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

Artículo
05/07/2024

El controlador Secrets Store Container Storage Interface (CSI) en Azure Kubernetes Service (AKS) proporciona varios métodos de acceso basado en identidades a Azure Key Vault. En este artículo se describen estos métodos y los procedimientos recomendados para utilizar los modelos de seguridad Control de acceso basado en roles (RBAC) u OpenID Connect (OIDC) para acceder al depósito de claves y al clúster AKS.

Puede utilizar uno de los siguientes métodos de acceso:

Microsoft Entra Workload ID
Identidad administrada asignada por el usuario

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 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)

Nota:

Este método de autenticación reemplaza a la identidad administrada por pods de Microsoft Entra (versión preliminar). La identidad administrada por pods de Microsoft Entra de código abierto (versión preliminar) en Azure Kubernetes Service ha quedado en desuso a partir del 24/10/2022.
El identificador de carga de trabajo de Microsoft Entra es compatible con clústeres de Windows y Linux.

Configuración de la identidad de carga de trabajo

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

Crear una identidad administrada usando el comando az identity create.

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)

Cree una directiva de acceso que conceda permiso a la identidad de carga de trabajo para acceder a los secretos, las claves de acceso y los certificados de Key Vault 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 RBAC enabled using `key` type
az role assignment create --role "Key Vault Certificate User" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE
```
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 no la tiene habilitada, consulte Actualización de un clúster de AKS con emisor de OIDC para habilitarla.
```
export AKS_OIDC_ISSUER="$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query "oidcIssuerProfile.issuerUrl" -o tsv)"
echo $AKS_OIDC_ISSUER
```

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

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}

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.

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

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

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

Cree una directiva de acceso que conceda permiso a la identidad para acceder a los secretos, las claves de acceso y los certificados de Key Vault 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 RBAC enabled using `key` type
az role assignment create --role "Key Vault Certificate User" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE
```

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.

Aplica SecretProviderClass al clúster usando el comando kubectl apply.
```
kubectl apply -f secretproviderclass.yaml
```

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"

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.

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/
```
Muestre un secreto en el almacén con 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 se crea un certificado de Key Vault, 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:

Object	Valor devuelto	Devuelve toda la cadena de certificados
`key`	Clave pública en formato de correo con privacidad mejorada (PEM).	N/D
`cert`	Certificado en formato PEM.	No
`secret`	Clave privada y certificado en formato PEM.	Sí

Deshabilitar el complemento en clústeres existentes

Nota:

Antes de deshabilitar el complemento, asegúrese de que no haya ningúnSecretProviderClass en uso. Si hay un SecretProviderClass e intenta deshabilitar el complemento, se producirá un error.

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
```

Nota:

Al deshabilitar el complemento, las cargas de trabajo existentes no deberían tener problemas ni ver ninguna actualización en los secretos montados. Si se reinicia el pod o se crea otro como parte del evento de escalado vertical, el pod no se iniciará porque el controlador ya está en ejecución.

Pasos siguientes

En este artículo, ha aprendido a crear y proporcionar una identidad para acceder a Azure Key Vault. La integración de Service Connector 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.

Compartir a través de

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

Requisitos previos para el CSI Driver

Acceso con un identificador de carga de trabajo de Microsoft Entra

Configuración de la identidad de carga de trabajo

Acceso con identidad administrada

Configuración de una identidad administrada

Validación de secretos de Key Vault

Obtención de certificados y claves

Deshabilitar el complemento en clústeres existentes

Pasos siguientes

Comentarios

Recursos adicionales