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
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’espaceaks-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’espaceaks-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’espaceaks-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’espaceaks-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 lecacerts
secret Kubernetes ne correspond pas auistio-ca-root-cert
configmap dans l’espaceaks-istio-system
de noms, il redémarre leistiod-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
Résolution des problèmes généraux du module complémentaire Istio Service Mesh
Résolution des problèmes liés au module complémentaire MeshConfig du maillage de service Istio
Résolution des problèmes de passerelle d’entrée du module complémentaire Istio Service Mesh
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.