Partager via

Résoudre les problèmes liés au module complémentaire fournisseur de secrets Azure Key Vault dans AKS

  • Article

Cet article explique comment résoudre les problèmes que vous pouvez rencontrer lors de l’utilisation du module complémentaire fournisseur de secrets Azure Key Vault dans Azure Kubernetes Service (AKS).

Note

Cet article s’applique à la version du module complémentaire managé AKS du fournisseur de secrets Azure Key Vault. Si vous utilisez la version helm installée (auto-gérée), accédez à la documentation GitHub du fournisseur Azure Key Vault pour le pilote CSI du magasin de secrets.

Prerequisites

Liste de contrôle pour la résolution des problèmes

Étape 1 : Vérifier que le module complémentaire fournisseur de secrets Azure Key Vault est activé sur votre cluster

Exécutez la commande az aks show pour vérifier que le module complémentaire est activé sur votre cluster :

az aks show -g <aks-resource-group-name> -n <aks-name> --query 'addonProfiles.azureKeyvaultSecretsProvider'

La sortie de commande doit être similaire au texte suivant :

{
  "config": null,
  "enabled": true,
  "identity": {
    "clientId": "<client-id>",
    "objectId": "<object-id>",
    "resourceId": "/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<azure-key-vault-secrets-provider-identity-name>"
  }
}

Si l’indicateur enabled est affiché comme false dans la sortie précédente, le module complémentaire fournisseur de secrets Azure Key Vault n’est pas activé sur votre cluster. Dans ce cas, reportez-vous à la documentation GitHub du fournisseur Azure Key Vault pour le pilote CSI du magasin de secrets pour la résolution des problèmes supplémentaires.

Si l’indicateur enabled est affiché comme true dans la sortie précédente, le module complémentaire fournisseur de secrets Azure Key Vault est activé sur votre cluster. Dans ce cas, passez aux étapes suivantes de cet article.

Étape 2 : Vérifier les journaux du fournisseur du magasin de secrets et des pods du pilote CSI

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

  1. Exécutez la commande kubectl get pour rechercher le fournisseur de magasin de secrets et les pods de pilote CSI qui s’exécutent sur le même nœud que celui sur lequel votre pod d’application s’exécute :

    kubectl get pod -l 'app in (secrets-store-provider-azure, secrets-store-csi-driver)' -n kube-system -o wide

  2. Exécutez la commande kubectl logs pour afficher les journaux d’activité à partir du pod fournisseur du magasin de secrets :

    kubectl logs -n kube-system <provider-pod-name> --since=1h | grep ^E

  3. Exécutez la commande kubectl logs pour afficher les journaux d’activité à partir du pod de pilote CSI du Magasin des secrets :

    kubectl logs -n kube-system <csi-driver-pod-name> -c secrets-store --since=1h | grep ^E

Une fois que vous avez collecté les journaux du fournisseur du magasin de secrets et des pods du pilote CSI, analysez ces journaux sur les causes mentionnées dans les sections suivantes pour identifier le problème et la solution correspondante.

Note

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 d’activité ou les messages d’événement :

Avertissement FailedMount 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 NMI (Node Managed Identity) dans aad-pod-identity a retourné un message d’erreur concernant une demande de jeton.

Solution 1 : Vérifier les journaux des pods NMI

Pour plus d’informations sur cette erreur et sur la façon de le résoudre, consultez les journaux des pods NMI et consultez le guide de résolution des problèmes des identités de pod Microsoft Entra.

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

Vous pouvez voir l’entrée d’erreur suivante dans les journaux d’activité 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 : échéance du contexte dépassée

Cette erreur se produit, car le pod fournisseur ne peut pas accéder à l’instance du coffre de clés. 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 verte et la connexion de nœud

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

  • Placez les pods du fournisseur sur la liste verte.

  • 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ée 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 rechercher 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 à l’article Du pilote CSI du magasin de secrets Azure Key Vault.

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 d’Azure Key Vault, et la connectivité entre AKS et Key Vault est effectuée via une liaison privée. Toutefois, les nœuds AKS et le point de terminaison privé du coffre de clés se trouvent sur différents réseaux virtuels. Ce scénario génère un message semblable 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 :

  • Créez une liaison de réseau virtuel pour le réseau virtuel du cluster AKS au niveau de la zone AZURE DNS privée.

  • Ajoutez le peering de réseaux virtuels entre le réseau virtuel du cluster AKS et le réseau virtuel du point de terminaison privé Key Vault.

Ces étapes sont décrites de manière plus détaillée dans les sections suivantes.

Connectez-vous aux nœuds du cluster AKS pour déterminer si le nom de domaine complet (FQDN) du coffre de clés est résolu via une adresse IP publique ou une adresse IP privée. Si vous recevez le message d’erreur « L’accès au réseau public est désactivé et que la demande ne provient pas d’un service approuvé ni via une liaison privée approuvée », le point de terminaison Key Vault est probablement résolu par le biais d’une adresse IP publique. Pour rechercher 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 un lien de réseau virtuel, procédez comme suit :

  1. Dans la 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 le titre 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 Ajouter un lien de réseau virtuel, renseignez les champs suivants.

    Nom de champ Action
    Nom de la liaison Entrez un nom à utiliser pour le lien de réseau virtuel.
    Abonnement 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 être résolu par le biais d’une adresse IP privée.

Étape 2 : Ajouter un peering de réseaux virtuels entre des réseaux virtuels

Si vous utilisez un point de terminaison privé, vous avez probablement désactivé l’accès public au niveau du coffre de clés. Par conséquent, aucune connectivité n’existe entre AKS et 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 Key Vault, vous voyez la sortie semblable 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 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 le peering de réseaux virtuels à l’aide de l’article Portail Azure pour homologuer les réseaux virtuels et vérifier que les réseaux virtuels sont connectés (à partir 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 auquel 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 peering de réseaux virtuels, vérifiez que la colonne Name 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 d’état Peering pour ce lien de peering a la valeur Connected.

Une fois cette procédure terminée, vous pouvez réexécuter la commande Netcat. La résolution et la connectivité DNS entre AKS et Key Vault doivent maintenant réussir. Vérifiez également que les secrets Key Vault sont correctement montés et fonctionnent comme prévu, comme indiqué par 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 le code d’erreur « 403 » en consultant la section HTTP 403 : Autorisations insuffisantes de l’article de référence sur les codes d’erreur de l’API REST Azure Key Vault.

Cause 5 : Le pilote secrets-store.csi.k8s.io est manquant dans 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 des secrets ne s’exécutent pas sur le nœud dans lequel l’application s’exécute :

Avertissement FailedMount 42s (x12 over 8m56s) kubelet, akswin00000 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 5 : Résoudre les problèmes liés au pod de pilote CSI du magasin secret s’exécutant sur le même nœud

Récupérez l’état du pod pilote CSI du magasin secret s’exécutant sur le même nœud en exécutant la commande suivante :

kubectl get pod -l app=secrets-store-csi-driver -n kube-system -o wide

Si l’état du pod n’est pas Running ou n’importe lequel des conteneurs de ce pod n’est pas en Ready état, passez à la vérification des journaux d’activité de ce pod en suivant les étapes décrites dans Check the Secrets Store Provider and CSI Driver pod logs.

Cause 6 : SecretProviderClass introuvable

Vous pouvez voir l’événement suivant lors de la description de votre pod d’application :

Events:
  Type     Reason       Age               From               Message
  ----     ------       ----              ----               -------
  Warning  FailedMount  2s (x5 over 10s)  kubelet            MountVolume.SetUp failed for volume "xxxxxxx" : rpc error: code = Unknown desc = failed to get secretproviderclass xxxxxxx/xxxxxxx, error: SecretProviderClass.secrets-store.csi.x-k8s.io "xxxxxxxxxxxxx" not found

Cet événement indique que la SecretProviderClass spécification de volume de votre pod référencée n’existe pas dans le même espace de noms que votre pod d’application.

Solution 6a : Créer la ressource SecretProviderClass manquante

Assurez-vous que la ressource référencée dans la SecretProviderClass spécification de volume de votre pod existe dans le même espace de noms que celui où votre pod d’application est en cours d’exécution.

Solution 6b : Modifier la spécification du volume de votre pod d’application pour référencer le nom de ressource SecretProviderClass correct

Modifiez la spécification du volume de votre pod d’application pour référencer le nom de ressource approprié SecretProviderClass :

...
spec:
  containers:
  ...
  volumes:
    - name: my-volume
      csi:
        driver: secrets-store.csi.k8s.io
        readOnly: true
        volumeAttributes:
          secretProviderClass: "xxxxxxxxx"

Cause 7 : 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 7 : Résoudre les problèmes liés au code d’erreur 401

Résolvez le code d’erreur « 401 » en consultant la section « HTTP 401 : Requête non authentifiée » de l’article de référence sur les codes d’erreur de l’API REST Azure Key Vault.

Cause 8 : Le nombre de requêtes dépasse le nombre maximal indiqué

Le nombre de requêtes dépasse le nombre maximal indiqué pour la période, comme indiqué par un code d’erreur « 429 ».

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

Résolvez le code d’erreur « 429 » en consultant la section « HTTP 429 : Trop de requêtes » de l’article de référence sur les 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.