Condividi tramite

Risolvere i problemi relativi al provider di Key Vault di Azure per il driver CSI dell'archivio segreti

  • Articolo

Questo articolo illustra i problemi comuni che potrebbero verificarsi quando si usa il driver CSI (Microsoft Azure Key Vault Provider for Secrets Store Container Storage Interface) in servizio Azure Kubernetes (AKS). L'articolo fornisce suggerimenti per la risoluzione di questi problemi.

Prerequisiti

Elenco di controllo per la risoluzione dei problemi

I log Key Vault di Azure sono disponibili nei pod del provider e del driver. Per risolvere i problemi che interessano il provider o il driver, esaminare i log del provider o del pod del driver in esecuzione nello stesso nodo in cui viene eseguito il pod dell'applicazione.

Passaggio 1 della risoluzione dei problemi: controllare i log del provider dell'archivio segreti

Per trovare il secrets-store-provider-azure pod eseguito nello stesso nodo in cui viene eseguito il pod dell'applicazione, eseguire i comandi kubectl get e kubectl logs seguenti che selezionano l'applicazione 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

Passaggio 2 della risoluzione dei problemi: Controllare i log dei driver CSI dell'archivio segreti

Per accedere ai log del driver CSI dell'archivio segreti, eseguire gli stessi comandi del passaggio 1, ma selezionare invece l'applicazione secrets-store-csi-driver e specificare il secrets-store contenitore:

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

Nota

Se si apre una richiesta di supporto, è consigliabile includere i log pertinenti del provider di Azure Key Vault e del driver CSI dell'archivio segreti.

Causa 1: Impossibile recuperare il token dell'insieme di credenziali delle chiavi

Nei log o nei messaggi di evento potrebbe essere visualizzata la voce di errore seguente:

Avviso FailedMount 74s kubelet MountVolume.SetUp failed for 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: nmi response failed with status code: 404, err: <nil>

Questo errore si verifica perché un componente DIM (Node Managed Identity) in aad-pod-identity ha restituito un messaggio di errore relativo a una richiesta di token.

Soluzione 1: Controllare i log dei pod NMI

Per altre informazioni su questo errore e su come risolverlo, controllare i log dei pod NMI e fare riferimento alla guida alla risoluzione dei problemi relativi all'identità del pod Microsoft Entra.

Causa 2: il pod del provider non può accedere all'istanza dell'insieme di credenziali delle chiavi

Nei log o nei messaggi di evento potrebbe essere visualizzata la voce di errore seguente:

E1029 17:37:42.461313 1 server.go:54] non è riuscito a elaborare la richiesta di montaggio, errore: keyvault. BaseClient#GetSecret: Errore durante l'invio della richiesta: StatusCode=0 -- Errore originale: scadenza del contesto superata

Questo errore si verifica perché il pod del provider non può accedere all'istanza dell'insieme di credenziali delle chiavi. L'accesso potrebbe essere impedito per uno dei motivi seguenti:

  • Una regola del firewall blocca il traffico in uscita dal provider.

  • I criteri di rete configurati nel cluster del servizio Azure Kubernetes bloccano il traffico in uscita.

  • I pod del provider vengono eseguiti nella rete host. Un errore può verificarsi se un criterio blocca il traffico o se si verificano instabilità di rete nel nodo.

Soluzione 2: Controllare i criteri di rete, l'elenco di indirizzi consentiti e la connessione al nodo

Per risolvere il problema, eseguire le azioni seguenti:

  • Inserire i pod del provider nell'elenco consentiti.

  • Verificare la presenza di criteri configurati per bloccare il traffico.

  • Assicurarsi che il nodo disponga della connettività a Microsoft Entra ID e all'insieme di credenziali delle chiavi.

Per testare la connettività all'insieme di credenziali delle chiavi di Azure dal pod in esecuzione nella rete host, seguire questa procedura:

  1. Creare il 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. Eseguire kubectl exec per eseguire un comando nel pod creato:

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

  3. Eseguire l'autenticazione usando l'insieme di credenziali delle chiavi di 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. Provare a ottenere un segreto già creato nell'insieme di credenziali delle chiavi di 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>"

Causa 3: l'identità gestita assegnata dall'utente non è corretta nella risorsa personalizzata SecretProviderClass

Se si verifica un'istanza del codice di errore HTTP "400" accompagnata da una descrizione dell'errore "Identità non trovata", l'identità gestita assegnata dall'utente non è corretta nella SecretProviderClass risorsa personalizzata. La risposta completa è simile al testo seguente:

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

Soluzione 3: Aggiornare SecretProviderClass usando il valore userAssignedIdentityID corretto

Trovare l'identità gestita assegnata dall'utente corretta e quindi aggiornare la SecretProviderClass risorsa personalizzata per specificare il valore corretto nel userAssignedIdentityID parametro . Per trovare l'identità gestita assegnata dall'utente corretta, eseguire il comando az aks show seguente nell'interfaccia della riga di comando di Azure:

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

Per informazioni su come configurare una SecretProviderClass risorsa personalizzata in formato YAML, vedere la sezione Usare un'identità gestita assegnata dall'utentedell'articolo Fornire un'identità per accedere al driver CSI provider di Azure Key Vault per l'archivio segreti.

Causa 4: l'endpoint privato Key Vault si trova in una rete virtuale diversa rispetto ai nodi del servizio Azure Kubernetes

L'accesso alla rete pubblica non è consentito a livello di Key Vault di Azure e la connettività tra servizio Azure Kubernetes e Key Vault viene effettuata tramite un collegamento privato. Tuttavia, i nodi del servizio Azure Kubernetes e l'endpoint privato del Key Vault si trovano in reti virtuali diverse. Questo scenario genera un messaggio simile al testo seguente:

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 correzione del problema di connettività è in genere un processo in due passaggi:

Questi passaggi sono descritti in modo più dettagliato nelle sezioni seguenti.

Connettersi ai nodi del cluster del servizio Azure Kubernetes per determinare se il nome di dominio completo (FQDN) del Key Vault viene risolto tramite un indirizzo IP pubblico o un indirizzo IP privato. Se si riceve il messaggio di errore "Accesso alla rete pubblica disabilitato e la richiesta non proviene da un servizio attendibile né tramite un collegamento privato approvato", l'endpoint Key Vault probabilmente viene risolto tramite un indirizzo IP pubblico. Per verificare la presenza di questo scenario, eseguire il comando nslookup :

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

Se il nome di dominio completo viene risolto tramite un indirizzo IP pubblico, l'output del comando sarà simile al testo seguente:

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

In questo caso, creare un collegamento di rete virtuale per la rete virtuale del cluster del servizio Azure Kubernetes a livello di zona DNS privato. Un collegamento di rete virtuale è già stato creato automaticamente per la rete virtuale dell'endpoint privato Key Vault.

Per creare il collegamento alla rete virtuale, seguire questa procedura:

  1. Nel portale di Azure cercare e selezionare DNS privato zone.

  2. Nell'elenco delle zone DNS private selezionare il nome della zona DNS privata. In questo esempio la zona DNS privata viene privatelink.vaultcore.azure.net.

  3. Nel riquadro di spostamento della zona DNS privata individuare l'intestazione Impostazioni e quindi selezionare Collegamenti di rete virtuale.

  4. Nell'elenco dei collegamenti di rete virtuale selezionare Aggiungi.

  5. Nella pagina Aggiungi collegamento alla rete virtuale completare i campi seguenti.

    Nome del campo Azione
    Nome collegamento Immettere un nome da usare per il collegamento alla rete virtuale.
    Abbonamento. Selezionare il nome della sottoscrizione che si vuole contenere il collegamento di rete virtuale.
    Rete virtuale Selezionare il nome della rete virtuale del cluster del servizio Azure Kubernetes.

  6. Fare clic sul pulsante OK.

Dopo aver completato la procedura di creazione del collegamento, eseguire il nslookup comando . L'output dovrebbe ora essere simile al testo seguente che mostra una risoluzione DNS più diretta:

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

Dopo aver aggiunto il collegamento alla rete virtuale, il nome di dominio completo deve essere risolvibile tramite un indirizzo IP privato.

Passaggio 2: Aggiungere il peering di rete virtuale tra reti virtuali

Se si usa un endpoint privato, è probabile che l'accesso pubblico sia stato disabilitato a livello di Key Vault. Pertanto, non esiste alcuna connettività tra il servizio Azure Kubernetes e il Key Vault. È possibile testare tale configurazione usando il comando Netcat (nc) seguente:

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

Se la connettività tra il servizio Azure Kubernetes e il Key Vault non è disponibile, viene visualizzato un output simile al testo seguente:

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

Per stabilire la connettività tra il servizio Azure Kubernetes e il Key Vault, aggiungere il peering di rete virtuale tra le reti virtuali seguendo questa procedura:

  1. Andare al portale di Azure.

  2. Usare una delle opzioni seguenti per seguire le istruzioni riportate nella sezione Creare un peer di rete virtualedell'esercitazione: Connettere le reti virtuali con il peering di rete virtuale usando l'articolo portale di Azure per eseguire il peering delle reti virtuali e verificare che le reti virtuali siano connesse (da un'estremità):

    • Passare alla rete virtuale del servizio Azure Kubernetes e eseguirne il peering alla rete virtuale dell'endpoint privato Key Vault.

    • Passare alla rete virtuale dell'endpoint privato Key Vault e eseguirne il peering alla rete virtuale del servizio Azure Kubernetes.

  3. Nel portale di Azure cercare e selezionare il nome dell'altra rete virtuale (la rete virtuale a cui è stato peering nel passaggio precedente).

  4. Nel riquadro di spostamento della rete virtuale individuare l'intestazione Impostazioni e quindi selezionare Peering.

  5. Nella pagina peering della rete virtuale verificare che la colonna Nome contenga il nome del collegamento peering della rete virtuale remota specificata nel passaggio 2. Assicurarsi inoltre che la colonna Stato peering per il collegamento di peering abbia il valore Connesso.

Dopo aver completato questa procedura, è possibile eseguire di nuovo il comando Netcat. La risoluzione DNS e la connettività tra il servizio Azure Kubernetes e il Key Vault dovrebbero ora avere esito positivo. Assicurarsi inoltre che i segreti Key Vault siano montati correttamente e funzionino come previsto, come illustrato nell'output seguente:

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

Soluzione 4b: Risolvere i problemi relativi al codice di errore 403

Risolvere i problemi relativi al codice di errore "403" esaminando la sezione HTTP 403: Autorizzazioni insufficienti dell'articolo di riferimento Azure Key Vault codici errore API REST.

Causa 5: il driver secrets-store.csi.k8s.io non è presente nell'elenco dei driver CSI registrati

Se viene visualizzato il messaggio di errore seguente relativo a un driver mancante secrets-store.csi.k8s.io negli eventi del pod, i pod del driver CSI dell'archivio segreti non sono in esecuzione nel nodo in cui è in esecuzione l'applicazione:

Avviso FailedMount 42s (x12 over 8m56s) kubelet, akswin000000 MountVolume.SetUp failed for volume "secrets-store01-inline" : kubernetes.io/csi: mounter. SetUpAt non è riuscito a ottenere il client CSI: il nome del driver secrets-store.csi.k8s.io non è stato trovato nell'elenco dei driver CSI registrati

Soluzione 5a: Installare il driver CSI dell'archivio segreti

Se è stato installato il provider di Key Vault usando i manifesti di distribuzione, seguire le istruzioni per installare il driver CSI dell'archivio segreti.

Soluzione 5b: ridistribuire il driver CSI dell'archivio segreti e il provider di Key Vault aggiungendo la tolleranza di taint

Se è già stato distribuito il driver CSI dell'archivio segreti, verificare se il nodo è contaminato. Se il nodo è contaminato, ridistribuire il driver CSI dell'archivio segreti e Key Vault provider aggiungendo la tolleranza per i taints.

Soluzione 5c: (solo Windows) Usare i valori di configurazione Helm durante l'installazione del driver CSI dell'archivio segreti e del provider di Key Vault

Se l'applicazione è in esecuzione in un nodo Windows, installare il driver CSI dell'archivio segreti e il provider di Key Vault nei nodi Windows usando i valori di configurazione Helm.

Causa 6: il driver non può comunicare con il provider

Se nei log o negli eventi viene visualizzato il messaggio di errore seguente, il driver non può comunicare con il provider:

Avviso FailedMount 85s (x10 over 5m35s) kubelet, aks-default-28951543-vmss000000 MountVolume.SetUp failed for 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

Soluzione 6a: (versioni del provider precedenti alla versione 0.0.9) Assicurarsi che i pod del provider vengano eseguiti in tutti i nodi

Se la versione del provider di Key Vault installata è precedente alla versione 0.0.9, assicurarsi che i pod del provider siano in esecuzione in tutti i nodi.

Soluzione 6b: (provider versione 0.0.9 e successive) Usare gRPC per la comunicazione del provider

Se è stato installato Key Vault provider versione 0.0.9 o successiva, configurare il driver per comunicare con il provider usando gRPC.

Causa 7: il driver CSI non è in grado di creare il segreto Kubernetes

Se viene visualizzato il messaggio di errore seguente nel contenitore dell'archivio segreto nel driver CSI, non sono stati installati il ruolo del cluster controllo degli accessi in base al ruolo e l'associazione di ruoli del cluster. Il ruolo del cluster e l'associazione del ruolo del cluster sono necessari per consentire al driver CSI di sincronizzare il contenuto montato come segreto Kubernetes.

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 \"\" nello spazio dei nomi \"default\"" spc="default/azure-linux" pod="default/busybox-linux-5f479855f7-jvfw4" secret="default/dockerconfig" spcps="default/busybox-linux-5f479855f7-jvfw4-default-azure-linux"

Soluzione 7: installare il ruolo del cluster e l'associazione di ruoli del cluster necessari

Quando si installa o si aggiorna il driver CSI e il provider di Key Vault usando i grafici Helm dal repository GitHub secrets-store-csi-driver-provider-azure, impostare il secrets-store-csi-driver.syncSecret.enabled parametro Helm su true. Questa modifica di configurazione installa il ruolo del cluster e l'associazione di ruoli del cluster necessari.

Per verificare che il ruolo del cluster e l'associazione di ruoli del cluster siano installati, eseguire i comandi seguenti 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

Causa 8: la richiesta non è autenticata

La richiesta non è autenticata per Key Vault, come indicato da un codice di errore "401".

Soluzione 8: Risolvere i problemi relativi al codice di errore 401

Risolvere i problemi relativi al codice di errore "401" esaminando la sezione "HTTP 401: Richiesta non autenticata" dell'articolo di riferimento Sui codici di errore dell'API REST di Azure Key Vault.

Causa 9: il numero di richieste supera il numero massimo indicato

Il numero di richieste supera il limite massimo indicato per l'intervallo di tempo, come indicato da un codice di errore "429".

Soluzione 9: Risolvere i problemi relativi al codice di errore 429

Risolvere i problemi relativi al codice di errore "429" esaminando la sezione "HTTP 429: Troppe richieste" dell'articolo di riferimento Sui codici di errore dell'API REST di Azure Key Vault.

Dichiarazione di non responsabilità sulle informazioni di terze parti

I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.