Dela via

Felsöka CSI-drivrutin för Azure Key Vault Provider för Secrets Store

  • Artikel

Den här artikeln beskriver vanliga problem som kan uppstå när du använder Microsoft Azure Key Vault Provider for Secrets Store Container Storage Interface (CSI)-drivrutin på Azure Kubernetes Service (AKS). Artikeln innehåller felsökningstips för att lösa dessa problem.

Förutsättningar

Checklista för felsökning

Azure Key Vault-loggar är tillgängliga i provider- och drivrutinspoddarna. Om du vill felsöka problem som påverkar providern eller drivrutinen undersöker du loggarna från providern eller drivrutinspodden som körs på samma nod som programpodden körs på.

Felsökning steg 1: Kontrollera providerloggarna för Secrets Store

Om du vill hitta podden secrets-store-provider-azure som körs på samma nod som programpodden körs på kör du följande kommandon för kubectl get - och kubectl-loggar som väljer secrets-store-provider-azure programmet:

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

Felsökning steg 2: Kontrollera CSI-drivrutinsloggarna för Secrets Store

Om du vill komma åt CSI-drivrutinsloggarna för Secrets Store kör du samma kommandon som i steg 1, men väljer secrets-store-csi-driver programmet i stället och anger containern secrets-store :

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

Obs!

Om du öppnar en supportbegäran är det en bra idé att inkludera relevanta loggar från Azure Key Vault-providern och CSI-drivrutinen för Secrets Store.

Orsak 1: Det gick inte att hämta nyckelvalvstoken

Du kan se följande felpost i loggarna eller händelsemeddelandena:

Varning FailedMount 74s kubelet MountVolume.SetUp misslyckades för volymen "secrets-store-inline" : kubernetes.io/csi: mounter. SetupAt misslyckades: rpc-fel: 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: nmi response failed with status code: 404, err: <nil>

Det här felet beror på att en NMI-komponent (Node Managed Identity) i aad-pod-identity returnerade ett felmeddelande om en tokenbegäran.

Lösning 1: Kontrollera NMI-poddloggarna

Mer information om det här felet och hur du löser det finns i felsökningsguiden för NMI-poddar och i felsökningsguiden för Microsoft Entra poddidentitet.

Orsak 2: Providerpodden kan inte komma åt key vault-instansen

Du kan se följande felpost i loggarna eller händelsemeddelandena:

E1029 17:37:42.461313 1 server.go:54] kunde inte bearbeta monteringsbegäran, fel: keyvault. BaseClient#GetSecret: Det gick inte att skicka begäran: StatusCode=0 -- Ursprungligt fel: tidsgränsen för kontexten överskreds

Det här felet beror på att providerpodden inte kan komma åt key vault-instansen. Åtkomst kan förhindras av någon av följande orsaker:

  • En brandväggsregel blockerar utgående trafik från providern.

  • Nätverksprinciper som konfigureras i AKS-klustret blockerar utgående trafik.

  • Providerpoddarna körs i värdnätverket. Ett fel kan inträffa om en princip blockerar den här trafiken eller om nätverksjitter inträffar på noden.

Lösning 2: Kontrollera nätverksprinciper, tillåtlista och nodanslutning

Åtgärda problemet genom att vidta följande åtgärder:

  • Placera providerpoddarna på listan över tillåtna.

  • Sök efter principer som har konfigurerats för att blockera trafik.

  • Kontrollera att noden har anslutning till Microsoft Entra ID och ditt nyckelvalv.

Följ dessa steg för att testa anslutningen till ditt Azure-nyckelvalv från den podd som körs i värdnätverket:

  1. Skapa podden:

    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. Kör kubectl exec för att köra ett kommando i podden som du skapade:

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

  3. Autentisera med hjälp av ditt Azure-nyckelvalv:

    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. Försök att hämta en hemlighet som redan har skapats i ditt Azure-nyckelvalv:

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

Orsak 3: Den användartilldelade hanterade identiteten är felaktig i den anpassade resursen SecretProviderClass

Om du stöter på en HTTP-felkod "400"-instans som åtföljs av en felbeskrivning av "Identitet hittades inte" är den användartilldelade hanterade identiteten felaktig i din SecretProviderClass anpassade resurs. Det fullständiga svaret liknar följande text:

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

Lösning 3: Uppdatera SecretProviderClass med rätt userAssignedIdentityID-värde

Hitta rätt användartilldelad hanterad identitet och uppdatera sedan den SecretProviderClass anpassade resursen för att ange rätt värde i parametern userAssignedIdentityID . Om du vill hitta rätt användartilldelad hanterad identitet kör du följande az aks show-kommando i Azure CLI:

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

Information om hur du konfigurerar en SecretProviderClass anpassad resurs i YAML-format finns i avsnittet Använda en användartilldelad hanterad identitet i artikeln Ange en identitet för att få åtkomst till Azure Key Vault Provider for Secrets Store CSI Driver.

Orsak 4: Den Key Vault privata slutpunkten finns i ett annat virtuellt nätverk än AKS-noderna

Åtkomst till offentligt nätverk tillåts inte på Azure Key Vault-nivå, och anslutningen mellan AKS och Key Vault görs via en privat länk. AKS-noderna och den privata slutpunkten för Key Vault finns dock i olika virtuella nätverk. Det här scenariot genererar ett meddelande som liknar följande text:

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"}

Att åtgärda anslutningsproblemet är vanligtvis en tvåstegsprocess:

De här stegen beskrivs mer detaljerat i följande avsnitt.

Anslut till AKS-klusternoderna för att avgöra om det fullständigt kvalificerade domännamnet (FQDN) för Key Vault matchas via en offentlig IP-adress eller en privat IP-adress. Om du får felmeddelandet "Offentlig nätverksåtkomst är inaktiverad och begäran inte kommer från en betrodd tjänst eller via en godkänd privat länk" löses förmodligen Key Vault slutpunkten via en offentlig IP-adress. Om du vill söka efter det här scenariot kör du kommandot nslookup :

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

Om FQDN matchas via en offentlig IP-adress liknar kommandoutdata följande text:

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

I det här fallet skapar du en virtuell nätverkslänk för det virtuella nätverket i AKS-klustret på den privata DNS-zonnivån. (En virtuell nätverkslänk har redan skapats automatiskt för det virtuella nätverket i Key Vault privata slutpunkten.)

Följ dessa steg för att skapa länken för det virtuella nätverket:

  1. I Azure Portal söker du efter och väljer Privat DNS zoner.

  2. I listan över privata DNS-zoner väljer du namnet på din privata DNS-zon. I det här exemplet är den privata DNS-zonen privatelink.vaultcore.azure.net.

  3. Leta upp rubriken Inställningar i navigeringsfönstret i den privata DNS-zonen och välj sedan Virtuella nätverkslänkar.

  4. I listan över länkar till virtuella nätverk väljer du Lägg till.

  5. På sidan Lägg till virtuellt nätverk-länk fyller du i följande fält.

    Fältnamn Åtgärd
    Länknamn Ange ett namn som ska användas för länken för det virtuella nätverket.
    Prenumeration Välj namnet på den prenumeration som du vill ska innehålla länken för det virtuella nätverket.
    Virtuellt nätverk Välj namnet på det virtuella nätverket för AKS-klustret.

  6. Välj OK knappen.

När du har slutfört länkens skapandeprocedur kör nslookup du kommandot . Utdata bör nu likna följande text som visar en mer direkt DNS-matchning:

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

När länken för det virtuella nätverket har lagts till bör det fullständiga domännamnet matchas via en privat IP-adress.

Steg 2: Lägg till peering för virtuella nätverk mellan virtuella nätverk

Om du använder en privat slutpunkt har du förmodligen inaktiverat offentlig åtkomst på Key Vault nivå. Det finns därför ingen anslutning mellan AKS och Key Vault. Du kan testa konfigurationen med hjälp av följande Netcat-kommando (nc):

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

Om anslutningen inte är tillgänglig mellan AKS och Key Vault visas utdata som liknar följande text:

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

Om du vill upprätta en anslutning mellan AKS och Key Vault lägger du till peering för virtuella nätverk mellan de virtuella nätverken genom att följa dessa steg:

  1. Gå till Azure Portal.

  2. Använd något av följande alternativ för att följa anvisningarna i avsnittet Skapa peer för virtuellt nätverk i självstudien: Ansluta virtuella nätverk med peering för virtuella nätverk med hjälp av artikeln Azure Portal för att peerkoppla de virtuella nätverken och kontrollera att de virtuella nätverken är anslutna (från ena änden):

    • Gå till ditt virtuella AKS-nätverk och peer-koppla det till det virtuella nätverket för Key Vault privata slutpunkten.

    • Gå till det virtuella nätverket för den Key Vault privata slutpunkten och peer-koppla den till det virtuella AKS-nätverket.

  3. I Azure Portal söker du efter och väljer namnet på det andra virtuella nätverket (det virtuella nätverk som du peer-kopplade till i föregående steg).

  4. Leta upp rubriken Inställningar i navigeringsfönstret för virtuellt nätverk och välj sedan Peerings.

  5. På peeringsidan för virtuella nätverk kontrollerar du att kolumnen Namn innehåller peeringlänknamnet för det virtuella fjärrnätverket som du angav i steg 2. Kontrollera också att kolumnen Peering-status för den peeringlänken har värdet Ansluten.

När du har slutfört den här proceduren kan du köra Netcat-kommandot igen. DNS-matchningen och anslutningen mellan AKS och Key Vault bör nu lyckas. Kontrollera också att Key Vault hemligheterna har monterats och fungerar som förväntat, vilket visas i följande utdata:

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

Lösning 4b: Felsöka felkod 403

Felsök felkoden "403" genom att läsa avsnittet HTTP 403: Insufficient Permissions (Otillräckliga behörigheter) i referensartikeln om Felkoder för REST API i Azure Key Vault.

Orsak 5: Den secrets-store.csi.k8s.io drivrutinen saknas i listan över registrerade CSI-drivrutiner

Om du får följande felmeddelande om en drivrutin som saknas secrets-store.csi.k8s.io i poddhändelserna körs inte CSI-drivrutinspoddarna för Secrets Store på noden där programmet körs:

Warning FailedMount 42s (x12 over 8m56s) kubelet, akswin000000 MountVolume.SetUp failed for volume "secrets-store01-inline" : kubernetes.io/csi: mounter. SetUpAt kunde inte hämta CSI-klienten: drivrutinsnamnet secrets-store.csi.k8s.io hittades inte i listan över registrerade CSI-drivrutiner

Lösning 5a: Installera CSI-drivrutinen för Secrets Store

Om du har installerat Key Vault-providern med hjälp av distributionsmanifest följer du anvisningarna för att installera CSI-drivrutinen för Secrets Store.

Lösning 5b: Distribuera om CSI-drivrutinen för secrets store och Key Vault-providern genom att lägga till taint-tolerans

Om du redan har distribuerat CSI-drivrutinen för Secrets Store kontrollerar du om noden är fläckad. Om noden är fördärvad distribuerar du om CSI-drivrutinen för secrets store och Key Vault-providern genom att lägga till tolerans för taints.

Lösning 5c: (endast Windows) Använd Helm-konfigurationsvärden när du installerar CSI-drivrutinen för Secrets Store och Key Vault-providern

Om programmet körs på en Windows-nod installerar du CSI-drivrutinen för Secrets Store och Key Vault providern på Windows-noder med hjälp av Helm-konfigurationsvärdena.

Orsak 6: Drivrutinen kan inte kommunicera med providern

Om du får följande felmeddelande i loggarna eller händelserna kan drivrutinen inte kommunicera med providern:

Warning FailedMount 85s (x10 over 5m35s) kubelet, aks-default-28951543-vmss000000 MountVolume.SetUp failed for volume "secrets-store01-inline" : kubernetes.io/csi: mounter. SetupAt misslyckades: rpc-fel: 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

Lösning 6a: (Providerversioner tidigare än version 0.0.9) Kontrollera att providerpoddar körs på alla noder

Om den installerade Key Vault providerversionen är tidigare än version 0.0.9 kontrollerar du att providerpoddarna körs på alla noder.

Lösning 6b: (Providerversion 0.0.9 och senare) Använd gRPC för providerkommunikation

Om du har installerat Key Vault providerversion 0.0.9 eller en senare version konfigurerar du drivrutinen så att den kommunicerar med providern med hjälp av gRPC.

Orsak 7: CSI-drivrutinen kan inte skapa Kubernetes-hemligheten

Om du får följande felmeddelande i containern secret-store i CSI-drivrutinen har du inte installerat rbac-klusterrollen (rollbaserad åtkomstkontroll) och klusterrollbindningen. Klusterrollen och klusterrollbindningen är nödvändiga för att CSI-drivrutinen ska kunna synkronisera det monterade innehållet som en Kubernetes-hemlighet.

E0610 22:27:02.283100 1 secretproviderclasspodstatus_controller.go:325] "det gick inte att skapa Kubernetes secret" err="secrets is forbidden: User \"system:serviceaccount:default:secrets-store-csi-driver\" kan inte skapa resursen \"secrets\" i API-gruppen \"\" i namespace \"default\"" spc="default/azure-linux" pod="default/busybox-linux-5f479855f7-jvfw4" secret="default/dockerconfig" spcps="default/busybox-linux-5f479855f7-jvfw4-default-azure-linux"

Lösning 7: Installera den klusterroll och klusterrollsbindning som krävs

När du installerar eller uppgraderar CSI-drivrutinen och Key Vault-providern med hjälp av Helm-diagram från GitHub-lagringsplatsen secrets-store-csi-driver-provider-azure anger du secrets-store-csi-driver.syncSecret.enabled Helm-parametern till true. Den här konfigurationsändringen installerar den klusterroll och klusterrollsbindning som krävs.

Kontrollera att klusterrollen och klusterrollbindningen är installerade genom att köra följande kubectl get kommandon:

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

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

Orsak 8: Begäran är oautentiserad

Begäran är oautentiserad för Key Vault, vilket anges med felkoden "401".

Lösning 8: Felsöka felkoden 401

Felsök felkoden "401" genom att läsa avsnittet "HTTP 401: Unauthenticated Request" (HTTP 401: oautentiserad begäran) i referensartikeln om REST API-felkoder i Azure Key Vault.

Orsak 9: Antalet begäranden överskrider det angivna maxvärdet

Antalet begäranden överskrider det angivna maxvärdet för tidsramen, vilket anges med felkoden "429".

Lösning 9: Felsök felkod 429

Felsök felkoden "429" genom att läsa avsnittet "HTTP 429: För många begäranden" i referensartikeln om REST API-felkoder i Azure Key Vault.

Ansvarsfriskrivning för information från tredje part

De produkter från andra tillverkare som diskuteras i denna artikel tillverkas oberoende av Microsoft. Produkternas funktion eller tillförlitlighet kan därför inte garanteras.

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.