Partekatu honen bidez:

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

  • Artikulua

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:

  • Service Connector con el Id. de carga de trabajo
  • Id. de carga de trabajo
  • Identidad administrada asignada por el usuario

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:

  • Creación de un clúster de AKS y una instancia de Azure Key Vault.
  • Creación de una conexión entre el clúster de AKS y Azure Key Vault con Conector de servicio.
  • Creación de un CRD de SecretProviderClass y un Pod que consuma el proveedor de CSI para probar la conexión.
  • Limpieza de recursos.

Importante

Las características en versión preliminar de AKS están disponibles como opción de participación y autoservicio. Las versiones preliminares se proporcionan "tal cual" y "como están disponibles", y están excluidas de los Acuerdos de nivel de servicio y garantía limitada. Las versiones preliminares de AKS reciben cobertura parcial del soporte al cliente en la medida de lo posible. Por lo tanto, estas características no están diseñadas para su uso en producción. Para más información, consulte los siguientes artículos de soporte:

Requisitos previos

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 con el comando az aks create. 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 (versión preliminar)

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

  1. En el Azure Portal, vaya al recurso de clúster de AKS.

  2. En el menú del servicio, en Configuración, seleccione Service Connector (versión preliminar)>Crear.

  3. En la página Crear conexión, configure las opciones siguientes en la pestaña Aspectos básicos:

    • Espacio de nombres de Kubernetes: Seleccione Predeterminado.
    • Tipo de servicio: seleccione Key Vault y active la casilla para habilitar el proveedor CSI de Azure Key Vault.
    • Nombre de la conexión: escriba un nombre para esta conexión.
    • Suscripción: seleccione la suscripción que contiene el almacén de claves.
    • Almacén de claves: seleccione el almacén de claves que creó anteriormente.
    • Tipo de cliente: seleccione Ninguno.

  4. Seleccione Revisar y crear y, a continuación, seleccione Crear para crear la conexión.

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

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

  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 no lo tiene habilitado, 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 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

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

  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

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

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

  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 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ún SecretProviderClass 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.