: Remarque : Ce guide n'est compatible qu'avec les API Cloud Service Mesh avec Istio et n'est pas compatible avec les API Google Cloud. Pour en savoir plus, consultez la page Présentation de Cloud Service Mesh . Cette section décrit les problèmes courants liés à Cloud Service Mesh avec les API Istio et explique comment les résoudre. Si vous avez besoin d'une aide supplémentaire, consultez la page Obtenir de l'aide .
Dans Cloud Service Mesh, Mesh CA ou Istiod envoient des certificats aux charges de travail sur tous les clusters du maillage. Les règles d'authentification (mTLS, par exemple) et d'autorisation (autoriser/refuser, par exemple) sont transmises à chaque cluster.
Ces règles déterminent quelles charges de travail peuvent communiquer et comment.
Problèmes liés au protocole TLS
Les sections suivantes expliquent comment résoudre les problèmes liés au protocole TLS dans Cloud Service Mesh.
Les exemples de cette section utilisent la variable ${CTX}, qui est le nom du contexte du fichier de configuration Kubernetes par défaut que vous utilisez pour accéder au cluster. Définissez la variable ${CTX} comme dans l'exemple suivant :
export CTX=gke_PROJECT_ID _CLUSTER_LOCATION _CLUSTER_NAME
Vérifier l'application du protocole TLS
Vérifiez que les requêtes en texte brut ne sont pas autorisées pour un service, lorsque celui-ci nécessite des connexions TLS :
kubectl exec SOURCE_POD -n SOURCE_NAMESPACE -c \
SOURCE_CONTAINER -- curl -v DESTINATION_URL
En supposant que le service nécessite des connexions TLS, la requête en texte brut précédente doit échouer et obtenir un résultat semblable à celui-ci:
curl: (56) Recv failure: Connection reset by peer command terminated with exit code 56
Vérifier les certificats mTLS
Lorsque mTLS est activé, vérifiez le certificat mTLS de la charge de travail en affichant l'en-tête X-Forwarded-Client-Cert. Pour ce faire, procédez comme suit :
Déployez l'exemple de service httpbin, qui peut afficher les en-têtes qu'il reçoit.
Utilisez curl pour afficher l'en-tête X-Forwarded-Client-Cert :
kubectl exec --context=${CTX} SOURCE_POD -n SOURCE_NAMESPACE -c \
SOURCE_CONTAINER -- curl http://httpbin.sample:8000/headers -s | \
grep X-Forwarded-Client-Cert
L'en-tête X-Forwarded-Client-Cert affiche les informations sur les certificats mTLS, comme dans l'exemple suivant :
X-Forwarded-Client-Cert": "By=spiffe://lt-multicluster-t2-5-15-2020.svc.id.goog/ns/sample/sa/httpbin;Hash=0781d68adfdab85b08b6758ed502f352464e81166f065cc6acde9433337b4494;Subject=\"OU=istio_v1_cloud_workload,O=Google LLC,L=Mountain View,ST=California,C=US\";URI=spiffe://lt-multicluster-t2-5-15-2020.svc.id.goog/ns/sample/sa/sleep Vous pouvez également utiliser openssl sur le side-car pour afficher l'intégralité de la chaîne de certificats :
kubectl debug --image istio/base --target istio-proxy -it --context=${CTX} SOURCE_POD \
-n SOURCE_NAMESPACE -- openssl s_client -alpn istio -showcerts -connect httpbin.sample:8000
Le résultat affiche la chaîne de certificats. Si vous utilisez Mesh CA, vérifiez que le CN du certificat racine contient istio_v1_cloud_workload_root-signer-.... Si vous utilisez Istiod comme autorité de certification, vérifiez que le certificat racine est défini sur O = <var>YOUR_TRUST_DOMAIN</var>.
Erreurs TLS bad certificate dans les journaux Istiod
Si des erreurs de handshake TLS bad certificate sont présentes dans les journaux, cela peut indiquer qu'Istiod ne parvient pas à établir une connexion TLS à un service.
Vous pouvez utiliser la chaîne d'expression régulière TLS handshake error.*bad certificate pour rechercher ces erreurs dans les journaux.
Ces erreurs sont généralement informatives et temporaires. Toutefois, si elles persistent, elles peuvent indiquer un problème dans votre système.
Vérifiez que votre configuration MutatingWebhookConfiguration istio-sidecar-injector dispose d'un groupe d'autorités de certification.
Le webhook d'injecteur side-car (utilisé pour l'injection side-car automatique) nécessite un groupe d'autorités de certification pour établir des connexions sécurisées avec le serveur d'API et Istiod. Ce groupe d'autorités de certification est ajouté dans la configuration par Istiod, mais peut parfois être écrasé (par exemple, si vous relancez la configuration du webhook).
Vérifiez la présence du groupe d'autorités de certification :
Remarque : Si vous avez installé plusieurs plans de contrôle, spécifiez une révision spécifique.
kubectl get mutatingwebhookconfiguration -l app=sidecar-injector -o=jsonpath='{.items[0].webhooks[0].clientConfig.caBundle}'
Si le résultat n'est pas vide, le groupe d'autorités de certification est configuré. Si le groupe d'autorités de certification est absent, redémarrez istiod pour qu'il analyse à nouveau le webhook, puis réinstallez le groupe d'autorités de certification.
Journalisation de refus pour la stratégie d'autorisation
Pour en savoir plus sur la journalisation de refus pour la stratégie d'autorisation, consultez la section Journalisation de refus .
Les règles d'autorisation ne sont pas appliquées
Si vous observez des symptômes indiquant que les règles d'autorisation ne sont pas appliquées, utilisez la commande suivante pour les vérifier :
kubectl exec --context=${CTX} -it SOURCE_POD -n SOURCE_NAMESPACE \
-c SOURCE_CONTAINER -- curl DESTINATION_URL
Dans le résultat, les messages access denied indiquent que les règles d'autorisation sont correctement appliquées, comme suit :
RBAC: access denied
Si vous confirmez que les règles d'autorisation ne sont pas appliquées, refusez l'accès à l'espace de noms. L'exemple suivant refuse l'accès à l'espace de noms nommé authz-ns :
kubectl apply --context=${CTX} -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: deny-authz-ns
namespace: authz-ns
spec:
{}
EOF
Erreur "customresourcedefinitions.apiextensions.k8s.io is forbidden" dans les journaux Istiod
Vous pouvez rencontrer des erreurs semblables à celles-ci :
error failed to list CRDs: customresourcedefinitions.apiextensions.k8s.io is forbidden: User "system:serviceaccount:istio-system:istiod-service-account" cannot list resource "customresourcedefinitions" in API group "apiextensions.k8s.io" at the cluster scope
Vous pouvez utiliser la chaîne d'expression régulière /error.*cannot list resource/ pour rechercher ces erreurs dans les journaux.
Cela peut se produire lorsque votre déploiement Istiod ne dispose pas de la liaison IAM appropriée ou d'autorisations RBAC suffisantes pour lire une ressource personnalisée.
Vérifiez s'il manque une liaison IAM dans votre compte. Tout d'abord, assurez-vous d'avoir correctement défini les identifiants et les autorisations .
Vérifiez ensuite que la liaison IAM est présente à l'aide de la commande suivante. Dans cet exemple, PROJECT_ID est le résultat de gcloud config get-value project et PROJECT_NUMBER est le résultat de gcloud projects list --filter="project_id=${PROJECT_ID}" --format="value(project_number)" :
gcloud projects add-iam-policy-binding ${PROJECT_ID} --member "serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-meshdataplane.iam.gserviceaccount.com" --role "roles/meshdataplane.serviceAgent" Vérifiez que vos règles RBAC sont correctement installées.
Si les règles RBAC sont manquantes, réexécutez asmcli install
Si les règles RBAC sont présentes et que les erreurs persistent, vérifiez que ClusterRoleBindings et RoleBindings associent les règles RBAC au bon compte de service Kubernetes. Vérifiez également que votre déploiement Istiod utilise le compte de service spécifié.
Erreurs de processus serverca dans les journaux Istiod
Vous pouvez rencontrer des erreurs semblables à celles-ci :
Authentication failed: Authenticator ClientCertAuthenticator at index 0 got error
Vous pouvez utiliser la chaîne d'expression régulière /serverca.*Authentication failed:.*JWT/ pour rechercher ces erreurs dans les journaux.
Cette erreur peut se produire lorsque l'émetteur JWT est mal configuré, si un client utilise un jeton arrivé à expiration ou si un autre problème de sécurité empêche une connexion de s'authentifier correctement auprès d'Istiod.
