Las credenciales estáticas son fáciles de crear y difíciles de defender. Un secreto llega a un manifiesto de Kubernetes, otro se copia en una variable de canalización y, en poco tiempo, nadie puede saber qué carga de trabajo aún necesita qué contraseña.

Azure Kubernetes Service (AKS) tiene un patrón mejor: Microsoft Entra Workload ID. En lugar de almacenar secretos de clientes de larga duración en pods, una cuenta de servicio de Kubernetes puede intercambiar un token proyectado por un token de acceso de Microsoft Entra. La carga de trabajo obtiene el acceso a Azure que necesita y usted deja de tratar Kubernetes Secrets como una bóveda de contraseñas.

En este tutorial, configurará la identidad de la carga de trabajo para una carga de trabajo de AKS, la conectará a una identidad administrada asignada por el usuario y verificará que el pod pueda acceder a Azure sin un secreto estático.

Requisitos previos

Para seguirlo, necesitarás:

• Una suscripción de Azure donde puede crear o modificar un clúster de AKS.
• CLI de Azure instalada y autenticada con az login.
• kubectl configurado para su clúster de AKS.
• Permiso para crear identidades administradas y credenciales de identidad federadas.
• Un clúster de AKS que admite la identidad de la carga de trabajo.

Relacionado: ID de carga de trabajo de Microsoft Entra para AKS

Por qué es importante la identidad de la carga de trabajo

Un pod de Kubernetes a menudo necesita comunicarse con los servicios de Azure. Podría leer un secreto de Key Vault, escribir en una cuenta de almacenamiento o consultar una base de datos. El antiguo atajo era colocar una ID de cliente y un secreto de cliente en algún lugar que el pod pudiera leer.

Ese atajo crea tres problemas:

• Los secretos se copian en demasiados lugares.
• La rotación se convierte en un riesgo de interrupción.
• La respuesta a incidentes se vuelve más difícil porque nadie sabe qué módulo utilizó qué credencial.

La identidad de la carga de trabajo cambia el modelo de confianza. El pod demuestra quién es a través de su cuenta de servicio de Kubernetes. Microsoft Entra confía en esa cuenta de servicio a través de una credencial de identidad federada. Azure devuelve un token sin que la carga de trabajo almacene nunca una contraseña.

El objetivo no es sólo menos secretos. El objetivo es una frontera de identidad más clara.

Habilite la identidad de la carga de trabajo en AKS

Si está creando un nuevo clúster, habilite la identidad de la carga de trabajo y el emisor de OIDC durante la creación del clúster.

az aks create \
  --resource-group rg-aks-demo \
  --name aks-workload-demo \
  --enable-oidc-issuer \
  --enable-workload-identity \
  --generate-ssh-keys

Para un clúster existente, habilite ambas funciones.

az aks update \
  --resource-group rg-aks-demo \
  --name aks-workload-demo \
  --enable-oidc-issuer \
  --enable-workload-identity

Luego recupere la URL del emisor OIDC. Necesitará esta URL al crear la credencial de identidad federada.

AKS_OIDC_ISSUER=$(az aks show \
  --resource-group rg-aks-demo \
  --name aks-workload-demo \
  --query oidcIssuerProfile.issuerUrl \
  --output tsv)

echo $AKS_OIDC_ISSUER

Si este comando devuelve un valor vacío, deténgase. El emisor no está habilitado correctamente y el intercambio de tokens no funcionará.

Crear una identidad administrada asignada por el usuario

A continuación, cree la identidad de Azure que utilizará su pod.

az identity create \
  --resource-group rg-aks-demo \
  --name id-aks-reader

Captar los valores de identidad.

IDENTITY_CLIENT_ID=$(az identity show \
  --resource-group rg-aks-demo \
  --name id-aks-reader \
  --query clientId \
  --output tsv)

IDENTITY_PRINCIPAL_ID=$(az identity show \
  --resource-group rg-aks-demo \
  --name id-aks-reader \
  --query principalId \
  --output tsv)

echo $IDENTITY_CLIENT_ID

Asigne a la identidad el rol más pequeño que necesite. Para una prueba rápida de solo lectura, asigne el rol a un grupo de recursos.

SUBSCRIPTION_ID=$(az account show --query id --output tsv)

az role assignment create \
  --assignee $IDENTITY_PRINCIPAL_ID \
  --role Reader \
  --scope /subscriptions/$SUBSCRIPTION_ID/resourceGroups/rg-aks-demo

No asigne Contributor solo porque facilita la demostración. La identidad de la carga de trabajo elimina los secretos estáticos, pero no corrige los roles con permisos excesivos.

Cree la cuenta de servicio de Kubernetes

Un enlace de identidad de carga de trabajo comienza en Kubernetes con una cuenta de servicio. Cree un espacio de nombres y una cuenta de servicio anotados con el ID del cliente de identidad administrada.

apiVersion: v1
kind: Namespace
metadata:
  name: workload-demo
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: workload-reader
  namespace: workload-demo
  annotations:
    azure.workload.identity/client-id: "REPLACE_WITH_CLIENT_ID"

Guarde el archivo como service-account.yamlreemplazar REPLACE_WITH_CLIENT_IDy aplicarlo.

kubectl apply -f service-account.yaml

El nombre de la cuenta de servicio y el espacio de nombres son importantes. Microsoft Entra confiará en esta cadena de asunto exacta más adelante:

system:serviceaccount:workload-demo:workload-reader

Si el espacio de nombres o el nombre de la cuenta de servicio cambia, la credencial federada también debe cambiar.

Crear la credencial de identidad federada

La credencial de identidad federada conecta Microsoft Entra con la cuenta de servicio de Kubernetes.

az identity federated-credential create \
  --resource-group rg-aks-demo \
  --identity-name id-aks-reader \
  --name fic-workload-reader \
  --issuer $AKS_OIDC_ISSUER \
  --subject system:serviceaccount:workload-demo:workload-reader \
  --audience api://AzureADTokenExchange

Este comando dice: los tokens emitidos por este emisor OIDC de AKS para esta cuenta de servicio de Kubernetes se pueden intercambiar por tokens como esta identidad administrada.

Ésa es la relación de confianza central. Todo lo demás es simplemente lograr que la cápsula lo use.

Relacionado: Configurar la federación de identidades de cargas de trabajo

Implementar un pod que utilice la identidad

Ahora crea un módulo de prueba. Las partes importantes son la cuenta de servicio y la etiqueta de identidad de la carga de trabajo.

apiVersion: v1
kind: Pod
metadata:
  name: azure-cli-test
  namespace: workload-demo
  labels:
    azure.workload.identity/use: "true"
spec:
  serviceAccountName: workload-reader
  containers:
    - name: azure-cli
      image: mcr.microsoft.com/azure-cli:latest
      command: ["/bin/sh", "-c"]
      args:
        - sleep 3600

Aplicar la vaina.

kubectl apply -f pod.yaml
kubectl wait --for=condition=Ready pod/azure-cli-test -n workload-demo --timeout=120s

La etiqueta indica al webhook de identidad de carga de trabajo que inserte las variables de entorno y el archivo de token que esperan el SDK y la CLI de Azure.

Verifique que el pod pueda usar Azure sin un secreto

Ejecute en el pod e inicie sesión con la identidad administrada.

kubectl exec -n workload-demo -it azure-cli-test -- /bin/sh

Dentro del contenedor, ejecute:

az login --federated-token "$(cat $AZURE_FEDERATED_TOKEN_FILE)" \
  --service-principal \
  --username $AZURE_CLIENT_ID \
  --tenant $AZURE_TENANT_ID

az group show --name rg-aks-demo --query name --output tsv

Si la asignación de roles es correcta, el comando devuelve el nombre del grupo de recursos. No se montó ningún secreto de cliente. No se copió ninguna contraseña en un secreto de Kubernetes. La carga de trabajo autenticada a través del token de la cuenta de servicio federada.

Solucionar fallas comunes

La identidad de la carga de trabajo tiene algunos modos de error predecibles. Utilice la siguiente tabla antes de cambiar piezas aleatorias.

Un buen orden de solución de problemas es:

kubectl get pod azure-cli-test -n workload-demo -o yaml
kubectl get serviceaccount workload-reader -n workload-demo -o yaml
az identity federated-credential list \
  --resource-group rg-aks-demo \
  --identity-name id-aks-reader
az role assignment list --assignee $IDENTITY_PRINCIPAL_ID --all

Si los objetos de Kubernetes se ven bien, verifique la credencial federada. Si la credencial parece correcta, verifique Azure RBAC.

Reemplace los secretos estáticos gradualmente

No migre todas las cargas de trabajo en un solo sprint. Comience con un pod que lea un servicio de Azure. Demuestre el camino de identidad, luego repita el patrón.

Para cada carga de trabajo, documente:

• Espacio de nombres y nombre de la cuenta de servicio.
• Nombre de identidad administrada.
• Nombre de la credencial de identidad federada.
• Asignación y alcance de roles de Azure.
• Servicio de Azure al que accede la carga de trabajo.

Esa lista se convierte en su mapa de propiedad. También facilita la respuesta a incidentes porque puede revocar la confianza de una carga de trabajo sin buscar secretos filtrados.

Limpiar la demostración

Cuando haya terminado de probar, elimine los recursos de demostración.

kubectl delete namespace workload-demo

az identity delete \
  --resource-group rg-aks-demo \
  --name id-aks-reader

Si creó el clúster de AKS solo para este tutorial, elimine el grupo de recursos.

az group delete --name rg-aks-demo --yes --no-wait

Dejar de enviar contraseñas en pods

La identidad de la carga de trabajo no es simplemente otra característica de AKS para activar. Es un mejor límite entre las cargas de trabajo de Kubernetes y los recursos de Azure.

El patrón es simple: habilite el emisor de OIDC, cree una identidad administrada, vincúlela a una cuenta de servicio de Kubernetes con una credencial de identidad federada y asigne a la identidad solo los permisos de Azure que necesita. Después de eso, el pod puede obtener tokens de Azure sin tener un secreto de cliente estático.

Comience con una carga de trabajo. Elimina un secreto almacenado. Demuestre el intercambio de tokens. Luego repita hasta que las credenciales estáticas se conviertan en la excepción en lugar de la predeterminada.