Felsöka azure Key Vault Secrets Provider-tillägg i AKS

Artikel
12/13/2024

I den här artikeln beskrivs hur du felsöker problem som kan uppstå när du använder tillägget Azure Key Vault Secrets Provider i Azure Kubernetes Service (AKS).

Kommentar

Den här artikeln gäller för den AKS-hanterade tilläggsversionen av Azure Key Vault Secrets Provider. Om du använder den installerade helm-versionen (självhanterad) går du till Azure Key Vault Provider for Secrets Store CSI Driver GitHub-dokumentationen.

Förutsättningar

Azure CLI
Kubernetes kubectl-verktyget (Om du vill installera kubectl med hjälp av Azure CLI kör du kommandot az aks install-cli .)
Tillägget Kubernetes Secrets Store CSI-drivrutin aktiverad i AKS-klustret
Verktyget klient-URL (curl)
Kommandoradsverktyget Netcat (nc) för TCP-anslutningar

Checklista för felsökning

Steg 1: Bekräfta att azure Key Vault Secrets Provider-tillägget är aktiverat i klustret

Kör kommandot az aks show för att bekräfta att tillägget är aktiverat i klustret:

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

Kommandoutdata bör likna följande text:

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

enabled Om flaggan visas som false i föregående utdata är tillägget Azure Key Vault Secrets Provider inte aktiverat i klustret. I det här fallet går du till Azure Key Vault Provider for Secrets Store CSI Driver GitHub-dokumentationen för ytterligare felsökning.

enabled Om flaggan visas som true i föregående utdata aktiveras tillägget Azure Key Vault Secrets Provider i klustret. I det här fallet går du till nästa steg i den här artikeln.

Steg 2: Kontrollera loggarna för secrets store-providern och CSI-drivrutinspodden

Tilläggsloggar för Azure Key Vault Secrets Provider genereras av både provider- och drivrutinspoddar. Om du vill felsöka problem som påverkar providern eller drivrutinen granskar du loggarna från podden som körs på samma nod som programpodden.

Kör kommandot kubectl get för att hitta poddarna Secrets Store Provider och CSI Driver som körs på samma nod som programpodden körs på:
```
kubectl get pod -l 'app in (secrets-store-provider-azure, secrets-store-csi-driver)' -n kube-system -o wide
```
Kör kommandot kubectl logs för att visa loggar från podden Secrets Store Provider:
```
kubectl logs -n kube-system <provider-pod-name> --since=1h | grep ^E
```
Kör kommandot kubectl logs för att visa loggar från CSI-drivrutinspodden för Secrets Store:
```
kubectl logs -n kube-system <csi-driver-pod-name> -c secrets-store --since=1h | grep ^E
```

När du har samlat in poddloggarna för secrets store-providern och CSI-drivrutinen analyserar du loggarna mot de orsaker som anges i följande avsnitt för att identifiera problemet och motsvarande lösning.

Kommentar

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:

Warning FailedMount 74s kubelet MountVolume.SetUp misslyckades för volymen "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: 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 NMI-poddloggarna och i felsökningsguiden för Microsoft Entra-poddidentitet.

Orsak 2: Providerpodden kan inte komma åt nyckelvalvsinstansen

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ätverks jitters 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 podden som körs i värdnätverket:

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

Kör kubectl exec för att köra ett kommando i podden som du skapade:
```
kubectl exec --stdin --tty  curl -- sh
```

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'

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 privata Key Vault-slutpunkten finns i ett annat virtuellt nätverk än AKS-noderna

Offentlig nätverksåtkomst 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 nyckelvalvets privata slutpunkt 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"}

Lösning 4a: Konfigurera en länk för virtuellt nätverk och peering för virtuella nätverk för att ansluta de virtuella nätverken

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

Skapa en virtuell nätverkslänk för det virtuella nätverket i AKS-klustret på den privata Azure DNS-zonnivån .
Lägg till peering för virtuella nätverk mellan det virtuella nätverket i AKS-klustret och det virtuella nätverket för den privata Key Vault-slutpunkten.

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

Steg 1: Skapa länken för det virtuella nätverket

Anslut till AKS-klusternoderna för att avgöra om nyckelvalvets fullständigt kvalificerade domännamn (FQDN) 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 Key Vault-slutpunkten förmodligen 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 löses 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 länk till ett virtuellt nätverk skapas redan automatiskt för det virtuella nätverket för den privata Key Vault-slutpunkten.)

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

I Azure Portal söker du efter och väljer Privat DNS zoner.
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.
Leta upp rubriken Inställningar i navigeringsfönstret i den privata DNS-zonen och välj sedan Länkar till virtuellt nätverk.
I listan över länkar till virtuella nätverk väljer du Lägg till.

På länken Lägg till virtuellt nätverk 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.
Abonnemang	Välj namnet på den prenumeration som du vill innehålla länken för det virtuella nätverket.
Virtuellt nätverk	Välj namnet på aks-klustrets virtuella nätverk.

Välj knappen OK.

När du har slutfört länkskapandet kör du nslookup 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:

Gå till Azure-portalen.
Använd något av följande alternativ för att följa anvisningarna från 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 den privata Key Vault-slutpunkten.
- Gå till det virtuella nätverket för den privata Key Vault-slutpunkten och peer-koppla den till det virtuella AKS-nätverket.
I Azure Portal söker du efter och väljer namnet på det andra virtuella nätverket (det virtuella nätverk som du peerade till i föregående steg).
Leta upp rubriken Inställningar i navigeringsfönstret för det virtuella nätverket och välj sedan Peerings.
På sidan peering 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öka felkoden "403" genom att läsa avsnittet HTTP 403: Otillräcklig behörighet i referensartikeln för Rest API-felkoder för Azure Key Vault.

Orsak 5: Drivrutinen secrets-store.csi.k8s.io 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, akswin0000000 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 5: Felsöka CSI-drivrutinspodden för hemlig lagring som körs på samma nod

Hämta statusen för CSI-drivrutinspodden för hemlig lagring som körs på samma nod genom att köra följande kommando:

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

Om poddstatusen inte Running är eller om någon av containrarna i den här podden inte är i Ready tillstånd fortsätter du med att kontrollera loggarna för den här podden genom att följa stegen i Kontrollera poddloggarna för Secrets Store Provider och CSI Driver.

Orsak 6: SecretProviderClass hittades inte

Du kan se följande händelse när du beskriver programpodden:

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

Den här händelsen anger att referensen SecretProviderClass i poddens volymspecifikation inte finns i samma namnområde som programpodden.

Lösning 6a: Skapa den saknade SecretProviderClass-resursen

Kontrollera att resursen SecretProviderClass som refereras i poddens volymspecifikation finns i samma namnområde där programpodden körs.

Lösning 6b: Ändra programpoddens volymspecifikation för att referera till rätt SecretProviderClass-resursnamn

Redigera programpoddens volymspecifikation för att referera till rätt SecretProviderClass resursnamn:

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

Orsak 7: Begäran är oautentiserad

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

Lösning 7: Felsöka felkod 401

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

Orsak 8: Antalet begäranden överskrider det angivna maximala antalet

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

Lösning 8: Felsöka felkod 429

Felsöka felkoden "429" genom att läsa avsnittet "HTTP 429: Too Many Requests" (HTTP 429: För många begäranden) i referensartikeln om REST API-felkoder för 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.

Dela via