Vous consultez la documentation de l'ancienne version de Service Mesh v1.18.

Versions disponibles

Cloud Service Mesh
Archive 1.22
Archive 1.21
Archive 1.20
Archive 1.19
Archive 1.18

Cette page a été traduite par l'API Cloud Translation.

Résoudre les problèmes de sécurité dans Cloud Service Mesh

Cette section décrit les problèmes courants liés à Cloud Service Mesh et explique comment les résoudre. Si vous avez besoin d'une aide supplémentaire, consultez la page Assistance.

Dans Cloud Service Mesh, Mesh CA ou Istiod envoient des certificats aux charges de travail sur tous les clusters du maillage. Des règles d'authentification (mTLS, par exemple) et d'autorisation (autoriser/refuser, par exemple) sont envoyées à 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 figurant dans cette section utilisent la variable ${CTX}, qui est le nom du contexte dans le fichier de configuration Kubernetes par défaut utilisé 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

Si le service nécessite des connexions TLS, la requête en texte brut ci-dessus doit échouer et générer 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 exec --context=${CTX} SOURCE_POD -n SOURCE_NAMESPACE -c istio-proxy \
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 pour les recréer.
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