Partager via

Résoudre les problèmes du fournisseur Azure Key Vault pour le pilote CSI du magasin de secrets

  • Article

Cet article décrit les problèmes courants que vous pouvez rencontrer lorsque vous utilisez le pilote CSI (Container Storage Interface) du fournisseur Microsoft Azure Key Vault sur Azure Kubernetes Service (AKS). L’article fournit des conseils de dépannage pour résoudre ces problèmes.

Conditions préalables

Liste de pour la résolution des problèmes

Les journaux d’Key Vault Azure sont disponibles dans les pods de fournisseur et de pilote. Pour résoudre les problèmes qui affectent le fournisseur ou le pilote, examinez les journaux du fournisseur ou du pod de pilote qui s’exécute sur le même nœud que celui sur lequel votre pod d’application s’exécute.

Étape 1 de résolution des problèmes : Vérifier les journaux du fournisseur du magasin de secrets

Pour rechercher le secrets-store-provider-azure pod qui s’exécute sur le même nœud que celui sur lequel votre pod d’application s’exécute, exécutez les commandes kubectl get et kubectl logs suivantes qui sélectionnent l’application secrets-store-provider-azure :

kubectl get pods --selector 'app in (csi-secrets-store-provider-azure, secrets-store-provider-azure)' \
    --all-namespaces \
    --output wide
kubectl logs <provider-pod-name> --since=1h | grep ^E

Étape 2 de résolution des problèmes : Vérifier les journaux du pilote CSI du magasin de secrets

Pour accéder aux journaux du pilote CSI du magasin de secrets, exécutez les mêmes commandes qu’à l’étape 1, mais sélectionnez l’application à la secrets-store-csi-driver place et spécifiez le secrets-store conteneur :

kubectl get pods --selector app=secrets-store-csi-driver --all-namespaces --output wide
kubectl logs <driver-pod-name> --container secrets-store --since=1h | grep ^E

Remarque

Si vous ouvrez une demande de support, il est judicieux d’inclure les journaux pertinents du fournisseur Azure Key Vault et du pilote CSI du magasin de secrets.

Cause 1 : Impossible de récupérer le jeton du coffre de clés

Vous pouvez voir l’entrée d’erreur suivante dans les journaux ou les messages d’événement :

Avertissement ÉchecMontage 74s kubelet MountVolume.SetUp a échoué pour le volume « secrets-store-inline » : kubernetes.io/csi : mounter. SetupAt failed : rpc error : code = Unknown desc = failed to mount secrets store objects for pod default/test, err : rpc error : code = Unknown desc = failed to mount objects, error : failed to get keyvault client : failed to get key vault token : failed to get key vault token : nmi response failed with status code : 404, err : <nil>

Cette erreur se produit parce qu’un composant Node Managed Identity (NMI) dans aad-pod-identity a retourné un message d’erreur concernant une demande de jeton.

Solution 1 : Vérifier les journaux du pod NMI

Pour plus d’informations sur cette erreur et sur la façon de la résoudre, case activée les journaux des pods NMI et reportez-vous au guide de résolution des problèmes d’identité de pod Microsoft Entra.

Cause 2 : Le pod du fournisseur ne peut pas accéder au coffre de clés instance

Vous pouvez voir l’entrée d’erreur suivante dans les journaux ou les messages d’événement :

E1029 17 :37 :42.461313 1 server.go :54] n’a pas pu traiter la demande de montage, erreur : coffre de clés. BaseClient#GetSecret : Échec de l’envoi de la demande : StatusCode=0 -- Erreur d’origine : délai de contexte dépassé

Cette erreur se produit parce que le pod fournisseur ne peut pas accéder au coffre de clés instance. L’accès peut être empêché pour l’une des raisons suivantes :

  • Une règle de pare-feu bloque le trafic de sortie du fournisseur.

  • Les stratégies réseau configurées dans le cluster AKS bloquent le trafic de sortie.

  • Les pods du fournisseur s’exécutent sur le réseau hôte. Une défaillance peut se produire si une stratégie bloque ce trafic ou si des gigues réseau se produisent sur le nœud.

Solution 2 : Vérifier les stratégies réseau, la liste d’autorisation et la connexion de nœud

Pour résoudre le problème, effectuez les actions suivantes :

  • Placez les pods du fournisseur dans la liste d’autorisation.

  • Recherchez les stratégies configurées pour bloquer le trafic.

  • Assurez-vous que le nœud dispose d’une connectivité à Microsoft Entra ID et à votre coffre de clés.

Pour tester la connectivité à votre coffre de clés Azure à partir du pod qui s’exécute sur le réseau hôte, procédez comme suit :

  1. Créez le pod :

    cat <<EOF | kubectl apply --filename -
apiVersion: v1
kind: Pod
metadata:
  name: curl
spec:
  hostNetwork: true
  containers:
  - args:
    - tail
    - -f
    - /dev/null
    image: curlimages/curl:7.75.0
    name: curl
  dnsPolicy: ClusterFirst
  restartPolicy: Always
EOF

  2. Exécutez kubectl exec pour exécuter une commande dans le pod que vous avez créé :

    kubectl exec --stdin --tty  curl -- sh

  3. Authentifiez-vous à l’aide de votre coffre de clés Azure :

    curl -X POST 'https://login.microsoftonline.com/<aad-tenant-id>/oauth2/v2.0/token' \
     -d 'grant_type=client_credentials&client_id=<azure-client-id>&client_secret=<azure-client-secret>&scope=https://vault.azure.net/.default'

  4. Essayez d’obtenir un secret déjà créé dans votre coffre de clés Azure :

    curl -X GET 'https://<key-vault-name>.vault.azure.net/secrets/<secret-name>?api-version=7.2' \
     -H "Authorization: Bearer <access-token-acquired-above>"

Cause 3 : L’identité managée affectée par l’utilisateur est incorrecte dans la ressource personnalisée SecretProviderClass

Si vous rencontrez un code d’erreur HTTP « 400 » instance accompagné d’une description d’erreur « Identité introuvable », l’identité managée affectée par l’utilisateur est incorrecte dans votre SecretProviderClass ressource personnalisée. La réponse complète ressemble au texte suivant :

MountVolume.SetUp failed for volume "<volume-name>" :  
  rpc error:  
    code = Unknown desc = failed to mount secrets store objects for pod <namespace>/<pod>,  
    err: rpc error: code = Unknown desc = failed to mount objects,  
    error: failed to get objectType:secret, objectName:<key-vault-secret-name>, objectVersion:: azure.BearerAuthorizer#WithAuthorization:  
      Failed to refresh the Token for request to https://<key-vault-name>.vault.azure.net/secrets/<key-vault-secret-name>/?api-version=2016-10-01:  
        StatusCode=400 -- Original Error: adal: Refresh request failed.  
        Status Code = '400'.  
        Response body: {"error":"invalid_request","error_description":"Identity not found"}  
        Endpoint http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&client_id=<userAssignedIdentityID>&resource=https%!!(MISSING)A(MISSING)%!!(MISSING)F(MISSING)%!!(MISSING)F(MISSING)vault.azure.net

Solution 3 : Mettre à jour SecretProviderClass à l’aide de la valeur userAssignedIdentityID correcte

Recherchez l’identité managée affectée par l’utilisateur correcte, puis mettez à jour la SecretProviderClass ressource personnalisée pour spécifier la valeur correcte dans le userAssignedIdentityID paramètre . Pour trouver l’identité managée affectée par l’utilisateur appropriée, exécutez la commande az aks show suivante dans Azure CLI :

az aks show --resource-group <resource-group-name> \
    --name <cluster-name> \
    --query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId \
    --output tsv

Pour plus d’informations sur la configuration d’une SecretProviderClass ressource personnalisée au format YAML, consultez la section Utiliser une identité managée affectée par l’utilisateur de l’article Fournir une identité pour accéder au pilote CSI du fournisseur Azure Key Vault pour le magasin de secrets.

Cause 4 : le point de terminaison privé Key Vault se trouve sur un réseau virtuel différent des nœuds AKS

L’accès au réseau public n’est pas autorisé au niveau de l’Key Vault Azure, et la connectivité entre AKS et Key Vault s’effectue via une liaison privée. Toutefois, les nœuds AKS et le point de terminaison privé du Key Vault se trouvent sur des réseaux virtuels différents. Ce scénario génère un message qui ressemble au texte suivant :

MountVolume.SetUp failed for volume "<volume>" :  
  rpc error:  
    code = Unknown desc = failed to mount secrets store objects for pod <namespace>/<pod>,  
    err: rpc error: code = Unknown desc = failed to mount objects,  
    error: failed to get objectType:secret, objectName: :<key-vault-secret-name>, objectVersion:: keyvault.BaseClient#GetSecret:  
      Failure responding to request:  
        StatusCode=403 -- Original Error: autorest/azure: Service returned an error.  
        Status=403 Code="Forbidden"  
        Message="Public network access is disabled and request is not from a trusted service nor via an approved private link.\r\n  
        Caller: appid=<application-id>;oid=<object-id>;iss=https://sts.windows.net/<id>/;xms_mirid=/subscriptions/<subscription-id>/resourcegroups/<aks-infrastructure-resource-group>/providers/Microsoft.Compute/virtualMachineScaleSets/aks-<nodepool-name>-<nodepool-id>-vmss;xms_az_rid=/subscriptions/<subscription-id>/resourcegroups/<aks-infrastructure-resource-group>/providers/Microsoft.Compute/virtualMachineScaleSets/aks-<nodepool-name>-<nodepool-id>-vmss \r\n  
        Vault: <keyvaultname>;location=<location>" InnerError={"code":"ForbiddenByConnection"}

La résolution du problème de connectivité est généralement un processus en deux étapes :

Ces étapes sont décrites plus en détail dans les sections suivantes.

Connectez-vous aux nœuds de cluster AKS pour déterminer si le nom de domaine complet (FQDN) du Key Vault est résolu via une adresse IP publique ou une adresse IP privée. Si vous recevez le message d’erreur « L’accès réseau public est désactivé et la demande ne provient pas d’un service approuvé ni d’une liaison privée approuvée », le point de terminaison Key Vault est probablement résolu via une adresse IP publique. Pour case activée pour ce scénario, exécutez la commande nslookup :

nslookup <key-vault-name>.vault.azure.net

Si le nom de domaine complet est résolu par le biais d’une adresse IP publique, la sortie de la commande ressemble au texte suivant :

root@aks-<nodepool-name>-<nodepool-id>-vmss<scale-set-instance>:/# nslookup <key-vault-name>.vault.azure.net
Server:         168.63.129.16
Address:        168.63.129.16#53

Non-authoritative answer:
<key-vault-name>.vault.azure.net  canonical name = <key-vault-name>.privatelink.vaultcore.azure.net.
<key-vault-name>.privatelink.vaultcore.azure.net  canonical name = data-prod.weu.vaultcore.azure.net.
data-prod-weu.vaultcore.azure.net  canonical name = data-prod-weu-region.vaultcore.azure.net.
data-prod-weu-region.vaultcore.azure.net  canonical name = azkms-prod-weu-b.westeurope.cloudapp.azure.com.
Name:   azkms-prod-weu-b.westeurope.cloudapp.azure.com
Address: 20.1.2.3

Dans ce cas, créez une liaison de réseau virtuel pour le réseau virtuel du cluster AKS au niveau de la zone DNS privée. (Une liaison de réseau virtuel est déjà créée automatiquement pour le réseau virtuel du point de terminaison privé Key Vault.)

Pour créer le lien de réseau virtuel, procédez comme suit :

  1. Dans le Portail Azure, recherchez et sélectionnez DNS privé zones.

  2. Dans la liste des zones DNS privées, sélectionnez le nom de votre zone DNS privée. Dans cet exemple, la zone DNS privée est privatelink.vaultcore.azure.net.

  3. Dans le volet de navigation de la zone DNS privée, recherchez l’en-tête Paramètres , puis sélectionnez Liens de réseau virtuel.

  4. Dans la liste des liens de réseau virtuel, sélectionnez Ajouter.

  5. Dans la page de lien Ajouter un réseau virtuel , renseignez les champs suivants.

    Nom du champ Action
    Nom du lien Entrez un nom à utiliser pour le lien de réseau virtuel.
    Subscription Sélectionnez le nom de l’abonnement que vous souhaitez contenir le lien de réseau virtuel.
    Réseau virtuel Sélectionnez le nom du réseau virtuel du cluster AKS.

  6. Cliquez sur le bouton OK.

Une fois la procédure de création de lien terminée, exécutez la nslookup commande . La sortie doit maintenant ressembler au texte suivant qui montre une résolution DNS plus directe :

root@aks-<nodepool-name>-<nodepool-id>-vmss<scale-set-instance>:/# nslookup <key-vault-name>.vault.azure.net
Server:         168.63.129.16
Address:        168.63.129.16#53

Non-authoritative answer:
<key-vault-name>.vault.azure.net  canonical name = <key-vault-name>.privatelink.vaultcore.azure.net.
Name:   <key-vault-name>.privatelink.vaultcore.azure.net
Address: 172.20.0.4

Une fois la liaison de réseau virtuel ajoutée, le nom de domaine complet doit pouvoir être résolu via une adresse IP privée.

Étape 2 : Ajouter le peering de réseaux virtuels entre les réseaux virtuels

Si vous utilisez un point de terminaison privé, vous avez probablement désactivé l’accès public au niveau Key Vault. Par conséquent, il n’existe aucune connectivité entre AKS et le Key Vault. Vous pouvez tester cette configuration à l’aide de la commande Netcat (nc) suivante :

nc -v -w 2 <key-vault-name>.vault.azure.net 443

Si la connectivité n’est pas disponible entre AKS et le Key Vault, vous voyez une sortie qui ressemble au texte suivant :

nc: connect to <key-vault-name>.vault.azure.net port 443 (tcp) timed out: Operation now in progress

Pour établir la connectivité entre AKS et le Key Vault, ajoutez le peering de réseaux virtuels entre les réseaux virtuels en procédant comme suit :

  1. Accédez au Portail Azure.

  2. Utilisez l’une des options suivantes pour suivre les instructions de la section Créer un homologue de réseau virtuel du Tutoriel : Connecter des réseaux virtuels avec appairage de réseaux virtuels à l’aide de la Portail Azure article pour appairer les réseaux virtuels et vérifier que les réseaux virtuels sont connectés (d’une extrémité) :

    • Accédez à votre réseau virtuel AKS et appairez-le au réseau virtuel du point de terminaison privé Key Vault.

    • Accédez au réseau virtuel du point de terminaison privé Key Vault et appairez-le au réseau virtuel AKS.

  3. Dans le Portail Azure, recherchez et sélectionnez le nom de l’autre réseau virtuel (le réseau virtuel que vous avez appairé à l’étape précédente).

  4. Dans le volet de navigation du réseau virtuel, recherchez le titre Paramètres , puis sélectionnez Peerings.

  5. Dans la page de peering de réseaux virtuels, vérifiez que la colonne Nom contient le nom du lien Peering du réseau virtuel distant que vous avez spécifié à l’étape 2. Vérifiez également que la colonne Peering status pour ce lien de peering a la valeur Connecté.

Une fois cette procédure terminée, vous pouvez réexécuter la commande Netcat. La résolution DNS et la connectivité entre AKS et le Key Vault doivent maintenant réussir. Assurez-vous également que les secrets Key Vault sont correctement montés et fonctionnent comme prévu, comme indiqué dans la sortie suivante :

Connection to <key-vault-name>.vault.azure.net 443 port [tcp/https] succeeded!

Solution 4b : Résoudre les problèmes liés au code d’erreur 403

Résolvez les problèmes liés au code d’erreur « 403 » en consultant la section HTTP 403 : Autorisations insuffisantes de l’article de référence Codes d’erreur de l’API REST Azure Key Vault.

Cause 5 : Le pilote secrets-store.csi.k8s.io est absent de la liste des pilotes CSI inscrits

Si vous recevez le message d’erreur suivant concernant un pilote manquant secrets-store.csi.k8s.io dans les événements de pod, les pods du pilote CSI du magasin de secrets ne s’exécutent pas sur le nœud dans lequel l’application s’exécute :

Avertissement FailedMount 42s (x12 over 8m56s) kubelet, akswin000000 MountVolume.SetUp a échoué pour le volume « secrets-store01-inline » : kubernetes.io/csi : mounter. SetUpAt n’a pas pu obtenir le client CSI : le nom du pilote secrets-store.csi.k8s.io introuvable dans la liste des pilotes CSI inscrits

Solution 5a : Installer le pilote CSI du magasin de secrets

Si vous avez installé le fournisseur Key Vault à l’aide de manifestes de déploiement, suivez les instructions pour installer le pilote CSI du magasin de secrets.

Solution 5b : redéployer le pilote CSI du magasin de secrets et le fournisseur Key Vault en ajoutant une tolérance de teinte

Si vous avez déjà déployé le pilote CSI du magasin de secrets, case activée si le nœud est contaminé. Si le nœud est affecté, redéployez le pilote CSI du magasin de secrets et Key Vault fournisseur en ajoutant une tolérance pour les teintes.

Solution 5c : (Windows uniquement) Utiliser des valeurs de configuration Helm lors de l’installation du pilote CSI du magasin de secrets et du fournisseur Key Vault

Si votre application s’exécute sur un nœud Windows, installez le pilote CSI du magasin de secrets et Key Vault fournisseur sur les nœuds Windows à l’aide des valeurs de configuration Helm.

Cause 6 : Le pilote ne peut pas communiquer avec le fournisseur

Si vous recevez le message d’erreur suivant dans les journaux ou les événements, le pilote ne peut pas communiquer avec le fournisseur :

Avertissement FailedMount 85s (x10 over 5m35s) kubelet, aks-default-28951543-vmss00000 MountVolume.SetUp a échoué pour le volume « secrets-store01-inline » : kubernetes.io/csi : mounter. SetupAt failed : rpc error : code = Unknown desc = failed to mount secrets store objects for pod default/nginx-secrets-store-inline-user-msi, err : failed to find provider binary azure, err : stat /etc/kubernetes/secrets-store-csi-providers/azure/provider-azure : no such file or directory

Solution 6a : (versions du fournisseur antérieures à la version 0.0.9) Assurez-vous que les pods de fournisseur s’exécutent sur tous les nœuds

Si votre version du fournisseur Key Vault installée est antérieure à la version 0.0.9, assurez-vous que les pods du fournisseur s’exécutent sur tous les nœuds.

Solution 6b : (fournisseur version 0.0.9 et ultérieure) Utiliser gRPC pour la communication avec le fournisseur

Si vous avez installé Key Vault fournisseur version 0.0.9 ou ultérieure, configurez le pilote pour communiquer avec le fournisseur à l’aide de gRPC.

Cause 7 : Le pilote CSI ne peut pas créer le secret Kubernetes

Si vous recevez le message d’erreur suivant dans le conteneur secret-store dans le pilote CSI, vous n’avez pas installé le rôle de cluster de contrôle d’accès en fonction du rôle (RBAC) et la liaison de rôle de cluster. Le rôle de cluster et la liaison de rôle de cluster sont nécessaires pour que le pilote CSI synchronise le contenu monté en tant que secret Kubernetes.

E0610 22 :27 :02.283100 1 secretproviderclasspodstatus_controller.go :325] « Échec de la création du secret Kubernetes » err="secrets is forbidden : User \"system :serviceaccount :default :secrets-store-csi-driver\ » cannot create resource \"secrets\ » in API group \"\ » in the namespace \"default\" » spc="default/azure-linux » pod="default/busybox-linux-5f479855f7-jvfw4 » secret="default/dockerconfig » spcps="default/busybox-linux-5f479855f7-jvfw4-default-azure-linux »

Solution 7 : Installer le rôle de cluster et la liaison de rôle de cluster requis

Lorsque vous installez ou mettez à niveau le pilote CSI et Key Vault fournisseur à l’aide de graphiques Helm du dépôt GitHub secrets-store-csi-driver-provider-azure, définissez le secrets-store-csi-driver.syncSecret.enabled paramètre Helm sur true. Cette modification de configuration installe le rôle de cluster et la liaison de rôle de cluster requis.

Pour vérifier que le rôle de cluster et la liaison de rôle de cluster sont installés, exécutez les commandes suivantes kubectl get :

# Synchronize as Kubernetes secret cluster role.
kubectl get clusterrole/secretprovidersyncing-role

# Synchronize as Kubernetes secret cluster role binding.
kubectl get clusterrolebinding/secretprovidersyncing-rolebinding

Cause 8 : La requête n’est pas authentifiée

La requête n’est pas authentifiée pour Key Vault, comme indiqué par un code d’erreur « 401 ».

Solution 8 : Résoudre les problèmes liés au code d’erreur 401

Résolvez les problèmes liés au code d’erreur « 401 » en consultant la section « HTTP 401 : Requête non authentifiée » de l’article de référence Codes d’erreur de l’API REST Azure Key Vault.

Cause 9 : Le nombre de demandes dépasse le maximum indiqué

Le nombre de demandes dépasse le maximum indiqué pour la période, comme indiqué par un code d’erreur « 429 ».

Solution 9 : Résoudre les problèmes liés au code d’erreur 429

Résolvez les problèmes liés au code d’erreur « 429 » en consultant la section « HTTP 429 : Trop de requêtes » de l’article de référence Codes d’erreur de l’API REST Azure Key Vault.

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.

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.