Implementación y configuración de la identidad de carga de trabajo en un clúster de Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) es un servicio de Kubernetes administrado que permite implementar y administrar clústeres de Kubernetes rápidamente. En este artículo:

  • Implementación de un clúster de AKS mediante la CLI de Azure que incluye el emisor de OpenID Connect y Microsoft Entra Workload ID
  • Concesión de acceso a la instancia de Azure Key Vault
  • Creación de un identificador de carga de trabajo de Microsoft Entra y una cuenta de servicio de Kubernetes
  • Configure la identidad administrada para la federación de tokens.

En este artículo se presupone un conocimiento básico de los conceptos de Kubernetes. Para más información, consulte Conceptos básicos de Kubernetes de Azure Kubernetes Service (AKS). Si no está familiarizado con Microsoft Entra Workload ID, consulte el siguiente artículo de información general.

  • En este artículo se necesita la versión 2.47.0, o versiones posteriores, de la CLI de Azure. Si usa Azure Cloud Shell, ya está instalada la versión más reciente.

  • La identidad que usa para crear el clúster tiene los permisos mínimos adecuados. Para más información sobre el acceso y la identidad en AKS, consulte Opciones de acceso e identidad en Azure Kubernetes Service (AKS).

  • Si tiene varias suscripciones de Azure, seleccione el id. de suscripción adecuado en el que se deben facturar los recursos con el comando az account.

Nota:

En lugar de configurar todos los pasos manualmente, hay otra implementación denominada Conector de servicio que le ayudará a configurar algunos pasos automáticamente y a obtener el mismo resultado. Consulte también: Tutorial: conexión a la cuenta de almacenamiento de Azure en Azure Kubernetes Service (AKS) con Service Connector mediante la identidad de carga de trabajo.

Exportación de variables de entorno

Para ayudar a simplificar los pasos para configurar las identidades necesarias, en los pasos siguientes se definen variables de entorno como referencia en el clúster.

Ejecute los comandos siguientes para crear estas variables. Reemplace los valores predeterminados de RESOURCE_GROUP, LOCATION, SERVICE_ACCOUNT_NAME, SUBSCRIPTION, USER_ASSIGNED_IDENTITY_NAME y FEDERATED_IDENTITY_CREDENTIAL_NAME.

export RESOURCE_GROUP="myResourceGroup"
export LOCATION="westcentralus"
export SERVICE_ACCOUNT_NAMESPACE="default"
export SERVICE_ACCOUNT_NAME="workload-identity-sa"
export SUBSCRIPTION="$(az account show --query id --output tsv)"
export USER_ASSIGNED_IDENTITY_NAME="myIdentity"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity"

Creación de un clúster de AKS

Cree un clúster de AKS con el comando az aks create y el parámetro --enable-oidc-issuer para utilizar el emisor de OIDC. En el siguiente ejemplo se crea un clúster denominado myAKSCluster con un nodo en myResourceGroup:

az aks create -g "${RESOURCE_GROUP}" -n myAKSCluster --enable-oidc-issuer --enable-workload-identity --generate-ssh-keys

Transcurridos unos minutos, el comando se completa y devuelve información en formato JSON sobre el clúster.

Nota

Al crear un clúster de AKS, se crea automáticamente un segundo grupo de recursos para almacenar los recursos de dicho clúster. Para más información, consulte ¿Por qué se crean dos grupos de recursos con AKS?

Actualización de un clúster de AKS ya existente

Puede actualizar un clúster de AKS con el comando az aks update y los parámetros --enable-oidc-issuer y --enable-workload-identity para utilizar el emisor de OIDC y habilitar la identidad de la carga de trabajo. En el siguiente ejemplo se actualiza un clúster denominado myAKSCluster:

az aks update -g "${RESOURCE_GROUP}" -n myAKSCluster --enable-oidc-issuer --enable-workload-identity

Obtener la dirección URL del emisor de OIDC

Para obtener la dirección URL del emisor de OIDC y guardarla en una variable de entorno, ejecute el siguiente comando. Reemplace el valor predeterminado de los argumentos -n, el nombre del clúster:

export AKS_OIDC_ISSUER="$(az aks show -n myAKSCluster -g "${RESOURCE_GROUP}" --query "oidcIssuerProfile.issuerUrl" -o tsv)"

La variable debe contener una dirección URL del emisor similar al ejemplo siguiente:

https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/

De manera predeterminada, el emisor tiene establecido usar la dirección URL base https://{region}.oic.prod-aks.azure.com/{tenant_id}/{uuid}, donde el valor de {region} coincide con la ubicación en la que se implementa el clúster de AKS. El valor {uuid} representa la clave OIDC.

Creación de una entidad administrada

Use el comando az account set de la CLI de Azure para que una suscripción específica se establezca como la suscripción activa actual. Después, use el comando az identity create para crear una identidad administrada.

az identity create --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --subscription "${SUBSCRIPTION}"

A continuación, vamos a crear una variable para el id. de identidad administrada.

export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "${RESOURCE_GROUP}" --name "${USER_ASSIGNED_IDENTITY_NAME}" --query 'clientId' -o tsv)"

Creación de una cuenta de servicio de Kubernetes

Cree una cuenta de servicio de Kubernetes y anote en ella el identificador de cliente de la identidad administrada creada en el paso anterior. Use el comando az aks get-credentials y reemplace los valores del nombre del clúster y el nombre del grupo de recursos.

az aks get-credentials -n myAKSCluster -g "${RESOURCE_GROUP}"

Copie y pegue la siguiente entrada de varias líneas en la CLI de Azure.

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

El ejemplo de salida siguiente es similar a la creación correcta del grupo de recursos:

serviceaccount/workload-identity-sa created

Establecimiento de una credencial de identidad federada

A continuación, use el comando az identity federated-credential create para crear la credencial de identidad federada entre la identidad administrada, el emisor de la cuenta de servicio y el asunto.

az identity federated-credential create --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --issuer "${AKS_OIDC_ISSUER}" --subject system:serviceaccount:"${SERVICE_ACCOUNT_NAMESPACE}":"${SERVICE_ACCOUNT_NAME}" --audience api://AzureADTokenExchange

Nota

La credencial de identidad federada tarda unos segundos en propagarse después de agregarse inicialmente. Si una solicitud de token se realiza inmediatamente después de agregar la credencial de identidad federada, podría provocar un error durante un par de minutos, ya que la memoria caché se rellena en el directorio con datos antiguos. Para evitar este problema, puede agregar un ligero retraso después de agregar la credencial de identidad federada.

Implementación de aplicación

Al implementar los pods de aplicación, el manifiesto debe hacer referencia a la cuenta de servicio creada en el paso Crear cuenta de servicio de Kubernetes. El siguiente manifiesto muestra cómo hacer referencia a la cuenta, en concreto a las propiedades metadata\namespace y spec\serviceAccountName:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: your-pod
  namespace: "${SERVICE_ACCOUNT_NAMESPACE}"
  labels:
    azure.workload.identity/use: "true"  # Required, only the pods with this label can use workload identity
spec:
  serviceAccountName: "${SERVICE_ACCOUNT_NAME}"
  containers:
    - image: <your image>
      name: <containerName>
EOF

Importante

Asegúrese de que los pods de su aplicación que usan identidad de carga de trabajo hayan agregado la etiqueta azure.workload.identity/use: "true" a la especificación de su pod; de lo contrario, los pods fallarán después de reiniciarse.

Opcional: concesión de permisos para acceder a Azure Key Vault

Este paso es necesario si necesita acceder a secretos, claves y certificados montados en Azure Key Vault desde un pod. Realice los pasos siguientes para configurar el acceso con una identidad administrada. En estos pasos se supone que tiene una instancia de Azure Key Vault ya creada y configurada en la suscripción. Si no la tiene, consulte Creación de una instancia de Azure Key Vault mediante la CLI de Azure.

Antes de continuar, necesita la siguiente información:

  • Nombre del almacén de claves
  • Grupo de recursos que contiene el almacén de claves

Puede recuperar esta información mediante el comando de la CLI de Azure: az keyvault list.

  1. Establezca una directiva de acceso para que la identidad administrada acceda a los secretos de Key Vault mediante la ejecución de los siguientes comandos:

    export KEYVAULT_RESOURCE_GROUP="myResourceGroup"
    export KEYVAULT_NAME="myKeyVault"
    export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "${RESOURCE_GROUP}" --name "${USER_ASSIGNED_IDENTITY_NAME}" --query 'clientId' -o tsv)"
    
    az keyvault set-policy --name "${KEYVAULT_NAME}" --secret-permissions get --spn "${USER_ASSIGNED_CLIENT_ID}"
    
  2. Creación de un secreto en Key Vault:

    export KEYVAULT_SECRET_NAME="my-secret"
    
    az keyvault secret set --vault-name "${KEYVAULT_NAME}" \
       --name "${KEYVAULT_SECRET_NAME}" \
       --value "Hello\!"
    
  3. Exportar la dirección URL de Key Vault:

    export KEYVAULT_URL="$(az keyvault show -g ${KEYVAULT_RESOURCE_GROUP} -n ${KEYVAULT_NAME} --query properties.vaultUri -o tsv)"
    
  4. Implementa un pod que haga referencia a la cuenta de servicio y la dirección URL de Key Vault anteriores:

    cat <<EOF | kubectl apply -f -
    apiVersion: v1
    kind: Pod
    metadata:
      name: quick-start
      namespace: ${SERVICE_ACCOUNT_NAMESPACE}
      labels:
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: ${SERVICE_ACCOUNT_NAME}
      containers:
        - image: ghcr.io/azure/azure-workload-identity/msal-go
          name: oidc
          env:
          - name: KEYVAULT_URL
            value: ${KEYVAULT_URL}
          - name: SECRET_NAME
            value: ${KEYVAULT_SECRET_NAME}
      nodeSelector:
        kubernetes.io/os: linux
    EOF
    

Para comprobar si el webhook inserta correctamente todas las propiedades, use el comando kubectl describe:

kubectl describe pod quick-start | grep "SECRET_NAME:"

Si funciona, la salida debe ser similar a la siguiente:

      SECRET_NAME:                 ${KEYVAULT_SECRET_NAME}

Para comprobar que el pod puede obtener un token y acceder al recurso, use el comando kubectl logs:

kubectl logs quick-start

Si funciona, la salida debe ser similar a la siguiente:

I0114 10:35:09.795900       1 main.go:63] "successfully got secret" secret="Hello\\!"

Deshabilitación de la identidad de la carga de trabajo

Para deshabilitar Microsoft Entra Workload ID en el clúster de AKS donde se ha habilitado y configurado, puede ejecutar el siguiente comando:

az aks update --resource-group "${RESOURCE_GROUP}" --name myAKSCluster --disable-workload-identity

Pasos siguientes

En este artículo, ha implementado un clúster de Kubernetes y lo ha configurado para usar una identidad de carga de trabajo como preparación para que las cargas de trabajo de la aplicación se autentiquen con esa credencial. Ahora está listo para implementar la aplicación y configurarla para usar la identidad de carga de trabajo con la versión más reciente de la biblioteca cliente de Azure Identity. Si no puede volver a escribir la aplicación para usar la versión más reciente de la biblioteca cliente, puede configurar el pod de la aplicación para autenticarse usando la identidad administrada con la identidad de carga de trabajo como solución de migración a corto plazo.