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 recursos de Azure

1. Cree un grupo de recursos con el comando az group create.

   az group create \
       --name <resource-group-name> \
       --location <location>
   

2. Cree un clúster de AKS mediante el az aks create comando. En el ejemplo siguiente se crea un clúster de AKS de un solo nodo con la identidad administrada habilitada.

   az aks create \
       --resource-group <resource-group-name> \
       --name <cluster-name> \
       --enable-managed-identity \
       --node-count 1
   

3. Conéctese al clúster mediante el comando az aks get-credentials.

   az aks get-credentials \
       --resource-group <resource-group-name> \
       --name <cluster-name>
   

4. Cree un almacén de claves mediante el comando az keyvault create.

   az keyvault create \
       --resource-group <resource-group-name> \  
       --name <key-vault-name> \
       --location <location>
   

5. Cree un secreto en el almacén de claves mediante el comando az keyvault secret set.

   az keyvault secret set \
       --vault-name <key-vault-name> \
       --name <secret-name> \
       --value <secret-value>
   

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.
   • Reemplace <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 para el CSI Driver

• 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 que se ejecuta en un pod usa para autenticarse en otros servicios de Azure, como cargas de trabajo en software. Secret Store CSI Driver se integra con las funcionalidades nativas de Kubernetes para federar con proveedores de identidades externos.

En este modelo de seguridad, el clúster de AKS actúa como emisor de tokens. A continuación, Microsoft Entra ID usa OIDC para detectar claves de firma pública y comprobar la autenticidad del token de cuenta de servicio antes de intercambiarlo por un token de Microsoft Entra. Para que la carga de trabajo intercambie un token de cuenta de servicio proyectado en su volumen para un token de Microsoft Entra, necesita la biblioteca cliente de Identidad de Azure en el SDK de Azure o la Biblioteca de autenticación de Microsoft (MSAL)

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 IDENTITY_TENANT=$(az aks show --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --query identity.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 el almacén de claves se establece con --enable-rbac-authorization y usa el tipo key o certificate, asigne el rol de 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 --object-id $IDENTITY_OBJECT_ID
   

   export KEYVAULT_SCOPE=$(az keyvault show --name $KEYVAULT_NAME --query id -o tsv)
   
   # Example command for key vault with Azure RBAC enabled using `key` type
   az role assignment create --role "Key Vault Certificate 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. Establecer una credencial de identidad federada entre la aplicación Microsoft Entra, el emisor de la cuenta de servicio y el sujeto. Obtenga el identificador de objeto de la aplicación Microsoft Entra mediante los siguientes comandos. Asegúrate de actualizar los valores de serviceAccountName yserviceAccountNamespace con el nombre de la cuenta de servicio de Kubernetes y su área 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.

   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
   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: "${IDENTITY_TENANT}"        # 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.

8. 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
     labels:
       azure.workload.identity/use: "true"
   spec:
     serviceAccountName: "workload-identity-sa"
     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
   

Requisitos previos para el CSI Driver

• 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

Un identificador administrado de Microsoft Entra es una identidad que un administrador usa para autenticarse en otros servicios de Azure. La identidad administrada usa Azure RBAC para federar con proveedores de identidades externos.

En este modelo de seguridad, puede conceder acceso a los recursos del clúster a los miembros del equipo o a los inquilinos que comparten un rol administrado. El rol se comprueba para que el ámbito acceda al almacén de claves y a otras credenciales. Cuando habilitó el proveedor Azure Key Vault para el controlador CSI del almacén de secretos en su clúster AKS, se creó una identidad de usuario.

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.

   az aks show --resource-group <resource-group> --name <cluster-name> --query addonProfiles.azureKeyvaultSecretsProvider.identity.objectId -o tsv
   az aks show --resource-group <resource-group> --name <cluster-name> --query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId -o tsv
   

   Como alternativa, puedes crear una nueva identidad administrada y asignarla a tu conjunto de escalado de máquinas virtuales (VM) o a cada instancia de VM en tu conjunto de disponibilidad mediante los siguientes comandos.

   az identity create --resource-group <resource-group> --name <identity-name>
   az vmss identity assign --resource-group <resource-group> --name <agent-pool-vmss> --identities <identity-resource-id>
   az vm identity assign --resource-group <resource-group> --name <agent-pool-vm> --identities <identity-resource-id>
   
   az identity show --resource-group <resource-group> --name <identity-name> --query 'clientId' -o tsv
   

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 el almacén de claves se establece con --enable-rbac-authorization y usa el tipo key o certificate, asigne el rol de 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 --object-id $IDENTITY_OBJECT_ID
   

   export IDENTITY_OBJECT_ID="$(az identity show --resource-group <resource-group> --name <identity-name> --query 'principalId' -o tsv)"
   export KEYVAULT_SCOPE=$(az keyvault show --name <key-vault-name> --query id -o tsv)
   
   # Example command for key vault with Azure RBAC enabled using `key` type
   az role assignment create --role "Key Vault Certificate User" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE
   

3. Crea SecretProviderClass mediante el siguiente código YAML. Asegúrate de usar tus propios valores para userAssignedIdentityID, keyvaultName, tenantId y los objetos para recuperarlos del almacén de claves.

   # 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: <client-id>   # Set the clientID of the user-assigned managed identity to use
       keyvaultName: <key-vault-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: <tenant-id>                 # The tenant ID of the key vault
   

   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. Crea un pod usando el siguiente 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"
   

6. Aplica el pod al clúster con el comando kubectl apply.

   kubectl apply -f pod.yaml
   

Validación de secretos de Key Vault

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. 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 ExampleSecret de prueba.

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

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 objetos que se asignan a los distintos recursos asociados a un certificado:

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.