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

1. Dans le portail Azure, accédez à votre ressource de cluster AKS.

2. Dans le menu du service, sous Paramètres, sélectionnez Service Connector>Create.

3. Sur la page Créer une connexion, configurez les paramètres suivants dans l’onglet Paramètres de base :

   • Espace de noms Kubernetes : sélectionnez par défaut.
   • Type de service : sélectionnez Key Vault et cochez la case pour activer le fournisseur CSI Azure Key Vault.
   • Nom de la connexion : saisissez un nom pour la connexion.
   • Abonnement : Sélectionnez l’abonnement qui contient le coffre-fort de clés.
   • Coffre à clés : Sélectionnez le coffre-fort de clés que vous avez créé.
   • Type de client : Ne sélectionner aucun.

4. Sélectionnez Réviser + créer, puis sélectionnez Créer pour créer la connexion.

• Créez une connexion à votre coffre-fort de clés à l’aide de la commande az aks connection create keyvault.

  az aks connection create keyvault \
      --connection <connection-name> \
      --resource-group <resource-group-of-cluster> \
      --name <cluster-name> \
      --target-resource-group <resource-group-of-key-vault> \
      --vault <key-vault-name> \
      --enable-csi \
      --client-type none
  

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)
   

   Sinon, vous pouvez créer une identité managée et l’attribuer à 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 configurez votre coffre de clés avec --enable-rbac-authorization et que vous utilisez le type key ou cert, attribuez le rôle Key Vault Certificate User.
   • 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 à l’aide de l’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 "false" lors de l’utilisation d’une identité managée.
   • useVMManagedIdentity: Définir sur "true" pour activer le mode d’identité managée.
   • userAssignedIdentityID : définissez cette valeur sur l’ID de client de l’identité managée attribuée par l’utilisateur.
   • tenantId : défini sur l’ID du 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é à /mnt/secrets-store est 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
   

Prérequis

• Terraform 1.6 ou version ultérieure.
• Azure CLI, installé et connecté. Installez la dernière version.
• kubectl, connecté à votre cluster avec la commande az aks get-credentials.

Configurer une identité managée

L’exemple Terraform testé crée le groupe de ressources, le cluster AKS avec le fournisseur Azure Key Vault pour le pilote CSI Secrets Store activé, Azure Key Vault, ExampleSecret, et une attribution de rôle qui accorde à l’identité managée du module complémentaire le rôle Key Vault Secrets User sur le coffre de clés. Si vous avez déjà déployé l’exemple issu de Utiliser le fournisseur Azure Key Vault avec le pilote CSI Secrets Store dans un cluster Azure Kubernetes Service (AKS), réutilisez ce répertoire de travail et passez directement à l’étape de définition des variables.

1. Créez un main.tf fichier et copiez l’exemple de configuration testé suivant dans celui-ci. Le référentiel GitHub Terraform Azure conserve l’exemple.

   terraform {
     required_version = ">= 1.5.0"
   
     required_providers {
       azurerm = {
         source  = "hashicorp/azurerm"
         version = "~> 3.116"
       }
       random = {
         source  = "hashicorp/random"
         version = "~> 3.6"
       }
     }
   }
   
   provider "azurerm" {
     features {
       resource_group {
         prevent_deletion_if_contains_resources = false
       }
     }
   }
   
   data "azurerm_client_config" "current" {}
   
   resource "random_string" "suffix" {
     length  = 6
     upper   = false
     special = false
   }
   
   locals {
     location            = "eastus"
     resource_group_name = "rg-aks-kv-csi-demo-${random_string.suffix.result}"
     aks_name            = "aks-kv-csi-demo"
     key_vault_name      = "kvcsidemo${random_string.suffix.result}"
     secret_name         = "ExampleSecret"
   }
   
   resource "azurerm_resource_group" "this" {
     name     = local.resource_group_name
     location = local.location
   }
   
   resource "azurerm_log_analytics_workspace" "this" {
     name                = "law-aks-kv-csi-demo"
     location            = azurerm_resource_group.this.location
     resource_group_name = azurerm_resource_group.this.name
     sku                 = "PerGB2018"
     retention_in_days   = 30
   }
   
   resource "azurerm_kubernetes_cluster" "this" {
     name                      = local.aks_name
     location                  = azurerm_resource_group.this.location
     resource_group_name       = azurerm_resource_group.this.name
     dns_prefix                = "akskvcsidemo"
     kubernetes_version        = null
     oidc_issuer_enabled       = true
     workload_identity_enabled = true
   
     default_node_pool {
       name       = "system"
       node_count = 1
       vm_size    = "Standard_D2s_v3"
   
       upgrade_settings {
         drain_timeout_in_minutes      = 0
         max_surge                     = "10%"
         node_soak_duration_in_minutes = 0
       }
     }
   
     identity {
       type = "SystemAssigned"
     }
   
     key_vault_secrets_provider {
       secret_rotation_enabled = false
     }
   
     oms_agent {
       log_analytics_workspace_id = azurerm_log_analytics_workspace.this.id
     }
   
     network_profile {
       network_plugin    = "azure"
       load_balancer_sku = "standard"
     }
   
     tags = {
       scenario = "aks-keyvault-csi"
     }
   }
   
   resource "azurerm_key_vault" "this" {
     name                          = local.key_vault_name
     location                      = azurerm_resource_group.this.location
     resource_group_name           = azurerm_resource_group.this.name
     tenant_id                     = data.azurerm_client_config.current.tenant_id
     sku_name                      = "standard"
     purge_protection_enabled      = false
     soft_delete_retention_days    = 7
     enable_rbac_authorization     = true
     public_network_access_enabled = true
   }
   
   resource "azurerm_role_assignment" "current_user_kv_admin" {
     scope                = azurerm_key_vault.this.id
     role_definition_name = "Key Vault Administrator"
     principal_id         = data.azurerm_client_config.current.object_id
   }
   
   resource "azurerm_key_vault_secret" "example" {
     name         = local.secret_name
     value        = "HelloFromKeyVault"
     key_vault_id = azurerm_key_vault.this.id
   
     depends_on = [
       azurerm_role_assignment.current_user_kv_admin
     ]
   }
   
   resource "azurerm_role_assignment" "aks_csi_secrets_user" {
     scope                = azurerm_key_vault.this.id
     role_definition_name = "Key Vault Secrets User"
     # This is the managed identity automatically created by the AKS Key Vault CSI addon.
     principal_id = azurerm_kubernetes_cluster.this.key_vault_secrets_provider[0].secret_identity[0].object_id
   }
   
   output "resource_group_name" {
     value = azurerm_resource_group.this.name
   }
   
   output "aks_cluster_name" {
     value = azurerm_kubernetes_cluster.this.name
   }
   
   output "key_vault_name" {
     value = azurerm_key_vault.this.name
   }
   
   output "key_vault_secret_name" {
     value = azurerm_key_vault_secret.example.name
   }
   
   output "tenant_id" {
     value = data.azurerm_client_config.current.tenant_id
   }
   
   output "aks_csi_client_id" {
     value = azurerm_kubernetes_cluster.this.key_vault_secrets_provider[0].secret_identity[0].client_id
   }
   
   output "aks_csi_object_id" {
     value = azurerm_kubernetes_cluster.this.key_vault_secrets_provider[0].secret_identity[0].object_id
   }
   

2. Initialisez, validez et appliquez la configuration.

   terraform init
   terraform fmt
   terraform validate
   terraform plan
   terraform apply
   

3. Définissez les variables utilisées dans les commandes restantes à partir des sorties Terraform.

   export RESOURCE_GROUP=$(terraform output -raw resource_group_name)
   export CLUSTER_NAME=$(terraform output -raw aks_cluster_name)
   export KEYVAULT_NAME=$(terraform output -raw key_vault_name)
   export KEYVAULT_SECRET_NAME=$(terraform output -raw key_vault_secret_name)
   export USER_ASSIGNED_CLIENT_ID=$(terraform output -raw aks_csi_client_id)
   export IDENTITY_OBJECT_ID=$(terraform output -raw aks_csi_object_id)
   export KEYVAULT_TENANT_ID=$(terraform output -raw tenant_id)
   

   Remarque

   L’exemple crée déjà l’attribution de rôle qui accorde le rôle Key Vault Secrets User à $IDENTITY_OBJECT_ID pour le coffre de clés. Ne répétez pas laz role assignment create'étape de l'onglet Azure CLI pour cette identité et ce coffre de clés. L'exemple l'a déjà fait pour vous.

4. Créez un SecretProviderClass à l’aide de l’ID client de l’identité et du nom du secret issus des sorties Terraform.

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

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

   cat <<EOF > secretproviderclass.yaml
   # This is a SecretProviderClass example using the add-on's managed identity, created by the Terraform sample, 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 to 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: ${KEYVAULT_SECRET_NAME}
             objectType: secret              # object types: secret, key, or cert
             objectVersion: ""               # [OPTIONAL] object versions, default to latest if empty
       tenantId: ${KEYVAULT_TENANT_ID}       # The tenant ID of the key vault
   EOF
   

   Remarque

   L’exemple crée uniquement un secret objet de type. Pour une couverture de type key ou cert, consultez Obtenir les certificats et les clés.

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

   kubectl apply -f secretproviderclass.yaml
   

6. 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
   

7. Appliquez le pod à votre cluster à l’aide de la kubectl apply commande.

   kubectl apply -f pod.yaml
   

Valider Key Vault secrets avec une identité managée

Une fois le pod démarré, le contenu monté à /mnt/secrets-store est disponible. Utilisez les commandes suivantes pour valider votre secret.

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. Affichez le secret dans le magasin à l’aide de la commande suivante. $KEYVAULT_SECRET_NAME correspond à celui de l’exemple ExampleSecret.

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

Nettoyer les ressources Terraform

Si vous avez déployé l’exemple uniquement pour terminer cet article et n’avez pas besoin des ressources pour quoi que ce soit d’autre, supprimez-les du même répertoire de travail que celui utilisé pour appliquer la configuration.

KUBE_CONTEXT=$(kubectl config current-context)
kubectl config delete-context $KUBE_CONTEXT
terraform destroy