Connectez votre fournisseur d’identité Azure au f fournisseur Azure Key Vault pour le pilote Secrets Store CSI dans AKS (Azure Kubernetes Services)

Découvrez comment vous connecter à Azure Key Vault avec le pilote CSI Secrets Store dans un cluster Azure Kubernetes Service (AKS) à l’aide de Service Connector. Dans cet article, vous allez effectuer les tâches suivantes :

Prérequis

• Compte Azure avec un abonnement actif. Créez un compte gratuitement.
• Interface de ligne de commande Azure. Connectez-vous à l’aide de la commande az login.
• Docker et kubectl. Pour installer kubectl localement, utilisez la commande az aks install-cli.
• Compréhension de base de conteneurs et d’AKS. Commencez par préparer une demande pour AKS.
• Avant de commencer, assurez-vous de terminer les étapes décrites dans Utiliser le fournisseur Azure Key Vault pour le pilote CSI du magasin de secrets dans un cluster Azure Kubernetes Service (AKS) pour activer le pilote CSI Azure Key Vault Secrets Store dans votre cluster AKS.

Configuration initiale

1. Si vous utilisez Service Connector pour la première fois, commencez par exécuter la commande az provider register pour inscrire les fournisseurs de ressources Service Connector et Kubernetes Configuration.

   az provider register -n Microsoft.ServiceLinker
   

   az provider register -n Microsoft.KubernetesConfiguration
   

   Conseil

   Vous pouvez vérifier si les fournisseurs de ressources ont déjà été inscrits en exécutant les commandes az provider show -n "Microsoft.ServiceLinker" --query registrationState et az provider show -n "Microsoft.KubernetesConfiguration" --query registrationState.

2. Si vous le souhaitez, utilisez la commande Azure CLI pour obtenir la liste des services cibles pris en charge pour le cluster AKS.

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

Créer une connexion de service dans AKS avec le connecteur de services

Vous pouvez créer une connexion de service à Azure Key Vault à l’aide du Portail Microsoft Azure ou d’Azure CLI.

Tester la connexion

Cloner l'exemple de dépôt et déployer les fichiers manifestes

1. Clonez le référentiel d’exemples à l’aide de la commande git clone.

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

2. Modifiez les répertoires vers l’exemple de fournisseur CSI Azure Key Vault.

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

3. Dans le fichier secret_provider_class.yaml, remplacez les espaces réservés suivants par les informations de votre Azure Key Vault :

   • Remplacez <AZURE_KEYVAULT_NAME> par le nom du coffre-fort de clés que vous avez créé et connecté.
   • Remplacez <AZURE_KEYVAULT_TENANTID> par l’ID de locataire du coffre de clés.
   • Remplacez <AZURE_KEYVAULT_CLIENTID> par l’ID client d’identité du azureKeyvaultSecretsProvider module complémentaire.
   • Remplacez <KEYVAULT_SECRET_NAME> par le secret du coffre-fort de clés que vous avez créé. Par exemple : ExampleSecret.

4. Déployez le CRD SecretProviderClass à l’aide de la commande kubectl apply.

   kubectl apply -f secret_provider_class.yaml
   

5. Déployez le fichier manifeste Pod à l’aide de la commande kubectl apply.

   La commande crée un pod nommé sc-demo-keyvault-csi dans l’espace de noms par défaut de votre cluster AKS.

   kubectl apply -f pod.yaml
   

Vérifier la connexion

1. Vérifiez que le pod a été créé avec succès à l’aide de la commande kubectl get.

   kubectl get pod/sc-demo-keyvault-csi
   

   Une fois le pod démarré, le contenu monté au niveau du chemin d’accès du volume spécifié dans le YAML de votre déploiement est disponible.

2. Affichez les secrets contenus dans le magasin de secrets à l'aide de la commande kubectl exec.

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

3. Afficher un secret en utilisant la commande kubectl exec.

   Cet exemple de commande montre un secret de test nommé ExampleSecret.

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

Conditions préalables pour le pilote CSI avec l’identité de charge de travail

• Avant de commencer, assurez-vous de terminer les étapes décrites dans Utiliser le fournisseur Azure Key Vault pour le pilote CSI du magasin de secrets dans un cluster Azure Kubernetes Service (AKS) pour activer le pilote CSI Azure Key Vault Secrets Store dans votre cluster AKS.
• ID de charge de travail Microsoft Entra prend en charge les clusters Windows et Linux.

Accéder avec une charge de travail Microsoft Entra ID

Une ID de charge de travail Microsoft Entra est une identité qu’une application ou un service utilise pour s’authentifier auprès d’autres services Azure, tels que les charges de travail dans les logiciels. Le pilote CSI du magasin de secrets s’intègre aux fonctionnalités Kubernetes natives pour fédérer avec des fournisseurs d’identité externes.

Dans ce modèle de sécurité, le cluster AKS agit en tant qu’émetteur de jeton. Lorsque le pilote CSI du magasin de secrets monte le volume, il demande un jeton de compte de service Kubernetes et le fournisseur Azure Key Vault échange ce jeton pour un jeton Microsoft Entra. L'application lit les fichiers montés et n'a pas besoin de la bibliothèque cliente Azure Identity ou de la Microsoft Authentication Library (MSAL) pour ce flux de montage de volume. Si l’application demande indépendamment Microsoft Entra jetons pour appeler des API protégées, utilisez Azure Identity ou MSAL dans l’application.

Configurer une identité de charge de travail

1. Définissez votre abonnement à l’aide de la commande 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. Créez une identité managée à l’aide de la commande az identity create.

   Remarque

   Cette étape suppose que vous disposez d’un cluster AKS existant, avec l’identité de charge de travail activée. Si l’identité de charge de travail n’est pas activée, consultez Activer l’identité de charge de travail sur un cluster AKS existant pour l’activer.

   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. Créez une attribution de rôle qui accorde à l’identité de charge de travail l’autorisation d’accéder aux secrets, clés d’accès et certificats Key Vault en utilisant la commande az role assignment create.

   Important

   • Si vous définissez votre key vault avec --enable-rbac-authorization et que vous utilisez key ou cert tapez, attribuez le Key Vault Certificate User rôle pour accorder des autorisations.
   • Si votre coffre de clés est défini avec --enable-rbac-authorization et que vous utilisez le type secret, attribuez le rôle Key Vault Secrets User.
   • Si votre coffre de clés n’est pas défini avec --enable-rbac-authorization, vous pouvez utiliser la commande az keyvault set-policy avec le paramètre --key-permissions get, --certificate-permissions get ou --secret-permissions get pour créer une stratégie de coffre de clés pour accorder l’accès aux clés, certificats ou secrets. Exemple :

   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. Obtenez l’URL de l’émetteur OIDC du cluster AKS à l’aide de la az aks show commande .

   Remarque

   Cette étape suppose que vous disposez d’un cluster AKS existant, avec l’URL de l’émetteur OIDC activée. Si l’URL de l’émetteur OIDC n’est pas activée, consultez Mettre à jour un cluster AKS avec l’émetteur OIDC pour l’activer.

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

5. Créez un compte de service Kubernetes pour la charge de travail. Mettez à jour les valeurs pour SERVICE_ACCOUNT_NAME et SERVICE_ACCOUNT_NAMESPACE avec le nom du compte de service Kubernetes et son espace de noms.

   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. Créez les informations d’identification d’identité fédérées entre l’identité managée, l’émetteur du compte de service et l’objet à l’aide de la commande 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. Déployez un SecretProviderClass à l’aide de la kubectl apply commande et du script YAML suivant.

Les paramètres suivants configurent l’accès aux identités de charge de travail :

• usePodIdentity: défini sur lors de "false" l’utilisation de l’identité de charge de travail.

• clientID: défini sur ${USER_ASSIGNED_CLIENT_ID}, l’ID client de l’identité managée affectée par l’utilisateur utilisée pour l’identité de charge de travail.

• cloudName: facultatif. Laissez vide pour utiliser l’environnement par défaut AzurePublicCloud .

• objectType: défini sur le type d’objet Key Vault à monter. Les valeurs valides sont secret, keyet cert.

• tenantId: défini sur l’ID de locataire qui contient le coffre de clés.

  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
  

  Remarque

  Si vous utilisez objectAlias plutôt que objectName, mettez à jour le script YAML pour le justifier.

  Remarque

  Pour que le SecretProviderClass fonctionne correctement, assurez-vous de remplir votre Azure Key Vault de secrets, de clés ou de certificats, avant de les référencer dans la section objects.

1. Déployez un échantillon de pod à l’aide de la kubectl apply commande et du script YAML suivant.

   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
   

Valider Key Vault secrets avec l’identité de charge de travail

Une fois le pod démarré, le contenu monté est /mnt/secrets-store disponible. Utilisez les commandes suivantes pour valider vos secrets et imprimer un secret de test.

1. Afficher les secrets conservés dans le magasin de secrets à l’aide de la commande suivante.

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

2. Afficher un secret du magasin à l’aide de la commande suivante. Cet exemple de commande montre le secret de test secret1.

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

Conditions préalables pour le pilote CSI avec une identité managée

• Avant de commencer, assurez-vous de terminer les étapes décrites dans Utiliser le fournisseur Azure Key Vault pour le pilote CSI du magasin de secrets dans un cluster Azure Kubernetes Service (AKS) pour activer le pilote CSI Azure Key Vault Secrets Store dans votre cluster AKS.

Accès avec une identité managée

Cette méthode utilise l’identité managée affectée par l’utilisateur que AKS crée automatiquement lorsque vous activez le fournisseur Azure Key Vault pour le pilote CSI du magasin de secrets. L’identité est nommée azurekeyvaultsecretsprovider-xxxxx, est stockée dans le groupe de ressources de nœud et est affectée au groupe de machines virtuelles identiques.

Une identité managée Microsoft Entra permet à une ressource ou une charge de travail Azure de s’authentifier auprès des services qui prennent en charge l’authentification Microsoft Entra sans stocker d’informations d’identification dans le code. Accordez à cette identité les autorisations appropriées Key Vault plan de données via Azure RBAC ou les stratégies d’accès, puis utilisez-la dans les étapes suivantes.

Configurer une identité managée

1. Accédez à votre coffre de clés à l’aide de la commande az aks show et de l’identité managée affectée par l’utilisateur créée par le module complémentaire. Vous devez également récupérer le clientId de l’identité, que vous utiliserez dans les étapes ultérieures lors de la création d’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)
   

   Vous pouvez également créer une identité managée et l’affecter à votre groupe de machines virtuelles identiques ou à chaque instance de machine virtuelle de votre groupe à haute 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)
   

   Pour un cluster basé sur un groupe identique de machines virtuelles, affectez l’identité au groupe identique de machines virtuelles.

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

   Pour un cluster basé sur un groupe à haute disponibilité, affectez l’identité à chaque instance de machine virtuelle dans le groupe à haute disponibilité.

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

2. Créez une attribution de rôle qui accorde à l’identité l’autorisation d’accéder aux secrets, clés d’accès et certificats Key Vault en utilisant la commande az role assignment create.

   Important

   • Si vous définissez votre key vault avec --enable-rbac-authorization et que vous utilisez key ou cert tapez, attribuez le Key Vault Certificate User rôle.
   • Si votre coffre de clés est défini avec --enable-rbac-authorization et que vous utilisez le type secret, attribuez le rôle Key Vault Secrets User.
   • Si votre coffre de clés n’est pas défini avec --enable-rbac-authorization, vous pouvez utiliser la commande az keyvault set-policy avec le paramètre --key-permissions get, --certificate-permissions get ou --secret-permissions get pour créer une stratégie de coffre de clés pour accorder l’accès aux clés, certificats ou secrets. Exemple :

   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. Créez un SecretProviderClass id client d’identité. Veillez à utiliser vos propres valeurs pour les objets à récupérer à partir de votre coffre de clés.

   Les paramètres suivants configurent l’accès aux identités managées affectées par l’utilisateur :

   • usePodIdentity: défini sur lors de "false" l’utilisation de l’identité managée.
   • useVMManagedIdentity: défini pour "true" activer le mode d’identité managée.
   • userAssignedIdentityID: défini sur l’ID client de l’identité managée affectée par l’utilisateur.
   • tenantId: défini sur l’ID de locataire qui contient le coffre de clés.

   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
   

   Remarque

   Si vous utilisez objectAlias au lieu de objectName, veillez à mettre à jour le script YAML.

   Remarque

   Pour que le SecretProviderClass fonctionne correctement, assurez-vous de remplir votre Azure Key Vault de secrets, de clés ou de certificats, avant de les référencer dans la section objects.

4. Appliquez le SecretProviderClass à votre cluster à l’aide de la commande kubectl apply.

   kubectl apply -f secretproviderclass.yaml
   

5. Créez un manifeste de pod nommé pod.yaml à l’aide de la commande suivante.

   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. Appliquez le pod à votre cluster à l’aide de la commande kubectl apply.

   kubectl apply -f pod.yaml
   

Valider Key Vault secrets avec une identité managée

Une fois le pod démarré, le contenu monté est /mnt/secrets-store disponible. Utilisez les commandes suivantes pour valider vos secrets et imprimer un secret de test.

1. Afficher les secrets conservés dans le magasin de secrets à l’aide de la commande suivante.

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

2. Afficher un secret du magasin à l’aide de la commande suivante. Cet exemple de commande montre le secret de test secret1.

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

Obtenir les certificats et clés

La conception d’Azure Key Vault fait une nette distinction entre les clés, les secrets et les certificats. Les fonctionnalités des certificats du service Key Vault sont conçues pour utiliser des caractéristiques de clé et de secret. Lorsque vous créez un certificat Key Vault, il crée une clé adressable et un secret avec le même nom. Cette clé permet d’exécuter des opérations d’authentification, tandis que le secret permet de récupérer la valeur du certificat sous forme de secret.

Un certificat Key Vault contient également des métadonnées de certificat x509 publiques. Le coffre de clés stocke les composantes publiques et privées de votre certificat dans un secret. Vous pouvez obtenir chaque composant individuel en spécifiant le objectType dans SecretProviderClass. Le tableau suivant présente les objectType valeurs que vous pouvez spécifier pour SecretProviderClass récupérer différents composants d’un certificat de coffre de clés et ce que chaque valeur retourne :

Désactiver le module complémentaire sur des clusters existants

Désactivez la fonctionnalité Fournisseur Azure Key Vault pour le pilote CSI du magasin de secrets dans un cluster existant à l’aide de la az aks disable-addons commande avec le azure-keyvault-secrets-provider module complémentaire.

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

Étapes suivantes

Dans cet article, vous avez appris à créer et à fournir une identité pour accéder à votre instance Azure Key Vault. L’intégration d’un connecteur de services permet de simplifier la configuration des connexions pour les charges de travail AKS et les services externes Azure. Il gère en toute sécurité les configurations réseau et d’authentification et suit les meilleures pratiques de connexion aux services Azure. Pour découvrir plus d’informations, consultez Utiliser le fournisseur Azure Key Vault pour la prise en charge du pilote CSI du magasin de secrets dans un cluster AKS et l’Introduction au connecteur de services.

Si vous souhaitez configurer des options de configuration supplémentaires ou effectuer une résolution des problèmes, consultez Options de configuration et ressources de résolution des problèmes pour le fournisseur Azure Key Vault avec le pilote CSI du magasin de secrets dans AKS.