Azure Workload Identity frente a Managed Identity (AKS)

Una identidad de carga de trabajo (workload identity) es una identidad no humana asignada a software (un contenedor, un servicio, una función o una VM) para que pueda autenticarse ante otros servicios sin secretos incrustados en el código. En lugar de incrustar una clave de API o una contraseña, la carga de trabajo intercambia un token de corta duración emitido por un proveedor de confianza por acceso a recursos en la nube. Esto importa ahora porque se reporta ampliamente que las identidades no humanas superan en número a las humanas en los entornos cloud, y suelen tener privilegios permanentes más amplios, con peor rotación y monitoreo, que las cuentas humanas, lo que las convierte en una superficie de ataque principal.

Managed identity frente a workload identity: ¿cuál es la diferencia?

Estos términos se solapan, así que conviene ser preciso. Una managed identity (identidad administrada) es la implementación concreta de Microsoft para recursos de Azure (VM, App Service, Functions) en la que Azure gestiona por ti el ciclo de vida de la credencial: no hay secretos que guardar ni rotar. Workload identity es el concepto más amplio e independiente de la nube: cualquier identidad que represente una carga de trabajo, incluidas las managed identities, las cuentas de servicio de Kubernetes y las identidades federadas de proveedores externos.

La distinción clave:

• Managed identity funciona para cargas que se ejecutan dentro de las plataformas de cómputo de Azure.
• Workload identity federation (federación de identidades de carga de trabajo) extiende la confianza a cargas que se ejecutan fuera de la nube (GitHub Actions, Kubernetes on-premises u otra nube) sin guardar un secreto de larga duración.

Si tu carga vive en Azure, una managed identity suele ser la opción más sencilla. Si vive en otro sitio pero necesita recursos de Azure, usas la federación de identidades de carga de trabajo.

Azure workload identity frente a managed identity, en una respuesta: no son tanto alternativas como capas. Una managed identity es la identidad de Entra, y Azure gestiona sus credenciales. Microsoft Entra Workload ID (Azure workload identity) es el mecanismo de federación que permite a una carga que no puede usar directamente una managed identity, como un pod de AKS o un job de CI, intercambiar su propio token OIDC por un token de Entra. Esa credencial federada puede asociarse a una managed identity asignada por el usuario o a un registro de aplicación (no a una managed identity asignada por el sistema), así que en AKS es habitual usar ambas.

Cómo funciona workload identity en Kubernetes y AKS

La identidad de cargas de trabajo de Kubernetes resuelve un problema concreto: pods que necesitan credenciales de la nube sin montar secretos estáticos. Funciona mediante federación de tokens OpenID Connect (OIDC). El servidor de API del clúster actúa como emisor OIDC. Cada pod recibe un token de cuenta de servicio proyectado: un JWT de corta duración firmado por el clúster. El proveedor de nube se configura para confiar en ese emisor y mapear la cuenta de servicio de Kubernetes a una identidad de la nube.

El flujo es:

• Un pod se ejecuta bajo una cuenta de servicio de Kubernetes.
• Kubernetes proyecta en el pod un token OIDC firmado y con tiempo limitado.
• El pod presenta ese token al endpoint de IAM de la nube.
• La nube valida la firma contra el emisor de confianza y devuelve un token de acceso de corta duración limitado a la identidad de nube mapeada.

En Azure Kubernetes Service (AKS) esto se llama Microsoft Entra Workload ID. Anotas una cuenta de servicio de Kubernetes para vincularla a una aplicación de Entra o a una managed identity, habilitas el emisor OIDC en el clúster y configuras una credencial federada. El resultado: los pods se autentican ante Azure Key Vault, Storage o SQL sin secretos en el manifiesto. Esto sustituyó al modelo anterior y obsoleto AAD Pod Identity.

Identidad de cargas de trabajo de Kubernetes en Amazon EKS

En Amazon EKS, la identidad de cargas de trabajo de Kubernetes la proporcionan IAM Roles for Service Accounts (IRSA) y el más reciente EKS Pod Identity. Ambos permiten a un pod usar un rol de AWS IAM sin guardar claves de acceso.

• IRSA: registras el emisor OIDC del clúster como proveedor de identidad de IAM, anotas una cuenta de servicio de Kubernetes con el rol de IAM que debe usar (eks.amazonaws.com/role-arn) y el pod intercambia su token de cuenta de servicio proyectado con AWS STS (AssumeRoleWithWebIdentity) por credenciales temporales. La política de confianza del rol restringe qué namespace y qué cuenta de servicio pueden asumirlo.
• EKS Pod Identity: instalas el complemento EKS Pod Identity Agent y creas una asociación de identidad de pod entre una cuenta de servicio y un rol de IAM. No hace falta configurar un proveedor de identidad OIDC por clúster.

El patrón es el mismo que en AKS y GKE: un token de corta duración firmado por el clúster se cambia por credenciales de nube de corta duración y con alcance limitado. Dale a cada carga su propio rol en lugar de depender de un rol de nodo amplio que heredan todos los pods del nodo.

GCP Workload Identity y Workload Identity Federation

GKE Workload Identity (ahora llamado Workload Identity Federation for GKE) permite que los pods de Google Kubernetes Engine se autentiquen ante las API de Google Cloud. Puedes conceder roles de IAM directamente a una cuenta de servicio de Kubernetes, o vincularla a una cuenta de servicio de IAM para que el pod la suplante, y el servidor de metadatos de GKE gestiona automáticamente credenciales de corta duración; de nuevo, sin archivos de clave JSON descargados, que son una fuente habitual de filtración de credenciales.

Workload Identity Federation en GCP va más allá: permite que cargas de fuera de Google Cloud (AWS, Azure, on-premises o pipelines de CI/CD) suplanten una cuenta de servicio de Google usando sus tokens de identidad nativos. Configuras un pool de identidades de carga de trabajo y un proveedor que confía en un emisor OIDC o SAML externo. Un job de GitHub Actions, por ejemplo, puede desplegar en GCP con su propio token OIDC en lugar de una clave de cuenta de servicio guardada. El patrón es idéntico en todas las nubes: federar la confianza a un emisor, intercambiar tokens y conceder acceso de corta duración y limitado.

Las identidades de carga de trabajo en Microsoft Entra, y cómo gobernarlas

En Microsoft Entra, workload identities es el término colectivo para las entidades de servicio (service principals) y las managed identities: las aplicaciones y servicios que acceden a recursos en lugar de las personas. Entra ofrece ahora funciones de gobierno dedicadas para ellas, como Conditional Access para workload identities (restricción por ubicación o riesgo; una función de Workload Identities Premium), revisiones de acceso para entidades de servicio y detección de riesgos que marca inicios de sesión sospechosos con credenciales de aplicación.

Esta brecha de gobierno es el riesgo real. Como las identidades no humanas superan en número a las humanas y a menudo tienen privilegios permanentes amplios con peor rotación y monitoreo, una sola entidad de servicio con demasiados permisos y un secreto filtrado puede hacer más daño que un usuario comprometido. Controles prácticos que priorizar:

• Elimina los secretos estáticos: adopta la federación y las managed identities para que no haya nada de larga duración que robar.
• Limita el privilegio por carga de trabajo: una identidad por carga, no una supercuenta compartida.
• Inventaría y revisa: haz revisiones de acceso periódicas sobre las entidades de servicio y elimina las que no se usan.
• Monitorea el intercambio de tokens: alerta ante emisores inesperados o cambios en las credenciales federadas.

Si quieres cuantificar cuánto privilegio permanente tienen realmente tus identidades no humanas, la herramienta de puntuación de riesgo de identidad (Pro) de PlayCISO puntúa de 0 a 100 a un usuario humano, una cuenta de servicio o un agente de IA según radio de impacto, fortaleza de autenticación, exposición, gobierno y monitoreo, en tu navegador.