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.

Prerequisites

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

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.

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.

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.

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

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.

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

• Résolution des problèmes de mise à niveau de la mise à niveau de révision mineure du maillage de service Istio

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