Conecte su proveedor de identidad de Azure Key Vault Secrets Store CSI Driver en Azure Kubernetes Service (AKS)

Aprenda a conectarse a Azure Key Vault mediante el controlador CSI del almacén de secretos en un clúster de Azure Kubernetes Service (AKS) con la ayuda de Service Connector. En este artículo, se realizarán las siguientes tareas:

Requisitos previos

• Una cuenta de Azure con una suscripción activa. Cree una cuenta gratuita.
• LaCLI de Azure. Inicie sesión con el comando az login.
• Docker y kubectl. Para instalar kubectl localmente, use el comando az aks install-cli.
• Conocimientos básicos sobre los contenedores y AKS. Empiece por preparar una aplicación para AKS.
• Antes de comenzar, asegúrese de finalizar los pasos de Utilice el proveedor Azure Key Vault para Secrets Store CSI Driver en un clúster Azure Kubernetes Service (AKS) para habilitar Azure Key Vault Secrets Store CSI Driver en su clúster AKS.

Configuración inicial

1. Si usa Service Connector por primera vez, empiece ejecutando el comando az provider register para registrar el los proveedores de recursos de Service Connector y Configuración de Kubernetes.

   az provider register -n Microsoft.ServiceLinker
   

   az provider register -n Microsoft.KubernetesConfiguration
   

   Sugerencia

   Es posible comprobar si estos proveedores de recursos ya se han registrado ejecutando los comandos az provider show -n "Microsoft.ServiceLinker" --query registrationState y az provider show -n "Microsoft.KubernetesConfiguration" --query registrationState.

2. Opcionalmente, use el comando de la CLI de Azure para obtener una lista de los servicios de destino admitidos para el clúster de AKS.

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

Creación de una conexión de servicio en AKS con Service Connector

Puede crear una conexión de servicio a Azure Key Vault mediante Azure Portal o la CLI de Azure.

Comprobación de la conexión

Clonación del repositorio de ejemplo e implementación de los archivos de manifiesto

1. Clone el repositorio de ejemplo mediante el comando git clone.

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

2. Cambie los directorios al ejemplo del proveedor CSI de Azure Key Vault.

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

3. En el archivo secret_provider_class.yaml, reemplace los siguientes marcadores de posición por la información de Azure Key Vault:

   • Reemplace <AZURE_KEYVAULT_NAME> por el nombre del almacén de claves que hemos creado y conectado.
   • Reemplace <AZURE_KEYVAULT_TENANTID> por el id. de inquilino del almacén de claves.
   • Sustituya <AZURE_KEYVAULT_CLIENTID> por el ID de cliente de identidad del complemento azureKeyvaultSecretsProvider.
   • Reemplace <KEYVAULT_SECRET_NAME> por el secreto del almacén de claves que creó. Por ejemplo, ExampleSecret.

4. Implemente el CRD SecretProviderClass mediante el comando kubectl apply.

   kubectl apply -f secret_provider_class.yaml
   

5. Implemente el archivo de manifiesto Pod mediante el comando kubectl apply.

   El comando crea un pod denominado sc-demo-keyvault-csi en el espacio de nombres predeterminado del clúster de AKS.

   kubectl apply -f pod.yaml
   

Comprobación de la conexión

1. Compruebe que el pod se creó correctamente mediante el comando kubectl get.

   kubectl get pod/sc-demo-keyvault-csi
   

   Una vez que se inicia el pod, el contenido montado en la ruta del volumen especificada en el archivo YAML de implementación estará disponible.

2. Muestre los secretos mantenidos en el almacén de secretos mediante el comando kubectl exec.

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

3. Muestre un secreto mediante el comando kubectl exec.

   En este comando de ejemplo se muestra un secreto de prueba denominado ExampleSecret.

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

Requisitos previos del controlador CSI con identidad de carga de trabajo

• Antes de comenzar, asegúrese de finalizar los pasos de Utilice el proveedor Azure Key Vault para Secrets Store CSI Driver en un clúster Azure Kubernetes Service (AKS) para habilitar Azure Key Vault Secrets Store CSI Driver en su clúster AKS.
• El Id. de carga de trabajo de Microsoft Entra es compatible con clústeres de Windows y Linux.

Acceso con un identificador de carga de trabajo de Microsoft Entra

Un Id. de carga de trabajo de Microsoft Entra es una identidad que una aplicación o servicio usa para autenticarse en otros servicios de Azure, como las cargas de trabajo del software. El controlador CSI de Secrets Store se integra con las funcionalidades nativas de Kubernetes para federarse con proveedores de identidades externos.

En este modelo de seguridad, el clúster de AKS actúa como emisor de tokens. Cuando el controlador CSI del almacén de secretos monta el volumen, solicita un token de cuenta de servicio de Kubernetes y el proveedor de Azure Key Vault intercambia ese token para un token de Microsoft Entra. La aplicación lee los archivos montados y no necesita la biblioteca cliente de Azure Identity ni el Biblioteca de autenticación de Microsoft (MSAL) para este flujo de montaje de volumen. Si la aplicación solicita por sí misma tokens de Microsoft Entra para llamar a API protegidas, use Azure Identity o MSAL en la aplicación.

Configuración de la identidad de carga de trabajo

1. Establece la suscripción ejecutando el 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. Crear una identidad administrada usando el comando az identity create.

   Nota:

   En este paso se asume que tiene un clúster de AKS existente con la identidad de carga de trabajo habilitada. Si la identidad de carga de trabajo no está habilitada, consulte Habilitación de la identidad de carga de trabajo en un clúster de AKS existente para habilitarla.

   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. Cree una asignación de roles que conceda al permiso de identidad de carga de trabajo para acceder a los secretos del almacén de claves, las claves de acceso y los certificados mediante el comando az role assignment create.

   Importante

   • Si ha configurado el almacén de claves con --enable-rbac-authorization y está usando el tipo key o cert, asigne el rol Key Vault Certificate User para conceder permisos.
   • Si el almacén de claves se establece con --enable-rbac-authorization y usa el tipo secret, asigne el rol de Key Vault Secrets User.
   • Si el almacén de claves no está establecido con --enable-rbac-authorization, puede usar el comando az keyvault set-policy con el parámetro --key-permissions get, --certificate-permissions geto --secret-permissions get a fin de crear una directiva de almacén de claves para conceder acceso a claves, certificados o secretos. Por ejemplo:

   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. Obtén la dirección URL del emisor de OIDC del clúster de AKS mediante el comando az aks show.

   Nota:

   En este paso se asume que tiene un clúster de AKS existente con la dirección URL del emisor de OIDC habilitada. Si la dirección URL del emisor de OIDC no está habilitada, consulte Actualización de un clúster de AKS con emisor de OIDC para habilitarlo.

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

5. Cree una cuenta de servicio de Kubernetes para la carga de trabajo. Actualice los valores de SERVICE_ACCOUNT_NAME y SERVICE_ACCOUNT_NAMESPACE con el nombre de la cuenta de servicio de Kubernetes y su espacio de nombres.

   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. Crear la credencial de identidad federada entre la identidad administrada, el emisor de la cuenta de servicio y el asunto mediante el 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. Implementar mediante SecretProviderClass el kubectl apply comando y el siguiente script YAML.

Los parámetros siguientes configuran el acceso a la identidad de carga de trabajo:

• usePodIdentity: se establece en "false" al usar la identidad de carga de trabajo.

• clientID: Se establece en ${USER_ASSIGNED_CLIENT_ID}, el ID de cliente de la identidad administrada asignada por el usuario que se utiliza para la identidad de carga de trabajo.

• cloudName: opcional. Deje vacío para usar el entorno predeterminado AzurePublicCloud .

• objectType: se establece en el tipo de objeto Key Vault que se va a montar. Los valores válidos son secret, keyy cert.

• tenantId: Se establece en el identificador del inquilino que contiene el cofre de claves.

  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
  

  Nota:

  Si usa objectAlias en lugar de objectName, actualice el script YAML para tenerlo en cuenta.

  Nota:

  Para que SecretProviderClass funcione correctamente, asegúrese de rellenar Azure Key Vault con secretos, claves o certificados antes de hacer referencia a ellos en la sección objects.

1. Implementar un pod de muestra kubectl apply con el comando y el siguiente script YAML.

   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
   

Validación de secretos de Key Vault con identidad de carga de trabajo

Una vez iniciado el pod, el contenido montado en /mnt/secrets-store está disponible. Use los siguientes comandos para validar los secretos e imprimir un secreto de prueba.

1. Muestre los secretos contenidos en el almacén de secretos mediante el comando siguiente.

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

2. Muestre un secreto en el almacén mediante el comando siguiente. Este comando de ejemplo muestra el secreto secret1 de prueba.

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

Requisitos previos para el controlador CSI con identidad administrada

• Antes de comenzar, asegúrese de finalizar los pasos de Utilice el proveedor Azure Key Vault para Secrets Store CSI Driver en un clúster Azure Kubernetes Service (AKS) para habilitar Azure Key Vault Secrets Store CSI Driver en su clúster AKS.

Acceso con identidad administrada

Este método utiliza la identidad administrada asignada por el usuario que AKS crea automáticamente cuando habilita el proveedor de Azure Key Vault para Secrets Store CSI Driver. La identidad se denomina azurekeyvaultsecretsprovider-xxxxx, se almacena en el grupo de recursos del nodo y se asigna al conjunto de escalado de máquinas virtuales.

Una identidad administrada Microsoft Entra permite que un recurso o carga de trabajo de Azure se autentique en los servicios que admiten la autenticación Microsoft Entra sin almacenar credenciales en el código. Otorgue a esta identidad los permisos adecuados del plano de datos de Key Vault mediante Azure RBAC o directivas de acceso y, a continuación, úsela en los pasos siguientes.

Configuración de una identidad administrada

1. Acceda al almacén de claves mediante el comando az aks show y la identidad administrada asignada por el usuario creada por el complemento. También debe recuperar el elemento clientId de la identidad, que usará en pasos posteriores al crear 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)
   

   Como alternativa, puede crear una nueva identidad administrada y asignarla al conjunto de escalado de máquinas virtuales (VM) o a cada instancia de máquina virtual del conjunto de disponibilidad.

   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)
   

   Para un clúster basado en un conjunto de escalado de máquinas virtuales, asigne la identidad al conjunto de escalado de máquinas virtuales.

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

   Para un clúster basado en conjunto de disponibilidad, asigne la identidad a cada instancia de máquina virtual del conjunto de disponibilidad.

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

2. Cree una asignación de roles que conceda el permiso de identidad para acceder a los secretos del almacén de claves, las claves de acceso y los certificados mediante el comando az role assignment create.

   Importante

   • Si configura el almacén de claves con --enable-rbac-authorization y usa el tipo key o cert, asigne el rol Key Vault Certificate User.
   • Si el almacén de claves se establece con --enable-rbac-authorization y usa el tipo secret, asigne el rol de Key Vault Secrets User.
   • Si el almacén de claves no está establecido con --enable-rbac-authorization, puede usar el comando az keyvault set-policy con el parámetro --key-permissions get, --certificate-permissions geto --secret-permissions get a fin de crear una directiva de almacén de claves para conceder acceso a claves, certificados o secretos. Por ejemplo:

   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. Cree un SecretProviderClass con el ID de cliente de identidad. Asegúrese de usar sus propios valores para los objetos que vaya a recuperar de su almacén de claves.

   Los parámetros siguientes configuran el acceso a la identidad administrada asignada por el usuario:

   • usePodIdentity: se establece en "false" cuando se usa la identidad administrada.
   • useVMManagedIdentity: se establece en "true" para habilitar el modo de identidad administrada.
   • userAssignedIdentityID: Se establece como el identificador de cliente de la identidad administrada asignada por el usuario.
   • tenantId: Se establece en el identificador del inquilino que contiene el cofre de claves.

   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
   

   Nota:

   Si usa objectAlias en lugar de objectName, asegúrese de actualizar el script YAML.

   Nota:

   Para que SecretProviderClass funcione correctamente, asegúrese de rellenar Azure Key Vault con secretos, claves o certificados antes de hacer referencia a ellos en la sección objects.

4. Aplica SecretProviderClass al clúster usando el comando kubectl apply.

   kubectl apply -f secretproviderclass.yaml
   

5. Cree un manifiesto de pod denominado pod.yaml con el comando siguiente.

   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. Aplica el pod al clúster con el comando kubectl apply.

   kubectl apply -f pod.yaml
   

Validación de secretos de Key Vault con identidad administrada

Una vez iniciado el pod, el contenido montado en /mnt/secrets-store está disponible. Use los siguientes comandos para validar los secretos e imprimir un secreto de prueba.

1. Muestre los secretos contenidos en el almacén de secretos mediante el comando siguiente.

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

2. Muestre un secreto en el almacén mediante el comando siguiente. Este comando de ejemplo muestra el secreto secret1 de prueba.

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

Obtención de certificados y claves

El diseño de Azure Key Vault establece distinciones claras entre las claves, los secretos y los certificados. Las características de certificado del servicio Key Vault están diseñadas para usar las funcionalidades de clave y secreto. Cuando crea un certificado del almacén de claves, se crean una clave direccionable y un secreto con el mismo nombre. Esta clave permite las operaciones de autenticación y el secreto permite la recuperación del valor del certificado como secreto.

Un certificado de almacén de claves también contiene metadatos del certificado X.509 público. El almacén de claves almacena los componentes tanto públicos como privados de su certificado en un secreto. Para obtener cada componente por separado, especifique objectType en SecretProviderClass. En la siguiente tabla se muestran los valores de objectType que puede especificar en SecretProviderClass para recuperar distintos componentes de un certificado de Key Vault y qué devuelve cada uno:

Deshabilitar el complemento en clústeres existentes

Deshabilite la funcionalidad del proveedor de Azure Key Vault para el controlador CSI del almacén de secretos en un clúster existente utilizando el comando az aks disable-addons con el complemento azure-keyvault-secrets-provider.

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

Pasos siguientes

En este artículo, ha aprendido a crear y proporcionar una identidad para acceder a Azure Key Vault. La integración de Conector de servicio ayuda a simplificar la configuración de conexión para cargas de trabajo de AKS y servicios de respaldo de Azure. Controla de forma segura la autenticación y las configuraciones de red y sigue los procedimientos recomendados para conectarse a los servicios de Azure. Para más información, consulte Uso del proveedor de Azure Key Vault para el controlador CSI del almacén de secretos en un clúster de AKS y la Introducción a Service Connector.

Si desea ajustar opciones de configuración adicionales o realizar la solución de problemas, consulte Opciones de configuración y recursos de solución de problemas para el proveedor de Azure Key Vault con el controlador CSI del almacén de secretos en AKS.