Partager via

Résolution des problèmes de certificat d’autorité de certification du plug-in de plug-in Istio Service Mesh

  • Article

Cet article décrit les problèmes courants de résolution des problèmes qui impliquent des certificats d’autorité de certification de plug-in pour le module complémentaire Istio Service Mesh, et propose des solutions pour résoudre ces problèmes. L’article passe également en revue le processus général de configuration des certificats d’autorité de certification de plug-in pour le module complémentaire de maillage de service.

Remarque

Cet article suppose que la révision asm-1-17 Istio est déployée sur le cluster.

Configuration requise

Processus de configuration générale

  • Avant d’activer le module complémentaire Istio pour utiliser la fonctionnalité de certificats d’autorité de certification de plug-in, vous devez activer le fournisseur Azure Key Vault pour le module complémentaire Magasin de secrets sur le cluster. Assurez-vous que le Key Vault Azure et le cluster se trouvent sur le même locataire Azure.

  • Une fois le module complémentaire fournisseur de secrets Azure Key Vault activé, vous devez configurer l’accès à l’Key Vault Azure pour l’identité managée affectée par l’utilisateur créée par le module complémentaire.

  • Une fois que vous avez accordé l’autorisation à l’identité managée affectée par l’utilisateur d’accéder à Azure Key Vault, vous pouvez utiliser la fonctionnalité de certificats d’autorité de certification de plug-in avec le module complémentaire Istio. Pour plus d’informations, consultez la section Activer le module complémentaire Istio pour utiliser un certificat d’autorité de certification de plug-in .

  • Pour que le cluster détecte automatiquement les modifications dans les secrets Azure Key Vault, vous devez activer la rotation automatique.

  • Bien que les modifications apportées au certificat intermédiaire soient appliquées automatiquement, le istiod déploiement doit être redémarré après avoir apporté des modifications au certificat racine. Le redémarrage du déploiement s’effectue à l’aide d’un cronjob, comme expliqué dans la section Ressources déployées .

Activer le module complémentaire Istio pour utiliser un certificat d’autorité de certification de plug-in

La fonctionnalité de certificat d’autorité de certification du plug-in Istio du module complémentaire Istio vous permet de configurer des certificats racine et intermédiaires de plug-in sur le maillage de votre cluster. Pour fournir des informations de certificat de plug-in lorsque vous activez le module complémentaire, spécifiez les paramètres suivants pour la commande az aks mesh enable dans Azure CLI.

Paramètre Description
--key-vault-id<resource-id> ID de ressource Azure Key Vault. Cette ressource est censée se trouver dans le même locataire que le cluster managé. Cet ID de ressource doit être au format d’ID de ressource du modèle de Resource Manager Azure (modèle ARM).
--root-cert-object-name<root-cert-obj-name> Nom de l’objet de certificat racine dans le coffre de clés Azure.
--ca-cert-object-name<inter-cert-obj-name> Nom de l’objet de certificat intermédiaire dans le coffre de clés Azure.
--ca-key-object-name<inter-key-obj-name> Nom de l’objet de clé privée du certificat intermédiaire dans le coffre de clés Azure.
--cert-chain-object-name<cert-chain-obj-name> Nom de l’objet de chaîne de certificats dans le coffre de clés Azure.

Si vous souhaitez utiliser la fonctionnalité de certificats d’autorité de certification de plug-in, vous devez spécifier les cinq paramètres. Tous les objets Azure Key Vault sont censés être de type Secret.

Pour plus d’informations, consultez Plug-in ca certificates for Istio-based service mesh add-on Azure Kubernetes Service.

Ressources déployées

Dans le cadre du déploiement du module complémentaire pour la fonctionnalité de certificats de plug-in, les ressources suivantes sont déployées sur le cluster :

  • Le cacerts secret Kubernetes est créé dans l’espace aks-istio-system de noms au moment du déploiement du module complémentaire. Ce secret contient des secrets Azure Key Vault synchronisés :

    kubectl describe secret cacerts --namespace aks-istio-system

    Name:         cacerts
Namespace:    aks-istio-system
Labels:       secrets-store.csi.k8s.io/managed=true
Annotations:  <none>

Type:  opaque

Data
====
ca-cert.pem:     1968 bytes
ca-key.pem:      3272 bytes
cert-chain.pem:  3786 bytes
root-cert.pem:   3636 bytes

  • L’objet istio-spc-asm-1-17SecretProviderClass est créé dans l’espace aks-istio-system de noms au moment du déploiement du module complémentaire. Cette ressource contient des paramètres spécifiques à Azure pour le pilote CSI (Container Storage Interface) du magasin de secrets :

    kubectl get secretproviderclass --namespace aks-istio-system

    NAME                 AGE
istio-spc-asm-1-17   14h

  • La istio-ca-root-cert carte de configuration est créée dans l’espace aks-istio-system de noms et tous les autres espaces de noms gérés par l’utilisateur. Ce mappage de configuration contient le certificat racine utilisé par l’autorité de certification, et il est utilisé par les charges de travail dans les espaces de noms pour valider la communication de charge de travail à charge de travail, comme suit :

    kubectl describe configmap istio-ca-root-cert --namespace aks-istio-system

    Name:         istio-ca-root-cert
Namespace:    aks-istio-system
Labels:       istio.io/config=true
Annotations:  <none>

Data
====
root-cert.pem:
----
-----BEGIN CERTIFICATE-----
<certificate data>
-----END CERTIFICATE-----

  • L’objet istio-cert-validator-cronjob-asm-1-17Cronjob est créé dans l’espace de aks-istio-system noms . Ce cronjob est planifié pour s’exécuter toutes les 10 minutes pour case activée des mises à jour sur le certificat racine. Si le certificat racine qui se trouve dans le cacerts secret Kubernetes ne correspond pas au mappage de istio-ca-root-cert configuration dans l’espace aks-istio-system de noms, il redémarre le istiod-asm-1-17 déploiement :

    kubectl get cronjob --namespace aks-istio-system

    NAME                                    SCHEDULE       SUSPEND   ACTIVE
istio-cert-validator-cronjob-asm-1-17   */10 * * * *   False     0

    Vous pouvez exécuter la commande suivante pour case activée les journaux cronjob de la dernière exécution :

    kubectl logs --namespace aks-istio-system $(kubectl get pods --namespace aks-istio-system | grep 'istio-cert-validator-cronjob-' | sort -k8 | tail -n 1 | awk '{print $1}')

    Cette commande génère l’un des messages de sortie suivants, selon qu’une mise à jour du certificat racine a été détectée ou non :

    Root certificate update not detected.

    Root certificate update detected. Restarting deployment...
deployment.apps/istiod-asm-1-17 restarted
Deployment istiod-asm-1-17 restarted.

Déterminer le type de certificat dans les journaux de déploiement

Vous pouvez afficher les journaux de déploiement pour déterminer si vous disposez d’un certificat d’autorité de certification auto-signé ou d’un certificat d’autorité de certification BYO (plug-in). Pour afficher les journaux, exécutez la commande suivante :

kubectl logs deploy/istiod-asm-1-17 --container discovery --namespace aks-istio-system | grep -v validationController

Immédiatement avant chaque entrée de journal de certificat se trouve une autre entrée de journal qui décrit ce type de certificat. Pour un certificat d’autorité de certification auto-signé, l’entrée indique « Aucun certificat branché à etc/cacerts/ca-key.pem ; le certificat auto-signé est utilisé. » Pour un certificat de plug-in, l’entrée indique « Utiliser le certificat branché à etc/cacerts/ca-key.pem ». Les exemples d’entrées de journal qui se rapportent aux certificats sont présentés dans les tableaux suivants.

  • Entrées de journal pour un certificat d’autorité de certification auto-signé

    Timestamp Niveau de journalisation Message
    2023-11-20T23 :27 :36.649019Z info Utilisation du format de fichier istiod pour la signature des fichiers ca
    2023-11-20T23 :27 :36.649032Z info Aucun certificat enfiché à etc/cacerts/ca-key.pem ; le certificat auto-signé est utilisé
    2023-11-20T23 :27 :36.649536Z info Certificat x509 - <détails du certificat>
    2023-11-20T23 :27 :36.649552Z info Les certificats Istiod sont rechargés
    2023-11-20T23 :27 :36.649613Z info spiffe Ajout de 1 certificat pour approuver le domaine cluster.local dans le vérificateur de certificats d’homologue

  • Entrées de journal pour un certificat d’autorité de certification BYO (plug-in)

    Timestamp Niveau de journalisation Message
    2023-11-21T00 :20 :25.808396Z info Utilisation du format de fichier istiod pour la signature des fichiers ca
    2023-11-21T00 :20 :25.808412Z info Utiliser le certificat enfiché à l’adresse etc/cacerts/ca-key.pem
    2023-11-21T00 :20 :25.808731Z info Certificat x509 - <détails du certificat>
    2023-11-21T00 :20 :25.808764Z info Certificat x509 - <détails du certificat>
    2023-11-21T00 :20 :25.808799Z info Certificat x509 - <détails du certificat>
    2023-11-21T00 :20 :25.808803Z info Les certificats Istiod sont rechargés
    2023-11-21T00 :20 :25.808873Z info spiffe Ajout de 1 certificat pour approuver le domaine cluster.local dans le vérificateur de certificats d’homologue

Les détails du certificat dans une entrée de journal sont affichés sous forme de valeurs séparées par des virgules pour l’émetteur, l’objet, le numéro de série (SN, une chaîne hexadécimale longue) et les valeurs d’horodatage de début et de fin qui définissent le moment où le certificat est valide.

Pour un certificat d’autorité de certification auto-signé, il existe une entrée de détail. Les exemples de valeurs de ce certificat sont indiqués dans le tableau suivant.

Émetteur Sujet SN NotBefore NotAfter
« O=cluster.local » "" <Valeur hexadécimale à 32 chiffres> « 2023-11-20T23 :25 :36Z » « 2033-11-17T23 :27 :36Z »

Pour un certificat d’autorité de certification BYO (plug-in), il existe trois entrées détaillées. Les deux autres entrées concernent une mise à jour du certificat racine et une modification du certificat intermédiaire. Les exemples de valeurs de ces entrées sont présentés dans le tableau suivant.

Émetteur Sujet SN NotBefore NotAfter
CN=Autorité de certification intermédiaire - A1,O=Istio,L=cluster-A1" "" <Valeur hexadécimale à 32 chiffres> « 2023-11-21T00 :18 :25Z » « 2033-11-18T00 :20 :25Z »
CN=Root A,O=Istio" « CN=Intermediate CA - A1,O=Istio,L=cluster-A1 » <Valeur hexadécimale à 40 chiffres> « 2023-11-04T01 :40 :22Z » « 2033-11-01T01 :40 :22Z »
CN=Root A,O=Istio" « CN=Root A,O=Istio » <Valeur hexadécimale à 40 chiffres> « 2023-11-04T01 :38 :27Z » « 2033-11-01T01 :38 :27Z »

Problèmes courants

Problème 1 : L’accès à Azure Key Vault est configuré de manière incorrecte

Après avoir activé le module complémentaire fournisseur de secrets Azure Key Vault, vous devez accorder l’accès à l’identité managée affectée par l’utilisateur du module complémentaire au Key Vault Azure. La configuration de l’accès à Azure Key Vault provoque de manière incorrecte le blocage de l’installation du module complémentaire.

kubectl get pods --namespace aks-istio-system

Dans la liste des pods, vous pouvez voir que les istiod-asm-1-17 pods sont bloqués dans un Init:0/2 état.

NOM PRÊT STATUT REDÉMARRE ÂGE
istiod-asm-1-17-6fcfd88478-2x95b 0/1 Terminaison 0 5m55s
istiod-asm-1-17-6fcfd88478-6x5hh 0/1 Terminaison 0 5m40s
istiod-asm-1-17-6fcfd88478-c48f9 0/1 Init :0/2 0 54 s
istiod-asm-1-17-6fcfd88478-wl8mw 0/1 Init :0/2 0 39 s

Pour vérifier le problème d’accès à Azure Key Vault, exécutez la kubectl get pods commande pour localiser les pods qui ont l’étiquette secrets-store-provider-azure dans l’espace kube-system de noms :

kubectl get pods --selector app=secrets-store-provider-azure --namespace kube-system --output name | xargs -I {} kubectl logs --namespace kube-system {}

L’exemple de sortie suivant montre qu’une erreur « 403 Interdit » s’est produite et que l’autorisation « obtenir » pour les secrets sur le coffre de clés vous est refusée :

« failed to process mount request » err="failed to get objectType :secret, objectName :<secret-object-name>, objectVersion :: keyvault. BaseClient#GetSecret : Échec de réponse à la demande : StatusCode=403 -- Erreur d’origine : autorest/azure : Le service a retourné une erreur. Status=403 Code=\"Forbidden\ » Message=\"L’utilisateur, le groupe ou l’application 'appid=<appid> ; oid=<oid> ; iss=<iss> » n’a pas l’autorisation d’obtention des secrets sur le coffre de clés « MyAzureKeyVault ; location=eastus'. Pour obtenir de l’aide sur la résolution de ce problème, consultez https://go.microsoft.com/fwlink/?linkid=2125287\ » InnerError={\"code\ » :\"AccessDenied\"} »

Pour résoudre ce problème, configurez l’accès à l’identité managée affectée par l’utilisateur pour le module complémentaire Azure Key Vault en obtenant les autorisations Get et List sur les secrets Azure Key Vault et en réinstallant le module complémentaire Istio. Tout d’abord, obtenez l’ID d’objet de l’identité managée affectée par l’utilisateur pour le module complémentaire Azure Key Vault en exécutant la commande az aks show :

OBJECT_ID=$(az aks show --resource-group <my-resource-group> --name <my-managed-cluster> --query 'addonProfiles.azureKeyvaultSecretsProvider.identity.objectId')

Pour définir la stratégie d’accès, exécutez la commande az keyvault set-policy suivante en spécifiant l’ID d’objet que vous avez obtenu :

az keyvault set-policy --name MyAzureKeyVault --object-id $OBJECT_ID --secret-permissions get list

Remarque

Avez-vous créé votre Key Vault en utilisant l’autorisation RBAC Azure pour votre modèle d’autorisation au lieu de la stratégie d’accès au coffre ? Dans ce cas, consultez Fournir l’accès à Key Vault clés, certificats et secrets avec un contrôle d’accès en fonction du rôle Azure pour créer des autorisations pour l’identité managée. Ajoutez une attribution de rôle Azure pour Key Vault Lecteur pour l’identité managée affectée par l’utilisateur du module complémentaire.

Problème 2 : La détection automatique des modifications de Key Vault secret n’est pas configurée

Pour qu’un cluster détecte automatiquement les modifications dans les secrets Azure Key Vault, vous devez activer la rotation automatique pour le module complémentaire fournisseur Azure Key Vault. La rotation automatique peut détecter automatiquement les modifications apportées aux certificats intermédiaires et racines. Pour un cluster qui active le module complémentaire fournisseur Azure Key Vault, exécutez la commande suivante az aks show pour case activée si la rotation automatique est activée :

az aks show --resource-group <my-resource-group> --name <my-managed-cluster> | jq -r '.addonProfiles.azureKeyvaultSecretsProvider.config.enableSecretRotation'

Si le cluster a activé le module complémentaire fournisseur Azure Key Vault, exécutez la commande suivante az aks show pour déterminer l’intervalle d’interrogation de rotation :

az aks show --resource-group <my-resource-group> --name <my-managed-cluster> | jq -r '.addonProfiles.azureKeyvaultSecretsProvider.config.rotationPollInterval'

Les secrets Azure Key Vault sont synchronisés avec le cluster lorsque le temps d’intervalle d’interrogation s’écoule après la synchronisation précédente. La valeur d’intervalle par défaut est de deux minutes.

Problème 3 : Les valeurs de certificat sont manquantes ou configurées de manière incorrecte

Si des objets secrets sont manquants dans Azure Key Vault, ou si ces objets sont configurés de manière incorrecte, l’installation du module complémentaire peut être retardée. Les istiod-asm-1-17 pods ne dépassent Init:0/2 pas status. Pour trouver la cause sous-jacente de ce problème, consultez les journaux de déploiement de ce pod en exécutant la commande suivante kubectl describe :

kubectl describe deploy/istiod-asm-1-17 --namespace aks-istio-system

La commande affiche les événements qui peuvent ressembler à la table de sortie suivante. Dans cet exemple, un secret manquant est la cause du problème.

Type Reason Âge From Message
Normal Scheduled 3m9s default-scheduler Aks-istio-system/istiod-asm-1-17-6fcfd88478-hqdjj attribué avec succès à aks-userpool-24672518-vmss0000000
Avertissement Échec du montage 66s kubelet Impossible d’attacher ou de monter des volumes : unmounted volumes=[cacerts], unattached volumes=[], échec du traitement des volumes=[] : délai d’attente de la condition
Avertissement Échec du montage 61s (x9 sur 3m9s) kubelet Échec de MountVolume.SetUp pour le volume « cacerts » : erreur rpc : code = Inconnu desc = échec du montage des objets de magasin de secrets pour le pod aks-istio-system/istiod-asm-1-17-6fcfd88478-hqdjj, err : rpc error : code = Unknown desc = failed to mount objects, error : failed to get objectType :secret, objectName :test-cert-chain, objectVersion :: keyvault. BaseClient#GetSecret : Échec de réponse à la demande : StatusCode=404 -- Erreur d’origine : autorest/azure : Le service a retourné une erreur. Status=404 Code="SecretNotFound » Message="Un secret avec (name/id) test-cert-chain est introuvable dans ce coffre de clés. Si vous avez récemment supprimé ce secret, vous pourrez peut-être le récupérer à l’aide de la commande de récupération correcte. Pour obtenir de l’aide sur la résolution de ce problème, consultez https://go.microsoft.com/fwlink/?linkid=2125182«

Ressources

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.

Exclusion de responsabilité sur les coordonnées externes

Microsoft fournit des informations de contacts externes afin de vous aider à obtenir un support technique sur ce sujet. Ces informations de contact peuvent être modifiées sans préavis. Microsoft ne garantit pas l’exactitude des informations concernant les sociétés externes.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.