Roles de IAM para cuentas de servicio (IRSA)

Cuando un pod que se ejecuta en EKS necesita llamar a una API de AWS —por ejemplo, leer de S3 o escribir en DynamoDB— necesita credenciales de AWS. El enfoque ingenuo consiste en crear un usuario de IAM y codificar sus claves de acceso como variables de entorno. Esto es inseguro y vulnera el principio de privilegio mínimo, porque todos los pods del mismo nodo comparten las credenciales. IAM Roles for Service Accounts (IRSA) resuelve este problema vinculando roles de IAM detallados directamente a las cuentas de servicio de Kubernetes.

IRSA funciona mediante la federación de OpenID Connect (OIDC). EKS crea un proveedor OIDC para su clúster. Cuando un pod hace referencia a una cuenta de servicio anotada con un ARN de rol de IAM, EKS inyecta en el pod un token proyectado de cuenta de servicio firmado. El SDK de AWS del pod intercambia este token por credenciales temporales de AWS mediante la API AssumeRoleWithWebIdentity de AWS STS; no se necesitan claves de larga duración.

Antes de usar IRSA, debe asociar el emisor OIDC de EKS como proveedor de identidad de confianza en su cuenta de AWS. Esto crea un recurso de proveedor OIDC de IAM que AWS STS reconocerá. El comando eksctl se encarga de esto automáticamente. Una vez creado, puede verificarlo en la consola de IAM, en Proveedores de identidad.

El rol de IAM para IRSA debe tener una política de confianza que permita al proveedor OIDC asumirlo, con un alcance limitado a un espacio de nombres y una cuenta de servicio específicos de Kubernetes. La condición utiliza la notificación sub del token OIDC, cuyo valor es system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME. Esto garantiza que solo los pods que usan esa cuenta de servicio específica puedan asumir el rol, y no cualquier pod del clúster.

Cree una ServiceAccount de Kubernetes en el espacio de nombres de destino y anótela con el ARN del rol de IAM. Cuando un pod haga referencia a esta cuenta de servicio, EKS inyectará automáticamente el token OIDC y dos variables de entorno (AWS_WEB_IDENTITY_TOKEN_FILE y AWS_ROLE_ARN). El SDK de AWS las detecta automáticamente y llama a STS para obtener credenciales temporales; no es necesario cambiar el código de la aplicación.

En la especificación del pod o del despliegue, establezca serviceAccountName con el nombre de la cuenta de servicio anotada. Cuando EKS programe el pod, montará automáticamente el token OIDC en /var/run/secrets/eks.amazonaws.com/serviceaccount/token y establecerá las variables de entorno necesarias. Cualquier llamada a un SDK de AWS dentro del pod utilizará de forma transparente las credenciales del rol de IAM asignado, sin ninguna configuración explícita de credenciales.

Con un rol de IAM del nodo, todos los pods de un nodo heredan los mismos permisos; un pod comprometido puede acceder a todos los servicios de AWS a los que el nodo tenga permiso de acceso. Con IRSA, cada pod, mediante su cuenta de servicio, asume únicamente el rol que necesita. Esto aplica el principio de privilegio mínimo en el nivel del pod y limita el radio de impacto de cualquier incidente de seguridad. AWS recomienda usar IRSA en lugar de roles a nivel de nodo en todos los nuevos despliegues de EKS.

eksctl puede crear la asociación OIDC, el rol de IAM, la política de confianza y la anotación de Kubernetes de la ServiceAccount mediante un solo comando, usando create iamserviceaccount. Esta es la forma más sencilla de configurar IRSA sin escribir manualmente el JSON de la política de confianza. Especifique el espacio de nombres, el nombre de la cuenta de servicio y el ARN de la política de IAM que desea asociar; eksctl se encargará del resto.

Muchos complementos y controladores de EKS necesitan IRSA para funcionar: Cluster Autoscaler necesita permiso para llamar a la API de escalado automático de EC2, el AWS Load Balancer Controller necesita permiso para crear y administrar recursos de ELB, external-dns necesita acceso de escritura a Route 53 y el EBS CSI driver necesita permiso para crear y asociar volúmenes de EBS. Use siempre IRSA para estos componentes del sistema; nunca conceda estos permisos en el nivel del rol de IAM del nodo.

Los tokens de IRSA tienen una duración corta y el controlador de proyección de tokens de Kubernetes los rota automáticamente antes de que caduquen. La audiencia predeterminada del token es sts.amazonaws.com y su caducidad es de 24 horas, pero el controlador los actualiza cuando han transcurrido el 80 % de su duración. Las credenciales de AWS STS obtenidas mediante IRSA también son temporales, normalmente de 1 hora. Esta rotación automática elimina la carga de rotar credenciales asociada a las claves de acceso de IAM de larga duración.

Cada vez que un pod asume un rol de IAM mediante IRSA, AWS CloudTrail registra un evento AssumeRoleWithWebIdentity. El evento incluye el ARN del rol asumido, el asunto del token OIDC (system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT) y la IP de origen. Esto proporciona un registro de auditoría completo de qué pods accedieron a qué servicios de AWS y cuándo, algo fundamental para el cumplimiento y la investigación de incidentes en entornos regulados.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) tratados en esta lección.

En esta lección ha aprendido que IRSA utiliza la federación OIDC para intercambiar tokens de cuentas de servicio de Kubernetes por credenciales temporales de AWS; las políticas de confianza de los roles de IAM limitan el acceso a un espacio de nombres y una cuenta de servicio específicos; y IRSA proporciona un privilegio mínimo por pod, muy superior al de los roles de IAM a nivel de nodo. A continuación, exploraremos las métricas, los espacios de nombres y las dimensiones de CloudWatch para observar sus recursos de AWS.