Delen via

Problemen met CSI-stuurprogramma van Azure Key Vault Provider for Secrets Store oplossen

  • Artikel

In dit artikel worden veelvoorkomende problemen besproken die kunnen optreden wanneer u het stuurprogramma Microsoft Azure Key Vault Provider for Secrets Store Container Storage Interface (CSI) op Azure Kubernetes Service (AKS) gebruikt. Het artikel bevat tips voor probleemoplossing voor het oplossen van deze problemen.

Vereisten

Controlelijst voor probleemoplossing

Azure Key Vault-logboeken zijn beschikbaar in de provider- en stuurprogrammapods. Als u problemen wilt oplossen die van invloed zijn op de provider of het stuurprogramma, bekijkt u de logboeken van de provider of stuurprogrammapod die wordt uitgevoerd op hetzelfde knooppunt waarop uw toepassingspod wordt uitgevoerd.

Probleemoplossingsstap 1: de logboeken van de geheimenarchiefprovider controleren

Als u de secrets-store-provider-azure pod wilt vinden die wordt uitgevoerd op hetzelfde knooppunt waarop de toepassingspod wordt uitgevoerd, voert u de volgende kubectl get - en kubectl-logboekopdrachten uit waarmee de secrets-store-provider-azure toepassing wordt geselecteerd:

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

Probleemoplossingsstap 2: De logboeken van het CSI-stuurprogramma van Secrets Store controleren

Voer dezelfde opdrachten uit als in stap 1 om toegang te krijgen tot de logboeken van Secrets Store CSI-stuurprogramma, maar selecteer in plaats daarvan de secrets-store-csi-driver toepassing en geef de container op 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

Opmerking

Als u een ondersteuningsaanvraag opent, is het een goed idee om de relevante logboeken van de Azure Key Vault-provider en het CSI-stuurprogramma van Secrets Store op te nemen.

Oorzaak 1: kan het sleutelkluistoken niet ophalen

Mogelijk ziet u de volgende foutvermelding in de logboeken of gebeurtenisberichten:

Waarschuwing FailedMount 74s kubelet MountVolume.SetUp mislukt voor 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 token key vault: nmi response failed with status code: 404, error: <nil>

Deze fout treedt op omdat een NMI-onderdeel (Node Managed Identity) in aad-pod-identity een foutbericht over een tokenaanvraag heeft geretourneerd.

Oplossing 1: De NMI-podlogboeken controleren

Voor meer informatie over deze fout en hoe u deze kunt oplossen, raadpleegt u de NMI-podlogboeken en raadpleegt u de handleiding voor het oplossen van problemen met Microsoft Entra pod-identiteit.

Oorzaak 2: de providerpod heeft geen toegang tot het sleutelkluisexemplaren

Mogelijk ziet u de volgende foutvermelding in de logboeken of gebeurtenisberichten:

E1029 17:37:42.461313 1 server.go:54] kan de koppelingsaanvraag niet verwerken, fout: keyvault. BaseClient#GetSecret: Fout bij het verzenden van aanvraag: StatusCode=0 -- Oorspronkelijke fout: contextdeadline overschreden

Deze fout treedt op omdat de providerpod geen toegang heeft tot het sleutelkluisexemplaren. Toegang kan om een van de volgende redenen worden verhinderd:

  • Een firewallregel blokkeert uitgaand verkeer van de provider.

  • Netwerkbeleid dat is geconfigureerd in het AKS-cluster blokkeert uitgaand verkeer.

  • De providerpods worden uitgevoerd op het hostnetwerk. Er kan een fout optreden als een beleid dit verkeer blokkeert of als er netwerk-jitters optreden op het knooppunt.

Oplossing 2: Netwerkbeleid, acceptatielijst en knooppuntverbinding controleren

Voer de volgende acties uit om het probleem op te lossen:

  • Zet de providerpods op de acceptatielijst.

  • Controleer op beleidsregels die zijn geconfigureerd om verkeer te blokkeren.

  • Zorg ervoor dat het knooppunt verbinding heeft met Microsoft Entra ID en uw sleutelkluis.

Voer de volgende stappen uit om de connectiviteit met uw Azure-sleutelkluis te testen vanaf de pod die wordt uitgevoerd op het hostnetwerk:

  1. Maak de 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. Voer kubectl exec uit om een opdracht uit te voeren in de pod die u hebt gemaakt:

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

  3. Verifiëren met behulp van uw Azure-sleutelkluis:

    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. Probeer een geheim op te halen dat al is gemaakt in uw Azure-sleutelkluis:

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

Oorzaak 3: De door de gebruiker toegewezen beheerde identiteit is onjuist in de aangepaste resource SecretProviderClass

Als u een HTTP-foutcode '400'-exemplaar tegenkomt dat vergezeld gaat van een foutbeschrijving 'Identiteit niet gevonden', is de door de gebruiker toegewezen beheerde identiteit onjuist in uw SecretProviderClass aangepaste resource. Het volledige antwoord lijkt op de volgende tekst:

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

Oplossing 3: SecretProviderClass bijwerken met behulp van de juiste waarde userAssignedIdentityID

Zoek de juiste door de gebruiker toegewezen beheerde identiteit en werk vervolgens de SecretProviderClass aangepaste resource bij om de juiste waarde in de userAssignedIdentityID parameter op te geven. Voer de volgende opdracht az aks show uit in Azure CLI om de juiste door de gebruiker toegewezen beheerde identiteit te vinden:

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

Zie de sectie Een door de gebruiker toegewezen beheerde identiteit gebruiken van het SecretProviderClass artikel Een identiteit opgeven voor toegang tot het CSI-stuurprogramma van Azure Key Vault Provider for Secrets Store voor informatie over het instellen van een aangepaste resource in YAML-indeling.

Oorzaak 4: Het Key Vault privé-eindpunt zich in een ander virtueel netwerk bevindt dan de AKS-knooppunten

Openbare netwerktoegang is niet toegestaan op azure Key Vault-niveau en de connectiviteit tussen AKS en Key Vault wordt tot stand gebracht via een privékoppeling. De AKS-knooppunten en het privé-eindpunt van de Key Vault bevinden zich echter in verschillende virtuele netwerken. In dit scenario wordt een bericht gegenereerd dat lijkt op de volgende tekst:

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

Het oplossen van het connectiviteitsprobleem is over het algemeen een proces in twee stappen:

Deze stappen worden gedetailleerder beschreven in de volgende secties.

Maak verbinding met de AKS-clusterknooppunten om te bepalen of de FQDN (Fully Qualified Domain Name) van de Key Vault wordt omgezet via een openbaar IP-adres of een privé-IP-adres. Als u het foutbericht 'Openbare netwerktoegang is uitgeschakeld en aanvraag is niet van een vertrouwde service of via een goedgekeurde privékoppeling' ontvangt, wordt het Key Vault eindpunt waarschijnlijk omgezet via een openbaar IP-adres. Voer de opdracht nslookup uit om dit scenario te controleren:

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

Als de FQDN wordt omgezet via een openbaar IP-adres, ziet de uitvoer van de opdracht eruit als de volgende tekst:

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

Maak in dit geval een virtuele netwerkkoppeling voor het virtuele netwerk van het AKS-cluster op het niveau van de privé-DNS-zone. (Er wordt al automatisch een koppeling naar een virtueel netwerk gemaakt voor het virtuele netwerk van de Key Vault privé-eindpunt.)

Voer de volgende stappen uit om de koppeling naar het virtuele netwerk te maken:

  1. Zoek en selecteer Privé-DNS zones in de Azure Portal.

  2. Selecteer in de lijst met privé-DNS-zones de naam van uw privé-DNS-zone. In dit voorbeeld is de privé-DNS-zone privatelink.vaultcore.azure.net.

  3. Zoek in het navigatiedeelvenster van de privé-DNS-zone de kop Instellingen en selecteer vervolgens Virtuele netwerkkoppelingen.

  4. Selecteer Toevoegen in de lijst met virtuele netwerkkoppelingen.

  5. Vul op de pagina Koppeling virtueel netwerk toevoegen de volgende velden in.

    Veldnaam Actie
    Koppelingsnaam Voer een naam in die u wilt gebruiken voor de koppeling naar het virtuele netwerk.
    Abonnement Selecteer de naam van het abonnement dat u de koppeling naar het virtuele netwerk wilt bevatten.
    Virtueel netwerk Selecteer de naam van het virtuele netwerk van het AKS-cluster.

  6. Klik op de OK-knop.

Nadat u de procedure voor het maken van de koppeling hebt voltooid, voert u de nslookup opdracht uit. De uitvoer moet nu lijken op de volgende tekst met een meer directe DNS-resolutie:

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

Nadat de koppeling naar het virtuele netwerk is toegevoegd, moet de FQDN kunnen worden omgezet via een privé-IP-adres.

Stap 2: peering van virtuele netwerken tussen virtuele netwerken toevoegen

Als u een privé-eindpunt gebruikt, hebt u waarschijnlijk openbare toegang op Key Vault niveau uitgeschakeld. Daarom bestaat er geen verbinding tussen AKS en de Key Vault. U kunt die configuratie testen met behulp van de volgende Netcat-opdracht (nc):

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

Als er geen verbinding beschikbaar is tussen AKS en de Key Vault, ziet u uitvoer die lijkt op de volgende tekst:

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

Als u connectiviteit tot stand wilt brengen tussen AKS en de Key Vault, voegt u peering van virtuele netwerken toe tussen de virtuele netwerken door de volgende stappen uit te voeren:

  1. Ga naar de Azure Portal.

  2. Gebruik een van de volgende opties om de instructies te volgen in de sectie Peer voor virtueel netwerk maken van de zelfstudie: Virtuele netwerken verbinden met peering van virtuele netwerken met behulp van het artikel Azure Portal om de virtuele netwerken te koppelen en te controleren of de virtuele netwerken zijn verbonden (aan het ene uiteinde):

    • Ga naar uw virtuele AKS-netwerk en peer het met het virtuele netwerk van het Key Vault privé-eindpunt.

    • Ga naar het virtuele netwerk van het Key Vault privé-eindpunt en koppel dit aan het virtuele AKS-netwerk.

  3. Zoek en selecteer in de Azure Portal de naam van het andere virtuele netwerk (het virtuele netwerk waarnaar u in de vorige stap een peer hebt ingesteld).

  4. Zoek in het navigatiedeelvenster van het virtuele netwerk de kop Instellingen en selecteer vervolgens Peerings.

  5. Controleer op de pagina peering van het virtuele netwerk of de kolom Naam de peeringkoppelingsnaam bevat van het externe virtuele netwerk dat u in stap 2 hebt opgegeven. Zorg er ook voor dat de peeringstatuskolom voor die peeringkoppeling de waarde Verbonden heeft.

Nadat u deze procedure hebt voltooid, kunt u de Netcat-opdracht opnieuw uitvoeren. De DNS-resolutie en connectiviteit tussen AKS en de Key Vault moeten nu slagen. Zorg er ook voor dat de Key Vault geheimen zijn gekoppeld en werken zoals verwacht, zoals wordt weergegeven in de volgende uitvoer:

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

Oplossing 4b: Foutcode 403 oplossen

U kunt foutcode 403 oplossen door de sectie HTTP 403: Onvoldoende machtigingen van het naslagartikel Foutcodes voor Azure Key Vault REST API te raadplegen.

Oorzaak 5: Het secrets-store.csi.k8s.io stuurprogramma ontbreekt in de lijst met geregistreerde CSI-stuurprogramma's

Als u het volgende foutbericht ontvangt over een ontbrekend secrets-store.csi.k8s.io stuurprogramma in de pod-gebeurtenissen, worden de pods voor het CSI-stuurprogramma van Secrets Store niet uitgevoerd op het knooppunt waarin de toepassing wordt uitgevoerd:

Waarschuwing FailedMount 42s (x12 over 8m56s) kubelet, akswin000000 MountVolume.SetUp mislukt voor volume "secrets-store01-inline" : kubernetes.io/csi: mounter. SetUpAt kan de CSI-client niet ophalen: stuurprogrammanaam secrets-store.csi.k8s.io niet gevonden in de lijst met geregistreerde CSI-stuurprogramma's

Oplossing 5a: Het CSI-stuurprogramma voor geheimenarchief installeren

Als u de Key Vault provider hebt geïnstalleerd met behulp van implementatiemanifesten, volgt u de instructies voor het installeren van het CSI-stuurprogramma van Secrets Store.

Oplossing 5b: Implementeer het CSI-stuurprogramma en Key Vault-provider opnieuw door taint-tolerantie toe te voegen

Als u het CSI-stuurprogramma voor geheimenopslag al hebt geïmplementeerd, controleert u of het knooppunt is besmet. Als het knooppunt is aangetast, implementeert u het CSI-stuurprogramma van Secrets Store en Key Vault provider opnieuw door tolerantie toe te voegen voor de taints.

Oplossing 5c: (alleen Windows) Helm-configuratiewaarden gebruiken bij het installeren van het Secrets Store CSI-stuurprogramma en Key Vault-provider

Als uw toepassing wordt uitgevoerd op een Windows-knooppunt, installeert u het Secrets Store CSI-stuurprogramma en Key Vault provider op Windows-knooppunten met behulp van de Helm-configuratiewaarden.

Oorzaak 6: Het stuurprogramma kan niet communiceren met de provider

Als u het volgende foutbericht ontvangt in de logboeken of gebeurtenissen, kan het stuurprogramma niet communiceren met de provider:

Waarschuwing FailedMount 85s (x10 over 5m35s) kubelet, aks-default-28951543-vmss0000000 MountVolume.SetUp mislukt voor 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-store-inline-user-msi, errorr: failed to provider binary azure, fout: stat /etc/kubernetes/secrets-store-csi-providers/azure/provider-azure: no such file or directory

Oplossing 6a: (Providerversies die ouder zijn dan versie 0.0.9) Zorg ervoor dat providerpods op alle knooppunten worden uitgevoerd

Als uw geïnstalleerde Key Vault providerversie ouder is dan versie 0.0.9, controleert u of de providerpods op alle knooppunten worden uitgevoerd.

Oplossing 6b: (Providerversie 0.0.9 en hoger) Gebruik gRPC voor providercommunicatie

Als u Key Vault providerversie 0.0.9 of een latere versie hebt geïnstalleerd, configureert u het stuurprogramma om met de provider te communiceren met behulp van gRPC.

Oorzaak 7: Het CSI-stuurprogramma kan het Kubernetes-geheim niet maken

Als u het volgende foutbericht ontvangt in de container secret-store in het CSI-stuurprogramma, hebt u de clusterrol op basis van op rollen gebaseerd toegangsbeheer (RBAC) en de clusterrolbinding niet geïnstalleerd. De clusterrol en de clusterrolbinding zijn nodig voor het CSI-stuurprogramma om de gekoppelde inhoud te synchroniseren als een Kubernetes-geheim.

E0610 22:27:02.283100 1 secretproviderclasspodstatus_controller.go:325] "failed to create Kubernetes secret" err="secrets is forbidden: User \"system:serviceaccount:default:secrets-store-csi-driver\" cannot create resource \"secrets\" in API group \"\" in de naamruimte \"default\"" spc="default/azure-linux" pod="default/busybox-linux-5f479855f7-jvfw4" secret="default/dockerconfig" spcps="default/busybox-linux-5f479855f7-jvfw4-default-azure-linux"

Oplossing 7: Installeer de vereiste clusterrol en clusterrolbinding

Wanneer u het CSI-stuurprogramma en de Key Vault provider installeert of upgradet met behulp van Helm-grafieken van de GitHub-opslagplaats secrets-store-csi-driver-provider-azure, stelt u de secrets-store-csi-driver.syncSecret.enabled Helm-parameter in op true. Met deze configuratiewijziging installeert u de vereiste clusterrol en clusterrolbinding.

Voer de volgende kubectl get opdrachten uit om te controleren of de clusterrol- en clusterrolbinding zijn geïnstalleerd:

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

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

Oorzaak 8: De aanvraag is niet geverifieerd

De aanvraag is niet geverifieerd voor Key Vault, zoals wordt aangegeven door de foutcode '401'.

Oplossing 8: Foutcode 401 oplossen

U kunt foutcode 401 oplossen door de sectie HTTP 401: Niet-geverifieerde aanvraag van het artikel Naslaginformatie over AZURE Key Vault REST API-foutcodes te raadplegen.

Oorzaak 9: het aantal aanvragen overschrijdt het opgegeven maximum

Het aantal aanvragen overschrijdt het opgegeven maximum voor de periode, zoals wordt aangegeven door een foutcode '429'.

Oplossing 9: Problemen met foutcode 429 oplossen

Probleemoplossing voor foutcode '429' door de sectie 'HTTP 429: Te veel aanvragen' van het artikel Azure Key Vault REST API-foutcodes te raadplegen.

Disclaimerinformatie van derden

De producten van derden die in dit artikel worden vermeld, worden vervaardigd door bedrijven die onafhankelijk zijn van Microsoft. Microsoft verleent dan ook geen enkele garantie, impliciet noch anderszins, omtrent de prestaties of de betrouwbaarheid van deze producten.

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Feedback-community van Azure.