Connettere il provider di identità di Azure al driver CSI dell'archivio di segreti di Azure Key Vault nel servizio Azure Kubernetes

Informazioni su come connettersi a Azure Key Vault con il driver CSI di Archivio segreti in un cluster del Servizio Azure Kubernetes con l'aiuto di Connettore di servizi. In questo articolo vengono completate le attività seguenti:

Prerequisiti

• Un account Azure con una sottoscrizione attiva. Creare un account gratuitamente.
• Interfaccia della riga di comando di Azure. Accedere usando il comando az login.
• Docker e kubectl. Per installare kubectl in locale, usare il comando az aks install-cli.
• Conoscenza di base dei contenitorei e del servizio Azure Kubernetes. Iniziare dalla preparazione di un'applicazione per il servizio Azure Kubernetes.
• Prima di iniziare, assicurarsi di completare i passaggi descritti in Usare il provider di Azure Key Vault per il driver CSI dell'archivio segreti in un cluster del servizio Azure Kubernetes (AKS) per abilitare il driver CSI dell'archivio segreti di Azure Key Vault nel cluster del servizio Azure Kubernetes.

Configurazione iniziale

1. Se si usa il connettore di servizi per la prima volta, iniziare eseguendo il comando az provider register per registrare i provider di risorse del connettore di servizi e della configurazione Kubernetes.

   az provider register -n Microsoft.ServiceLinker
   

   az provider register -n Microsoft.KubernetesConfiguration
   

   Suggerimento

   È possibile verificare se questi provider di risorse sono già stati registrati eseguendo i comandi az provider show -n "Microsoft.ServiceLinker" --query registrationState e az provider show -n "Microsoft.KubernetesConfiguration" --query registrationState.

2. Facoltativamente, usare il comando dell'interfaccia della riga di comando di Azure per ottenere un elenco dei servizi di destinazione supportati per il cluster del servizio Azure Kubernetes.

   az aks connection list-support-types --output table
   

Creare una connessione al servizio nel servizio Azure Kubernetes con connettore di servizi

È possibile creare una connessione al servizio ad Azure Key Vault usando il portale di Azure o l'interfaccia della riga di comando di Azure.

Testare la connessione

Clonare il repository di esempio e distribuire i file manifesto

1. Clonare il repository di esempio usando il comando git clone.

   git clone https://github.com/Azure-Samples/serviceconnector-aks-samples.git
   

2. Passare all'esempio di provider CSI di Azure Key Vault.

   cd serviceconnector-aks-samples/azure-keyvault-csi-provider
   

3. Nel file secret_provider_class.yaml sostituire i segnaposto seguenti con le informazioni di Azure Key Vault:

   • Sostituire <AZURE_KEYVAULT_NAME> con il nome dell'insieme di credenziali delle chiavi creato e connesso.
   • Sostituire <AZURE_KEYVAULT_TENANTID> con l'ID tenant dell'insieme di credenziali delle chiavi.
   • Sostituisci <AZURE_KEYVAULT_CLIENTID> con l'ID client Identity del componente aggiuntivo azureKeyvaultSecretsProvider.
   • Sostituire <KEYVAULT_SECRET_NAME> con il segreto dell'insieme di credenziali delle chiavi creato. Ad esempio: ExampleSecret.

4. Distribuire il CRD SecretProviderClass usando il comando kubectl apply.

   kubectl apply -f secret_provider_class.yaml
   

5. Distribuire il file manifesto Pod usando il comando kubectl apply.

   Il comando crea un pod denominato sc-demo-keyvault-csi nello spazio dei nomi predefinito del cluster del servizio Azure Kubernetes.

   kubectl apply -f pod.yaml
   

Verificare la connessione

1. Verificare che il pod sia stato creato correttamente usando il comando kubectl get.

   kubectl get pod/sc-demo-keyvault-csi
   

   Dopo l'avvio del pod, è disponibile il contenuto montato nel percorso del volume specificato nella distribuzione YAML.

2. Visualizzare i segreti contenuti nell'archivio segreti usando il comando kubectl exec.

   kubectl exec sc-demo-keyvault-csi -- ls /mnt/secrets-store/
   

3. Visualizzare un segreto usando il comando kubectl exec.

   Questo comando di esempio mostra un segreto di test denominato ExampleSecret.

   kubectl exec sc-demo-keyvault-csi -- cat /mnt/secrets-store/ExampleSecret
   

Prerequisiti per il driver CSI con identità del carico di lavoro

• Prima di iniziare, assicurarsi di completare i passaggi descritti in Usare il provider di Azure Key Vault per il driver CSI dell'archivio segreti in un cluster del servizio Azure Kubernetes (AKS) per abilitare il driver CSI dell'archivio segreti di Azure Key Vault nel cluster del servizio Azure Kubernetes.
• L'ID dei carichi di lavoro di Microsoft Entra supporta sia i cluster Windows che Linux.

Accesso con un ID carico di lavoro Microsoft Entra

Un ID dei carichi di lavoro di Microsoft Entra è un'identità usata da un'applicazione o da un servizio per autenticarsi con altri servizi Azure, ad esempio i carichi di lavoro nel software. Il Secrets Store CSI Driver si integra con le funzionalità native di Kubernetes per federarsi con provider di identità esterni.

In questo modello di sicurezza il cluster del servizio Azure Kubernetes funge da emittente del token. Quando il driver CSI dell'archivio segreti monta il volume, richiede un token dell'account del servizio Kubernetes e il provider di Azure Key Vault scambia tale token per ottenere un token Microsoft Entra. L'applicazione legge i file montati e non richiede la libreria client di Identità di Azure o la Libreria di Autenticazione Microsoft (MSAL) per questo flusso di montaggio del volume. Se l'applicazione richiede in modo indipendente Microsoft Entra token per chiamare LE API protette, usare Azure Identity o MSAL nell'applicazione.

Configurare l'identità del carico di lavoro

1. Impostare la sottoscrizione usando il comando az account set.

   export SUBSCRIPTION_ID=<subscription id>
   export RESOURCE_GROUP=<resource group name>
   export UAMI=<name for user assigned identity>
   export KEYVAULT_NAME=<existing keyvault name>
   export CLUSTER_NAME=<aks cluster name>
   
   az account set --subscription $SUBSCRIPTION_ID
   

2. Creare un'identità gestita usando il comando az identity create.

   Note

   Questo passaggio presuppone che sia presente un cluster del servizio Azure Kubernetes esistente con l'identità del carico di lavoro abilitata. Se l'identità del carico di lavoro in AKS non è abilitata, vedere Abilitare l'identità del carico di lavoro in un cluster esistente di servizio Azure Kubernetes per abilitarla.

   az identity create --name $UAMI --resource-group $RESOURCE_GROUP
   
   export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group $RESOURCE_GROUP --name $UAMI --query 'clientId' -o tsv)"
   export KEYVAULT_TENANT_ID="$(az keyvault show --name $KEYVAULT_NAME --query properties.tenantId -o tsv)"
   

3. Creare un'assegnazione di ruolo che concede all'identità del carico di lavoro l'autorizzazione per accedere ai segreti, alle chiavi di accesso e ai certificati dell'insieme di credenziali delle chiavi usando il comando az role assignment create.

   Importante

   • Se si configura il Key Vault con --enable-rbac-authorization e si usa il tipo cert o key, assegnare il ruolo Key Vault Certificate User per concedere le autorizzazioni.
   • Se l'insieme di credenziali delle chiavi è impostato con --enable-rbac-authorization e si usa il tipo secret, assegnare il ruolo Key Vault Secrets User.
   • Se l'insieme di credenziali delle chiavi non è impostato con --enable-rbac-authorization, è possibile usare il comando az keyvault set-policy con il parametro --key-permissions get, --certificate-permissions get o --secret-permissions get per creare un criterio dell'insieme di credenziali delle chiavi per concedere l'accesso per chiavi, certificati o segreti. Ad esempio:

   az keyvault set-policy --name $KEYVAULT_NAME --key-permissions get --secret-permissions get --object-id <identity-object-id>
   

   export KEYVAULT_SCOPE=$(az keyvault show --name $KEYVAULT_NAME --query id -o tsv)
   
   # Example commands for a key vault with Azure RBAC enabled using `key` and `secret` types
   az role assignment create --role "Key Vault Certificate User" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE
   az role assignment create --role "Key Vault Secrets User" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE
   

4. Ottenere l'URL dell'autorità di certificazione OIDC del cluster del servizio Azure Kubernetes usando il comando az aks show.

   Note

   Questo passaggio presuppone che sia presente un cluster del servizio Azure Kubernetes esistente con l'URL dell'autorità di certificazione OIDC abilitato. Se l'URL dell'emittente OICD non è abilitato, vedere Aggiornare un cluster del servizio Azure Kubernetes con l'autorità di certificazione OIDC per abilitarlo.

   export AKS_OIDC_ISSUER="$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query "oidcIssuerProfile.issuerUrl" -o tsv)"
   echo $AKS_OIDC_ISSUER
   

5. Creare un account del servizio Kubernetes per il carico di lavoro. Aggiorna i valori di SERVICE_ACCOUNT_NAME e SERVICE_ACCOUNT_NAMESPACE con il nome del service account di Kubernetes e il relativo namespace.

   export SERVICE_ACCOUNT_NAME="workload-identity-sa"  # sample name; can be changed
   export SERVICE_ACCOUNT_NAMESPACE="default" # can be changed to namespace of your workload
   
   cat <<EOF | kubectl apply -f -
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     annotations:
       azure.workload.identity/client-id: ${USER_ASSIGNED_CLIENT_ID}
     name: ${SERVICE_ACCOUNT_NAME}
     namespace: ${SERVICE_ACCOUNT_NAMESPACE}
   EOF
   

6. Creare le credenziali di identità federate tra l'identità gestita, l'autorità emittente dell'account del servizio e l'oggetto usando il comando az identity federated-credential create.

   export FEDERATED_IDENTITY_NAME="aksfederatedidentity" # can be changed as needed
   
   az identity federated-credential create --name $FEDERATED_IDENTITY_NAME --identity-name $UAMI --resource-group $RESOURCE_GROUP --issuer ${AKS_OIDC_ISSUER} --subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}
   

7. Distribuire un SecretProviderClass usando il comando kubectl apply e lo script YAML seguente.

I parametri seguenti configurano l'accesso all'identità del carico di lavoro:

• usePodIdentity: impostare su "false" quando si usa l'identità del carico di lavoro.

• clientID: impostare su ${USER_ASSIGNED_CLIENT_ID}, l'ID client dell'identità gestita assegnata dall'utente usata per l'identità del carico di lavoro.

• cloudName: facoltativo. Lasciare vuoto per usare l'ambiente predefinito AzurePublicCloud .

• objectType: impostare sul tipo di oggetto dell'insieme di credenziali delle chiavi da montare. I valori validi sono secret, keye cert.

• tenantId: impostare sull'ID del tenant che contiene l'insieme di credenziali delle chiavi.

  cat <<EOF | kubectl apply -f -
  # This is a SecretProviderClass example using workload identity to access your key vault
  apiVersion: secrets-store.csi.x-k8s.io/v1
  kind: SecretProviderClass
  metadata:
    name: azure-kvname-wi # needs to be unique per namespace
    namespace: ${SERVICE_ACCOUNT_NAMESPACE}
  spec:
    provider: azure
    parameters:
      usePodIdentity: "false"
      clientID: "${USER_ASSIGNED_CLIENT_ID}" # Setting this to use workload identity
      keyvaultName: ${KEYVAULT_NAME}       # Set to the name of your key vault
      cloudName: ""                         # [OPTIONAL for Azure] if not provided, the Azure environment defaults to AzurePublicCloud
      objects:  |
        array:
          - |
            objectName: secret1             # Set to the name of your secret
            objectType: secret              # object types: secret, key, or cert
            objectVersion: ""               # [OPTIONAL] object versions, default to latest if empty
          - |
            objectName: key1                # Set to the name of your key
            objectType: key
            objectVersion: ""
      tenantId: "${KEYVAULT_TENANT_ID}"     # The tenant ID of the key vault
  EOF
  

  Note

  Se si usa objectAlias invece di objectName, aggiornare lo script YAML per tener conto di esso.

  Note

  Affinché SecretProviderClass funzioni correttamente, assicurarsi di popolare Azure Key Vault con segreti, chiavi o certificati prima di farvi riferimento nella sezione objects.

1. Distribuire un pod di esempio usando il comando kubectl apply e lo script YAML seguente.

   cat <<EOF | kubectl apply -f -
   # This is a sample pod definition for using SecretProviderClass and workload identity to access your key vault
   kind: Pod
   apiVersion: v1
   metadata:
     name: busybox-secrets-store-inline-wi
     namespace: ${SERVICE_ACCOUNT_NAMESPACE}
     labels:
       azure.workload.identity/use: "true"
   spec:
     serviceAccountName: ${SERVICE_ACCOUNT_NAME}
     containers:
       - name: busybox
         image: registry.k8s.io/e2e-test-images/busybox:1.29-4
         command:
           - "/bin/sleep"
           - "10000"
         volumeMounts:
         - name: secrets-store01-inline
           mountPath: "/mnt/secrets-store"
           readOnly: true
     volumes:
       - name: secrets-store01-inline
         csi:
           driver: secrets-store.csi.k8s.io
           readOnly: true
           volumeAttributes:
             secretProviderClass: "azure-kvname-wi"
   EOF
   

Convalida i segreti di Key Vault con l'identità del carico di lavoro

Dopo l'avvio del pod, il contenuto montato in /mnt/secrets-store è disponibile. Usare i comandi seguenti per convalidare i segreti e stampare un segreto di test.

1. Visualizzare i segreti contenuti nell'archivio segreti usando il comando seguente.

   kubectl exec --namespace $SERVICE_ACCOUNT_NAMESPACE busybox-secrets-store-inline-wi -- ls /mnt/secrets-store/
   

2. Visualizzare un segreto nell'archivio usando il comando seguente. Questo comando di esempio mostra il segreto secret1 di test.

   kubectl exec --namespace $SERVICE_ACCOUNT_NAMESPACE busybox-secrets-store-inline-wi -- cat /mnt/secrets-store/secret1
   

Prerequisiti per il driver CSI con identità gestita

• Prima di iniziare, assicurarsi di completare i passaggi descritti in Usare il provider di Azure Key Vault per il driver CSI dell'archivio segreti in un cluster del servizio Azure Kubernetes (AKS) per abilitare il driver CSI dell'archivio segreti di Azure Key Vault nel cluster del servizio Azure Kubernetes.

Accesso con identità gestita

Questo metodo usa l'identità gestita assegnata all'utente che AKS crea automaticamente quando si abilita il provider Azure Key Vault per il driver CSI di Secrets Store. L'identità è denominata azurekeyvaultsecretsprovider-xxxxx, viene archiviata nel gruppo di risorse del nodo e viene assegnata al set di scalabilità di macchine virtuali.

Un'identità gestita Microsoft Entra consente a una risorsa o a un carico di lavoro di Azure di eseguire l'autenticazione ai servizi che supportano l'autenticazione Microsoft Entra senza archiviare le credenziali nel codice. Concedere a questa identità le autorizzazioni del piano dati di Key Vault appropriate tramite RBAC di Azure o i criteri di accesso, quindi utilizzarla nei passaggi seguenti.

Configurare identità gestita

1. Accedere all'insieme di credenziali delle chiavi usando il comando az aks show e l'identità gestita assegnata dall'utente creata dal componente aggiuntivo. È necessario anche recuperare l'identità di clientId, che verrà utilizzata nei passaggi successivi durante la creazione di un SecretProviderClass.

   export RESOURCE_GROUP=<resource-group>
   export CLUSTER_NAME=<cluster-name>
   export KEYVAULT_NAME=<key-vault-name>
   
   export IDENTITY_OBJECT_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query addonProfiles.azureKeyvaultSecretsProvider.identity.objectId -o tsv)
   export USER_ASSIGNED_CLIENT_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId -o tsv)
   

   In alternativa, è possibile creare una nuova identità gestita e assegnarla al set di scalabilità di macchine virtuali o a ogni istanza di macchina virtuale nel set di disponibilità.

   export USER_ASSIGNED_IDENTITY_NAME=<identity-name>
   
   az identity create --resource-group $RESOURCE_GROUP --name $USER_ASSIGNED_IDENTITY_NAME
   
   export IDENTITY_RESOURCE_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $USER_ASSIGNED_IDENTITY_NAME --query id -o tsv)
   export IDENTITY_OBJECT_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $USER_ASSIGNED_IDENTITY_NAME --query principalId -o tsv)
   export USER_ASSIGNED_CLIENT_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $USER_ASSIGNED_IDENTITY_NAME --query clientId -o tsv)
   

   Per un cluster basato su set di scalabilità di macchine virtuali, assegnare l'identità al set di scalabilità di macchine virtuali.

   az vmss identity assign --resource-group <node-resource-group> --name <agent-pool-vmss> --identities $IDENTITY_RESOURCE_ID
   

   Per un cluster basato su set di disponibilità, assegnare l'identità a ogni istanza di macchina virtuale nel set di disponibilità.

   az vm identity assign --resource-group <node-resource-group> --name <agent-pool-vm> --identities $IDENTITY_RESOURCE_ID
   

2. Creare un'assegnazione di ruolo che concede all'identità l'autorizzazione per accedere ai segreti, alle chiavi di accesso e ai certificati dell'insieme di credenziali delle chiavi usando il comando az role assignment create.

   Importante

   • Se si configura il Key Vault con --enable-rbac-authorization e si usa il tipo cert o key, assegnare il ruolo Key Vault Certificate User.
   • Se l'insieme di credenziali delle chiavi è impostato con --enable-rbac-authorization e si usa il tipo secret, assegnare il ruolo Key Vault Secrets User.
   • Se l'insieme di credenziali delle chiavi non è impostato con --enable-rbac-authorization, è possibile usare il comando az keyvault set-policy con il parametro --key-permissions get, --certificate-permissions get o --secret-permissions get per creare un criterio dell'insieme di credenziali delle chiavi per concedere l'accesso per chiavi, certificati o segreti. Ad esempio:

   az keyvault set-policy --name $KEYVAULT_NAME --key-permissions get --secret-permissions get --object-id $IDENTITY_OBJECT_ID
   

   export KEYVAULT_SCOPE=$(az keyvault show --name $KEYVAULT_NAME --query id -o tsv)
   
   # Example commands for a key vault with Azure RBAC enabled using `key` and `secret` types
   az role assignment create --role "Key Vault Certificate User" --assignee-object-id $IDENTITY_OBJECT_ID --assignee-principal-type ServicePrincipal --scope $KEYVAULT_SCOPE
   az role assignment create --role "Key Vault Secrets User" --assignee-object-id $IDENTITY_OBJECT_ID --assignee-principal-type ServicePrincipal --scope $KEYVAULT_SCOPE
   

3. Creare un SecretProviderClass usando l'ID client dell'identità. Assicurarsi di utilizzare i propri valori per gli oggetti da recuperare dal Key Vault.

   I parametri seguenti configurano l'accesso all'identità gestita assegnata dall'utente:

   • usePodIdentity: impostare su "false" quando si usa l'identità gestita.
   • useVMManagedIdentity: Impostare su "true" per abilitare la modalità di identità gestita.
   • userAssignedIdentityID: impostare sull'ID client dell'identità gestita assegnata dall'utente.
   • tenantId: impostare sull'ID del tenant che contiene l'insieme di credenziali delle chiavi.

   export KEYVAULT_TENANT_ID=$(az keyvault show --name $KEYVAULT_NAME --query properties.tenantId -o tsv)
   
   cat <<EOF > secretproviderclass.yaml
   # This is a SecretProviderClass example using user-assigned identity to access your key vault
   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: azure-kvname-user-msi
   spec:
     provider: azure
     parameters:
       usePodIdentity: "false"
       useVMManagedIdentity: "true"          # Set to true for using managed identity
       userAssignedIdentityID: ${USER_ASSIGNED_CLIENT_ID} # Set the client ID of the user-assigned managed identity to use
       keyvaultName: ${KEYVAULT_NAME}         # Set to the name of your key vault
       cloudName: ""                         # [OPTIONAL for Azure] if not provided, the Azure environment defaults to AzurePublicCloud
       objects:  |
         array:
           - |
             objectName: secret1
             objectType: secret              # object types: secret, key, or cert
             objectVersion: ""               # [OPTIONAL] object versions, default to latest if empty
           - |
             objectName: key1
             objectType: key
             objectVersion: ""
       tenantId: ${KEYVAULT_TENANT_ID}       # The tenant ID of the key vault
   EOF
   

   Note

   Se si usa objectAlias invece di objectName, assicurarsi di aggiornare lo script YAML.

   Note

   Affinché SecretProviderClass funzioni correttamente, assicurarsi di popolare Azure Key Vault con segreti, chiavi o certificati prima di farvi riferimento nella sezione objects.

4. Applicare l'oggetto SecretProviderClass al cluster usando il comando kubectl apply.

   kubectl apply -f secretproviderclass.yaml
   

5. Creare un manifesto del pod denominato pod.yaml usando il comando seguente.

   cat <<EOF > pod.yaml
   # This is a sample pod definition for using SecretProviderClass and the user-assigned identity to access your key vault
   kind: Pod
   apiVersion: v1
   metadata:
     name: busybox-secrets-store-inline-user-msi
   spec:
     containers:
       - name: busybox
         image: registry.k8s.io/e2e-test-images/busybox:1.29-4
         command:
           - "/bin/sleep"
           - "10000"
         volumeMounts:
         - name: secrets-store01-inline
           mountPath: "/mnt/secrets-store"
           readOnly: true
     volumes:
       - name: secrets-store01-inline
         csi:
           driver: secrets-store.csi.k8s.io
           readOnly: true
           volumeAttributes:
             secretProviderClass: "azure-kvname-user-msi"
   EOF
   

6. Applicare il pod al cluster usando il comando kubectl apply.

   kubectl apply -f pod.yaml
   

Convalida i segreti di Key Vault usando un'identità gestita

Dopo l'avvio del pod, il contenuto montato in /mnt/secrets-store è disponibile. Usare i comandi seguenti per convalidare i segreti e stampare un segreto di test.

1. Visualizzare i segreti contenuti nell'archivio segreti usando il comando seguente.

   kubectl exec busybox-secrets-store-inline-user-msi -- ls /mnt/secrets-store/
   

2. Visualizzare un segreto nell'archivio usando il comando seguente. Questo comando di esempio mostra il segreto secret1 di test.

   kubectl exec busybox-secrets-store-inline-user-msi -- cat /mnt/secrets-store/secret1
   

Ottenere certificati e chiavi

La progettazione di Azure Key Vault distingue in modo netto le chiavi, i segreti e i certificati. Le funzionalità del certificato del servizio Key Vault sono progettate per usare le funzionalità di chiave e segreto. Quando si crea un certificato dell'insieme di credenziali delle chiavi, viene creata una chiave indirizzabile e un segreto con lo stesso nome. Questa chiave consente operazioni di autenticazione e il segreto consente il recupero del valore del certificato come segreto.

Un certificato Key Vault contiene inoltre metadati del certificato x509 pubblico. L'insieme di credenziali delle chiavi archivia i componenti pubblici e privati del certificato in un segreto. È possibile ottenere ogni singolo componente specificando objectType in SecretProviderClass. La tabella seguente mostra i valori objectType che è possibile specificare in SecretProviderClass per recuperare diversi componenti di un certificato dell'insieme di credenziali delle chiavi e cosa restituisce ciascun valore:

Disabilitare il componente aggiuntivo nei cluster esistenti

Disabilitare la funzionalità driver CSI dell'archivio chiavi di Azure per il provider di Azure Key Vault in un cluster esistente usando il comando az aks disable-addons con il componente aggiuntivo azure-keyvault-secrets-provider.

az aks disable-addons --addons azure-keyvault-secrets-provider --resource-group myResourceGroup --name myAKSCluster

Passaggi successivi

In questo articolo si è appreso come creare e fornire un'identità per accedere ad Azure Key Vault. L'integrazione del connettore di servizi semplifica la configurazione della connessione per i carichi di lavoro del servizio Azure Kubernetes e i servizi sottostanti di Azure. Gestisce in modo sicuro le configurazioni di autenticazione e di rete e segue le procedure consigliate per la connessione ai servizi di Azure. Per altre informazioni, vedere Usare il provider di Azure Key Vault per il driver CSI dell'archivio segreti in un cluster del servizio Azure Kubernetes e Introduzione al connettore di servizi.

Per configurare le opzioni di configurazione aggiuntive o eseguire la risoluzione dei problemi, vedere Opzioni di configurazione e risoluzione dei problemi relativi alle risorse per il provider di Azure Key Vault con il driver CSI dell'archivio segreti nel servizio Azure Kubernetes.