Vous consultez la documentation d'Anthos Service Mesh 1.6. Accédez à la documentation la plus récente ou sélectionnez une autre version disponible :

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

Cette section explique les problèmes couramment rencontrés dans Anthos Service Mesh et indique comment les résoudre. Si vous avez besoin d'une aide supplémentaire, consultez la page Assistance.

Dans Anthos 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 Anthos 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 :

  1. Déployez l'exemple de service httpbin, qui peut afficher les en-têtes qu'il reçoit.

  2. 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
  3. 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.

  1. 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).

  2. Vérifiez la présence du groupe d'autorités de certification :

    kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector -o=jsonpath='{.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 rejet pour la stratégie d'autorisation

La stratégie d'autorisation refuse une requête si celle-ci n'est pas autorisée par la stratégie. Pour les protocoles HTTP (y compris gRPC), la requête sera refusée avec le code d'état 403. Pour les protocoles non HTTP, la connexion est directement interrompue. Pour en savoir plus sur les stratégies d'autorisation, consultez la page Autorisation Istio.

Le journal d'accès de la suite Google Cloud Operations fournit les informations nécessaires lorsque la requête est refusée par une stratégie d'autorisation, ce qui peut être utile dans certains cas. Par exemple, le journal indique le nombre de requêtes refusées par la stratégie d'autorisation, et peut vous aider à déterminer la stratégie à l'origine du refus depuis l'application backend.

Le journal d'accès de la suite Google Cloud Operations comprend les libellés suivantes pour le refus d'autorisation.

  • response_details : est défini sur AuthzDenied si le refus est causé par la stratégie d'autorisation.
  • policy_name : inclut l'espace de noms et le nom de la stratégie d'autorisation DENY à l'origine du refus. La valeur est au format <Namespace>.<Name>. Par exemple, foo.deny-method-get correspond à une stratégie d'autorisation deny-method-get dans l'espace de noms foo.
  • policy_rule : inclut l'index de la règle au sein de la stratégie d'autorisation à l'origine du refus. Par exemple, 0 correspond à la première règle de la stratégie.

Pour en savoir plus sur la façon d'obtenir le journal d'accès, consultez la section Accéder aux journaux dans Cloud Logging.

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.

  1. 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"
  2. Vérifiez que vos règles RBAC sont correctement installées.

  3. Si les règles RBAC sont manquantes, réexécutez istioctl install (ou la méthode d'installation que vous avez utilisée pour installer Anthos Service Mesh) afin de les recréer.

  4. 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.