Partager via


Résolution des problèmes de certificat d’autorité de certification du module complémentaire Istio Service Mesh

Cet article décrit les problèmes courants de résolution des problèmes liés à la fonctionnalité de certificats d’autorité de certification du plug-in Plug-in Istio 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 plug-in pour le module complémentaire service mesh.

Note

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

Conditions préalables

  • Azure CLI.

  • L’outil Kubernetes kubectl , ou un outil similaire, pour se connecter au cluster. Pour installer kubectl à l’aide d’Azure CLI, exécutez la commande az aks install-cli .

  • Les outils d’interpréteur de commandes standard de style Linux suivants :

    • grep
    • sort
    • tail
    • awk
    • xargs
  • Outil jq pour interroger des données JSON.

Processus d’installation 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 du Magasin des secrets sur le cluster. Assurez-vous que Azure Key Vault et le cluster se trouvent sur le même locataire Azure.

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

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

  • Pour que le cluster détecte automatiquement les modifications apportées aux secrets Azure Key Vault, vous devez activer la rotation automatique pour le module complémentaire du fournisseur de secrets Azure Key Vault.

  • Bien que les modifications apportées au certificat intermédiaire soient appliquées automatiquement, les modifications apportées au certificat racine ne sont récupérées que par le plan de contrôle une fois le istiod déploiement redémarré par une tâche cronjob que le module complémentaire déploie, comme expliqué dans la section Ressources déployées . Cette tâche cronjob s’exécute à un intervalle de 10 minutes.

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

La fonctionnalité de certificats d’autorité de certification du plug-in Istio vous permet de configurer des certificats racine et intermédiaires de plug-in pour le maillage. 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 Azure Resource Manager (modèle ARM).
--root-cert-object-name<root-cert-obj-name> Nom de l’objet de certificat racine dans Azure Key Vault.
--ca-cert-object-name<inter-cert-obj-name> Nom de l’objet de certificat intermédiaire dans Azure Key Vault.
--ca-key-object-name<inter-key-obj-name> Nom de l’objet de clé privée de certificat intermédiaire dans Azure Key Vault.
--cert-chain-object-name<cert-chain-obj-name> Nom de l’objet de la chaîne de certificats dans Azure Key Vault.

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 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-21 SecretProviderClass 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 (Secrets Store Container Storage Interface) :

    kubectl get secretproviderclass --namespace aks-istio-system
    
    NAME                 AGE
    istio-spc-asm-1-21   14h
    
  • Le istio-ca-root-cert configmap est créé dans l’espace aks-istio-system de noms et tous les espaces de noms gérés par l’utilisateur. Ce configmap contient le certificat racine utilisé par l’autorité de certification et 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-21 cronjob est créé dans l’espace aks-istio-system de noms. Cette tâche cronjob est planifiée pour s’exécuter toutes les 10 minutes pour vérifier les mises à jour sur le certificat racine. Si le certificat racine qui se trouve dans le cacerts secret Kubernetes ne correspond pas au istio-ca-root-cert configmap dans l’espace aks-istio-system de noms, il redémarre le istiod-asm-1-21 déploiement :

    kubectl get cronjob --namespace aks-istio-system
    
    NAME                                    SCHEDULE       SUSPEND   ACTIVE
    istio-cert-validator-cronjob-asm-1-21   */10 * * * *   False     0     
    

    Vous pouvez exécuter la commande suivante pour vérifier les journaux cronjob pour 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 de certificat racine a été détectée :

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

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

Vous pouvez afficher les journaux de istiod 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 plug-in. Pour visualiser les journaux, exécutez la commande suivante :

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

Immédiatement avant chaque entrée de journal de certificat est 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é sur etc/cacerts/ca-key.pem ; le certificat auto-signé est utilisé. » Pour un certificat de plug-in, l’entrée indique « Utiliser le certificat enfichable sur etc/cacerts/ca-key.pem ». Les exemples d’entrées de journal relatives aux certificats sont indiquées dans les tableaux suivants.

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

    Timestamp Log level 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 branché sur 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 a ajouté 1 certificats pour approuver le cluster de domaine.local dans le vérificateur de certificats homologue
  • Entrées de journal pour un certificat d’autorité de certification plug-in

    Timestamp Log level 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 branché sur 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 a ajouté 1 certificats pour approuver le cluster de domaine.local dans le vérificateur de certificats 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, le sujet, 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 présentés dans le tableau suivant.

Émetteur Objet SN NotBefore NotAfter
« O=cluster.local » "" <32 chiffres-hex-value> « 2023-11-20T23:25:36Z » « 2033-11-17T23:27:36Z »

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

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

Résoudre des 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 du 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 à Azure Key Vault. La configuration de l’accès à Azure Key Vault provoque un blocage incorrect 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-21 pods sont bloqués dans un Init:0/2 état.

NOM PRÊT STATUT REDÉMARRAGES AGE
istiod-asm-1-21-6fcfd88478-2x95b 0/1 Fin d’exécution 0 5m55s
istiod-asm-1-21-6fcfd88478-6x5hh 0/1 Fin d’exécution 0 5m40s
istiod-asm-1-21-6fcfd88478-c48f9 0/1 Init :0/2 0 54 s
istiod-asm-1-21-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, car vous n’avez pas d’autorisations « get » pour les secrets sur le coffre de clés :

« Échec du traitement de la demande de montage » err=« Échec de l’obtention d’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 d’autorisation d’obtention de 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 fournisseur de secrets Azure Key Vault en obtenant et en listant les autorisations 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 du fournisseur de secrets Azure Key Vault en exécutant la commande az aks show :

OBJECT_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $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 $AKV_NAME --object-id $OBJECT_ID --secret-permissions get list

Note

Avez-vous créé votre coffre de clés à l’aide de 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 aux clés, certificats et secrets Key Vault 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 le lecteur Key Vault pour l’identité managée affectée par l’utilisateur du module complémentaire.

Problème 2 : La détection automatique des modifications du secret Key Vault 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 du 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 vérifier si la rotation automatique est activée :

az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER | jq -r '.addonProfiles.azureKeyvaultSecretsProvider.config.enableSecretRotation'

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

az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER | jq -r '.addonProfiles.azureKeyvaultSecretsProvider.config.rotationPollInterval'

Les secrets Azure Key Vault sont synchronisés avec le cluster lorsque l’intervalle de sondage 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 sont 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, les istiod-asm-1-21 pods peuvent être bloqués dans un Init:0/2 état, ce qui retarde l’installation du module complémentaire. Pour rechercher la cause sous-jacente de ce problème, exécutez la commande suivante kubectl describe sur le istiod déploiement et affichez la sortie :

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

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

Type Motif Âge De Message
Normale Planifié 3m9s planificateur par défaut Attribution réussie d’aks-istio-system/istiod-asm-1-21-6fcfd88478-hqdjj à aks-userpool-24672518-vmss000000
Avertissement FailedMount 66s kubelet Impossible d’attacher ou de monter des volumes : volumes non montés=[cacerts], volumes non attachés=[], échec du traitement des volumes=[] : délai d’attente de la condition
Avertissement FailedMount 61s (x9 sur 3m9s) kubelet MountVolume.SetUp a échoué pour le volume « cacerts » : erreur rpc : code = Inconnu desc = échec du montage des objets de magasin de secrets pour pod aks-istio-system/istiod-asm-1-21-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="A secret with (name/id) test-cert-chain est introuvable dans ce coffre de clés. Si vous avez récemment supprimé ce secret, vous pouvez 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é de contact tierce

Microsoft fournit des informations de contact tierces pour vous aider à trouver des informations supplémentaires à ce sujet. Ces informations de contact peuvent changer sans préavis. Microsoft ne garantit pas l’exactitude des informations de contact tierces.

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.