Implementación de identidad de carga de trabajo y administración de secretos para AKS

Completado

Problema de administración de credenciales en Kubernetes

Las cargas de trabajo en contenedores suelen necesitar autenticarse en servicios Azure: consultar Azure Storage, llamar a Azure OpenAI, leer desde Azure SQL o recuperar secretos de Azure Key Vault. El enfoque tradicional almacena las credenciales de estos servicios como secretos de Kubernetes y los monta en pods como variables de entorno o archivos. Este enfoque crea problemas persistentes.

Los secretos de Kubernetes están codificados en base64, no cifrados de forma predeterminada. Se conservan en el clúster indefinidamente a menos que se quiten explícitamente. Las credenciales de la entidad de servicio expiran, se renuevan o se revocan, y cada uno de estos casos exige actualizar tanto la credencial de origen como el secreto de Kubernetes, a menudo mediante un proceso manual coordinado entre todos los pods que las utilizan. El resultado es credenciales dispersas entre espacios de nombres, con propiedad poco clara, rotación incoherente y ninguna expiración automatizada. Un único pod en peligro puede filtrar secretos que persistan mucho después de que la carga de trabajo haya desaparecido.

Uso de Id. de carga de trabajo de Microsoft Entra para eliminar las credenciales almacenadas

Id. de carga de trabajo de Microsoft Entra resuelve el problema de credenciales reemplazando las credenciales almacenadas por identidad federada. En lugar de una contraseña o un secreto de cliente almacenado en el clúster, un pod presenta su token de cuenta de servicio de Kubernetes —un token de corta duración emitido por el punto de conexión de OpenID Connect (OIDC) del clúster de Azure Kubernetes Service (AKS)— y lo intercambia por un token de acceso de Microsoft Entra ID. Nunca se almacenan credenciales en el clúster.

El intercambio funciona a través de cinco componentes que funcionan juntos:

• Emisor OIDC de AKS: Cada clúster de AKS expone una dirección URL del emisor OIDC en la que Microsoft Entra confía como proveedor de identidades. Habilite en la creación del clúster o en un clúster existente con --enable-oidc-issuer.
• Anotación de cuenta de servicio deKubernetes: se anota una cuenta de servicio en el clúster con el identificador de cliente de un registro de aplicación de Microsoft Entra (azure.workload.identity/client-id).
• Credencial de identidad federada: se configura una credencial de identidad federada en el registro de la aplicación. Especifica la dirección URL del emisor de OIDC de AKS como el emisor de confianza y el espacio de nombres y el nombre de la cuenta de servicio como sujeto, por ejemplo, system:serviceaccount:retail-app:payment-svc.
• Webhook de identidad de carga de trabajo de Azure: controlador de admisión mutante que intercepta la creación de pods. En el caso de los pods que usan una cuenta de servicio anotada, inserta las variables de entorno necesarias : AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILE y monta un token de cuenta de servicio proyectado como un archivo.
• Token exchange en tiempo de ejecución: cuando la carga de trabajo llama al SDK de identidad de Azure mediante DefaultAzureCredential o WorkloadIdentityCredential, el SDK lee el archivo de token proyectado y lo presenta al punto de conexión del token de Microsoft Entra. Microsoft Entra valida el token con respecto a la configuración de la credencial federada y devuelve un token de acceso de ámbito limitado.

El pod nunca contiene una contraseña, un secreto de cliente o un certificado. Los tokens de acceso son de corta duración, se generan a petición y se limitan al recurso de Azure solicitado.

Habilite el emisor OIDC y la identidad de carga de trabajo en un clúster:

az aks update \
  --resource-group <resource-group> \
  --name <cluster-name> \
  --enable-oidc-issuer \
  --enable-workload-identity

Montaje de secretos de Key Vault directamente en los pods

El Container Storage Interface (CSI) del almacén de secretos de Azure Key Vault amplía la identidad de carga de trabajo a la recuperación de secretos. En lugar de almacenar valores confidenciales como secretos de Kubernetes y montarlos como variables de entorno, el controlador CSI monta los secretos, certificados y claves de Key Vault directamente en los pods como volúmenes. Los valores secretos nunca se escriben en etcd.

El controlador usa la identidad de carga de trabajo para autenticarse en Key Vault. Define un SecretProviderClass que asocia los objetos de Key Vault con la ruta de montaje, y el controlador los recupera cuando se inicia el pod:

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: keyvault-secrets
  namespace: retail-app
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    clientID: <workload-identity-client-id>
    keyvaultName: <key-vault-name>
    tenantID: <tenant-id>
    objects: |
      array:
        - |
          objectName: connection-string
          objectType: secret

El pod monta SecretProviderClass como volumen CSI. La cadena de conexión está disponible en la ruta de montaje como un archivo y nunca aparece en los secretos de Kubernetes ni en etcd.

Tip

El controlador CSI del almacén de secretos también puede sincronizar los secretos de Key Vault con los secretos de Kubernetes para las aplicaciones que requieren la inserción de variables de entorno. Utilice esta opción solo cuando sea necesario: el método de montaje de volúmenes CSI mantiene los secretos completamente fuera de etcd.

Autenticarse en Azure Container Registry sin usar secretos de extracción

Los secretos de extracción de imágenes almacenan en el clúster las credenciales del registro de contenedores. Cuando un nodo extrae una imagen, se autentica mediante el secreto, que debe ser válido, actual y accesible. Si el secreto caduca o se elimina, la descarga de imágenes falla.

Adjunte un Azure Container Registry (ACR) a un clúster de AKS y la identidad administrada del clúster controla automáticamente la autenticación:

az aks update \
  --resource-group <resource-group> \
  --name <cluster-name> \
  --attach-acr <acr-name>

Esto otorga a la identidad administrada del clúster el rol de AcrPull en el registro. La extracción de imágenes de nodo usa la identidad administrada: no se necesita imagePullSecret en las especificaciones del pod.

Aplicación de la identidad de carga de trabajo a las cargas de trabajo del agente de IA

La identidad de carga de trabajo es especialmente importante para los agentes de inteligencia artificial hospedados en AKS: orquestadores, servicios de llamada a funciones o flujos de trabajo de automatización que invocan Azure OpenAI, Fundición de IA de Azure o Azure API de Cognitive Services. Sin la identidad de la carga de trabajo, los equipos suelen almacenar claves de API como secretos de Kubernetes. Esas claves no expiran automáticamente, se pueden copiar fuera del clúster y crear dependencias de rotación difíciles de administrar a escala.

Con la identidad de carga de trabajo, un pod de agente de IA se autentica como un registro de aplicaciones de Microsoft Entra y llama a Azure OpenAI mediante un token de acceso con ámbito y de corta duración. El token no se puede reutilizar para otros recursos, expira automáticamente y el pod nunca contiene una credencial que se podría extraer y usar en otro lugar. Combine la identidad de carga de trabajo con Azure RBAC en el recurso Azure OpenAI: conceda el rol de usuario de OpenAI de Cognitive Services al registro de aplicaciones de la identidad de carga de trabajo en lugar de compartir una clave. Esto proporciona al agente acceso con privilegios mínimos que puede auditar, rotar y revocar de forma independiente.