Roles de IAM para cuentas de servicio

Las aplicaciones de los contenedores de un Pod pueden usar un SDK de AWS o la AWS CLI para llevar a cabo solicitudes de API a Servicios de AWS mediante permisos de AWS Identity and Access Management (IAM). Las aplicaciones deben firmar sus solicitudes de API AWS con credenciales de AWS. Los roles de IAM para cuentas de servicio ofrecen la posibilidad de administrar las credenciales para las aplicaciones, de un modo similar a cómo los perfiles de instancia de Amazon EC2 proporcionan credenciales a instancias de Amazon EC2. En lugar de crear y distribuir las credenciales de AWS a los contenedores o de utilizar el rol de la instancia de Amazon EC2, puede asociar el rol de IAM con una cuenta de servicio de Kubernetes y configurar los Pods para usar la cuenta de servicio. No puede usar roles de IAM para cuentas de servicio con clústeres locales para Amazon EKS en AWS Outposts.

Los roles de IAM para cuentas de servicio ofrecen los siguientes beneficios:

• Privilegio mínimo: puede limitar los permisos de IAM a una cuenta de servicio y solo los Pods que utilizan esa cuenta de servicio tienen acceso a esos permisos. Esta característica también elimina la necesidad de soluciones de terceros como kiam o kube2iam.

• Aislamiento de credenciales: los contenedores de un Pod's solo pueden recuperar las credenciales para el rol de IAM asociado a la cuenta de servicio que usa el contenedor. Un contenedor nunca tiene acceso a credenciales que utilizan otros contenedores de otros Pods. Al utilizar roles de IAM para cuentas de servicio, los contenedores de Pod's también tienen los permisos asignados al rol de IAM del nodo de Amazon EKS, a menos que bloquee el acceso del Pod al servicio de metadatos de instancias (IMDS) de Amazon EC2. Para obtener más información, consulte Restringir el acceso al perfil de instancias asignado al nodo de trabajo.

• Auditabilidad: el acceso y el registro de eventos está disponible a través de AWS CloudTrail para garantizar una auditoría retrospectiva.

Siga estos procedimientos para habilitar los roles de IAM para cuentas de servicio:

1. Creación de un proveedor de OIDC de IAM para su clúster: solo complete este procedimiento una vez para cada clúster.

   nota

   Si habilita el punto de conexión de VPC de EKS, no se podrá acceder al punto de conexión del servicio OIDC de EKS desde el interior de esa VPC. Por lo tanto, no funcionarán operaciones tales como crear un proveedor de OIDC con eksctl en la VPC, y provocarán que se agote el tiempo de espera al intentar solicitar https://oidc.eks.region.amazonaws.com. A continuación se muestra un ejemplo de mensaje de error:

   ** server can't find oidc.eks.region.amazonaws.com: NXDOMAIN

   Para completar este paso, puede ejecutar el comando fuera de la VPC; por ejemplo, en AWS CloudShell o en un equipo conectado a Internet.

2. Configuración de una cuenta de servicio de Kubernetes para asumir un rol de IAM: complete este procedimiento para cada conjunto único de permisos que desee que tenga una aplicación.

3. Configuración de Pods para usar una cuenta de servicio de Kubernetes: complete este procedimiento para cada Pod que necesite acceso a Servicios de AWS.

4. Uso de un AWS SDK compatible— Confirme que la carga de trabajo utilice un SDK de AWS de una versión compatible y que utilice la cadena de credenciales predeterminada.

Información general de IAM, Kubernetes y OpenID Connect (OIDC)

En 2014, AWS Identity and Access Management agregó compatibilidad con identidades federadas mediante OpenID Connect (OIDC). Esta característica le permite autenticar llamadas a la API de AWS con proveedores de identidades compatibles y recibir un token web JSON (JWT) de OIDC válido. Puede transferir este token a la operación de API AWS STSAssumeRoleWithWebIdentity y recibir credenciales temporales del rol de IAM. Puede utilizar estas credenciales para interactuar con cualquier Servicio de AWS, como Amazon S3 y DynamoDB.

Cada token JWT está firmado por un par de claves de firma. Las claves se envían al proveedor de OIDC administrado por Amazon EKS y la clave privada cambia cada 7 días. Amazon EKS conserva las claves públicas hasta que caduquen. Si conecta clientes OIDC externos, tenga en cuenta que debe actualizar las claves de firma antes de que caduque la clave pública. Aprenda cómo Obtenga las claves de firma.

Kubernetes ha usado durante mucho tiempo las cuentas de servicio como su propio sistema de identidad interno. Pods se puede autenticar con el servidor de la API de Kubernetes mediante un token montado automáticamente (un JWT que no era OIDC) que solo podía validar el servidor de la API de Kubernetes. Estos tokens de cuenta de servicio heredados no caducan, y rotar la clave de firma es un proceso difícil. En Kubernetes, versión 1.12, se agregó compatibilidad para una nueva característica de ProjectedServiceAccountToken. Esta característica es un token web JSON de OIDC que también contiene la identidad de la cuenta de servicio y permite una audiencia configurable.

Amazon EKS aloja un punto de conexión de detección de OIDC público por clúster que contiene las claves de firma para los tokens web JSON ProjectedServiceAccountToken a fin de que los sistemas externos como IAM puedan validar y aceptar los tokens de OIDC que emite Kubernetes.