Risolvere i problemi del componente aggiuntivo Provider di segreti di Azure Key Vault nel servizio Azure Kubernetes

Articolo
12/13/2024

Questo articolo illustra come risolvere i problemi che possono verificarsi quando si usa il componente aggiuntivo Provider di segreti di Azure Key Vault in servizio Azure Kubernetes (servizio Azure Kubernetes).

Note

Questo articolo si applica alla versione del componente aggiuntivo gestito del servizio Azure Kubernetes del provider di segreti di Azure Key Vault. Se si usa la versione helm installata (autogestita), passare alla documentazione di GitHub del provider di Azure Key Vault per l'archivio segreti CSI Driver .

Prerequisiti

Interfaccia della riga di comando di Azure
Lo strumento kubectl kubernetes (per installare kubectl usando l'interfaccia della riga di comando di Azure, eseguire il comando az aks install-cli).
Componente aggiuntivo del driver CSI dell'archivio segreti Kubernetes abilitato nel cluster del servizio Azure Kubernetes
Strumento URL client (curl)
Strumento da riga di comando Netcat (nc) per le connessioni TCP

Elenco di controllo per la risoluzione dei problemi

Passaggio 1: Verificare che il componente aggiuntivo Provider di segreti di Azure Key Vault sia abilitato nel cluster

Eseguire il comando az aks show per verificare che il componente aggiuntivo sia abilitato nel cluster:

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

L'output del comando dovrebbe essere simile al testo seguente:

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

Se il enabled flag viene visualizzato come false nell'output precedente, il componente aggiuntivo Provider di segreti di Azure Key Vault non è abilitato nel cluster. In questo caso, fare riferimento alla documentazione di GitHub del provider di Azure Key Vault per l'archivio di segreti CSI driver per altri problemi.

Se il enabled flag viene visualizzato come true nell'output precedente, il componente aggiuntivo Provider di segreti di Azure Key Vault è abilitato nel cluster. In questo caso, andare ai passaggi successivi in questo articolo.

Passaggio 2: Controllare i log del provider dell'archivio segreti e dei pod del driver CSI

I log dei componenti aggiuntivi del provider di segreti di Azure Key Vault vengono generati sia da provider che da pod driver. Per risolvere i problemi che interessano il provider o il driver, esaminare i log del pod in esecuzione nello stesso nodo del pod dell'applicazione.

Eseguire il comando kubectl get per trovare i pod del provider dell'archivio segreti e del driver CSI eseguiti nello stesso nodo in cui viene eseguito il pod dell'applicazione:
```
kubectl get pod -l 'app in (secrets-store-provider-azure, secrets-store-csi-driver)' -n kube-system -o wide
```
Eseguire il comando kubectl logs per visualizzare i log dal pod del provider dell'archivio segreti:
```
kubectl logs -n kube-system <provider-pod-name> --since=1h | grep ^E
```
Eseguire il comando kubectl logs per visualizzare i log dal pod del driver CSI dell'archivio segreti:
```
kubectl logs -n kube-system <csi-driver-pod-name> -c secrets-store --since=1h | grep ^E
```

Dopo aver raccolto i log del provider dell'archivio segreti e dei pod del driver CSI, analizzare questi log in base alle cause indicate nelle sezioni seguenti per identificare il problema e la soluzione corrispondente.

Note

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

Causa 1: non è stato possibile recuperare il token dell'insieme di credenziali delle chiavi

È possibile che venga visualizzata la voce di errore seguente nei log o nei messaggi di evento:

Avviso FailedMount 74s kubelet MountVolume.SetUp non riuscito per il 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 NMI (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 di identità dei pod di Microsoft Entra.

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

È possibile che venga visualizzata la voce di errore seguente nei log o nei messaggi di evento:

E1029 17:37:42.461313 1 server.go:54] non è riuscito a elaborare la richiesta di montaggio, errore: keyvault. BaseClient#GetSecret: Richiesta di invio non riuscita: 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 questo traffico o se si verificano problemi di rete nel nodo.

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

Per risolvere il problema, eseguire le azioni seguenti:

Inserire i pod del provider nell'elenco elementi consentiti.
Verificare la presenza di criteri configurati per bloccare il traffico.
Assicurarsi che il nodo disponga della connettività all'ID Microsoft Entra 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:

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

Eseguire kubectl exec per eseguire un comando nel pod creato:
```
kubectl exec --stdin --tty  curl -- sh
```

Eseguire l'autenticazione con 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'

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 codice di errore HTTP "400" che è accompagnato 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'utente nell'articolo Fornire un'identità per accedere al provider di Azure Key Vault per il driver CSI dell'archivio segreti.

Causa 4: l'endpoint privato di 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 Azure Key Vault 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 dell'insieme di credenziali delle chiavi 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"}

Soluzione 4a: Configurare un collegamento di rete virtuale e il peering di rete virtuale per connettere le reti virtuali

La correzione del problema di connettività è in genere un processo in due passaggi:

Creare un collegamento di rete virtuale per la rete virtuale del cluster servizio Azure Kubernetes a livello di zona DNS di Azure privato.
Aggiungere il peering di rete virtuale tra la rete virtuale del cluster servizio Azure Kubernetes e la rete virtuale dell'endpoint privato di Key Vault.

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

Passaggio 1: Creare il collegamento alla rete virtuale

Connettersi ai nodi del cluster del servizio Azure Kubernetes per determinare se il nome di dominio completo (FQDN) dell'insieme di credenziali delle chiavi viene risolto tramite un indirizzo IP pubblico o un indirizzo IP privato. Se viene visualizzato il messaggio di errore "L'accesso alla rete pubblica è disabilitato e la richiesta non proviene da un servizio attendibile né tramite un collegamento privato approvato", l'endpoint dell'insieme di credenziali delle chiavi viene probabilmente 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 è 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 servizio Azure Kubernetes a livello di zona DNS privato. Un collegamento di rete virtuale viene già creato automaticamente per la rete virtuale dell'endpoint privato di Key Vault.

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

Nella portale di Azure cercare e selezionare DNS privato zone.
Nell'elenco delle zone DNS private selezionare il nome della zona DNS privata. In questo esempio la zona DNS privata è privatelink.vaultcore.azure.net.
Nel riquadro di spostamento della zona DNS privata individuare l'intestazione Impostazioni e quindi selezionare Collegamenti di rete virtuale.
Nell'elenco dei collegamenti di rete virtuale selezionare Aggiungi.

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

Nome 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 alla rete virtuale.
Rete virtuale	Selezionare il nome della rete virtuale del cluster del servizio Azure Kubernetes.

Selezionare il 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. Di conseguenza, non esiste alcuna connettività tra il servizio Azure Kubernetes e l'insieme di credenziali delle chiavi. È possibile testare la configurazione usando il comando Netcat (nc) seguente:

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

Se la connettività non è disponibile tra il servizio Azure Kubernetes e l'insieme di credenziali delle chiavi, 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 servizio Azure Kubernetes e Key Vault, aggiungere il peering di rete virtuale tra le reti virtuali seguendo questa procedura:

Vai al portale di Azure.
Usare una delle opzioni seguenti per seguire le istruzioni della sezione Creare un peer di rete virtuale dell'esercitazione: Connettere reti virtuali con 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'unica estremità):
- Passare alla rete virtuale del servizio Azure Kubernetes ed eseguirne il peering alla rete virtuale dell'endpoint privato di Key Vault.
- Passare alla rete virtuale dell'endpoint privato di Key Vault ed eseguire il peering alla rete virtuale del servizio Azure Kubernetes.
Nella portale di Azure cercare e selezionare il nome dell'altra rete virtuale (la rete virtuale a cui è stato eseguito il peering nel passaggio precedente).
Nel riquadro di spostamento della rete virtuale individuare l'intestazione Impostazioni e quindi selezionare Peering.
Nella pagina peering di 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 un 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 l'insieme di credenziali delle chiavi dovrebbero ora avere esito positivo. Assicurarsi inoltre che i segreti di 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 codici di errore dell'API REST di Azure Key Vault.

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

Se viene visualizzato il seguente messaggio di errore relativo a un driver mancante secrets-store.csi.k8s.io negli eventi del pod, i pod del driver CSI dell'archivio segreti non vengono eseguiti 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 trovato nell'elenco dei driver CSI registrati

Soluzione 5: Risolvere i problemi del pod del driver CSI dell'archivio segreti in esecuzione nello stesso nodo

Recuperare lo stato del pod del driver CSI dell'archivio segreto in esecuzione nello stesso nodo eseguendo il comando seguente:

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

Se lo stato del pod non Running è o nessuno dei contenitori in questo pod non è nello Ready stato, procedere con la verifica dei log per questo pod seguendo i passaggi descritti in Controllare i log del provider dell'archivio segreti e dei pod del driver CSI.

Causa 6: SecretProviderClass non trovato

Quando si descrive il pod dell'applicazione, potrebbe essere visualizzato l'evento seguente:

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

Questo evento indica che il SecretProviderClass riferimento nella specifica del volume del pod non esiste nello stesso spazio dei nomi del pod dell'applicazione.

Soluzione 6a: Creare la risorsa SecretProviderClass mancante

Assicurarsi che la SecretProviderClass risorsa a cui si fa riferimento nella specifica del volume del pod esista nello stesso spazio dei nomi in cui è in esecuzione il pod dell'applicazione.

Soluzione 6b: Modificare la specifica del volume del pod dell'applicazione per fare riferimento al nome di risorsa SecretProviderClass corretto

Modificare la specifica del volume del pod dell'applicazione per fare riferimento al nome della risorsa corretto SecretProviderClass :

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

Causa 7: La richiesta non è autenticata

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

Soluzione 7: 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 codici di errore dell'API REST di Azure Key Vault.

Causa 8: il numero di richieste supera il valore massimo indicato

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

Soluzione 8: 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 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.

Condividi tramite