Más información sobre cómo Pod Identity de EKS concede a los pods acceso a los servicios de AWS

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: Cuando se restringe el acceso al Servicio de metadatos de instancias (IMDS) de Amazon EC2, los contenedores de un pod 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. Si no se restringe el IMDS, los contenedores del pod también tienen acceso al rol de IAM del nodo de Amazon EKS y es posible que los contenedores puedan acceder a las credenciales de los roles de IAM de otros pods del mismo nodo. 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 facilitar una auditoría retrospectiva.

Operaciones independientes: en muchas organizaciones, la creación de proveedores de identidad de OIDC es una responsabilidad de equipos diferentes a la de administrar los clústeres de Kubernetes. Pod Identity de EKS tiene una clara separación de funciones, en donde toda la configuración de las asociaciones de Pod Identity de EKS se realiza en Amazon EKS y toda la configuración de los permisos de IAM se realiza en IAM.

Reutilización: La Pod Identity de EKS utiliza una única entidad principal de IAM en lugar de los principios independientes para cada clúster que utilizan los roles de IAM para cuentas de servicio. El administrador de IAM añade la siguiente entidad principal a la política de confianza de cualquier función para que Pod Identities de EKS puedan utilizarla.

            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            }

Escalabilidad: cada conjunto de credenciales temporales lo asume el servicio de autenticación de EKS en Pod Identity de EKS, en lugar de cada AWS SDK que se ejecuta en cada pod. A continuación, el agente de Pod Identity de Amazon EKS que se ejecuta en cada nodo emite las credenciales de los SDK. De este modo, la carga se reduce a una vez para cada nodo y no se duplica en cada pod. Para obtener más información del proceso, consulte Descripción del funcionamiento de Pod Identity de EKS.

Se admiten hasta 5000 asociaciones de EKS Pod Identity por clúster para asignar roles de IAM a cuentas de servicio de Kubernetes.

Asociación de roles de IAM: Cada cuenta de servicio de Kubernetes en un clúster se puede asociar a un rol de IAM de la misma cuenta de AWS que el clúster. Para cambiar el rol, edite la asociación de EKS Pod Identity. Para el acceso entre cuentas, delegue el acceso al rol mediante los roles de IAM. Para obtener más información, consulte Delegación del acceso entre cuentas de AWS mediante roles de IAM en la Guía del usuario de IAM.

Agente de EKS Pod Identity: Se requiere el agente de Pod Identity para utilizar EKS Pod Identity. El agente se ejecuta como un Kubernetes DaemonSet en los nodos del clúster y proporciona credenciales solo a los pods del mismo nodo. Utiliza la hostNetwork del nodo y ocupa los puertos 80 y 2703 en la dirección local de enlace (169.254.170.23 para IPv4, [fd00:ec2::23] para IPv6). Si IPv6 está deshabilitado en su clúster, deshabilite IPv6 para el agente de Pod Identity. Para obtener más información, consulte Deshabilitar IPv6 en el agente de EKS Pod Identity.

Consistencia eventual: Las asociaciones de EKS Pod Identity tienen consistencia final, con posibles demoras de varios segundos después de las llamadas a la API. Evite crear o actualizar asociaciones en rutas de código críticas y de alta disponibilidad. En cambio, realice estas acciones en rutinas de inicialización o configuración separadas y menos frecuentes. Para obtener más información, consulte Grupos de seguridad por pod en la Guía de prácticas recomendadas de EKS.

Consideraciones sobre el proxy y el grupo de seguridad: Para los pods que utilizan un proxy, añada 169.254.170.23 (IPv4) y [fd00:ec2::23] (IPv6) a las variables de entorno de no_proxy/NO_PROXY para evitar que se produzcan errores en las solicitudes al agente de EKS Pod Identity. Si utiliza grupos de seguridad para pods con la CNI de AWS VPC, establezca el indicador ENABLE_POD_ENI en “true” y el indicador POD_SECURITY_GROUP_ENFORCING_MODE “standard”. Para obtener más información, consulte Asignación de los grupos de seguridad a pods individuales.

Versiones del clúster de Amazon EKS enumeradas en el tema anterior Versiones del clúster de Pod Identity de EKS.

Nodos de trabajo del clúster que son instancias Linux Amazon EC2.

AWS Outposts.

Amazon EKS Anywhere.

Los clústeres de Kubernetes que se crean y ejecutan en Amazon EC2. Los componentes de Pod Identity de EKS solo están disponibles en Amazon EKS.

Pods que se ejecutan en cualquier lugar, excepto instancias Linux Amazon EC2. No se admiten los pods de Linux y Windows que se ejecutan en AWS Fargate (Fargate). No se admiten pods que se ejecutan en instancias Windows de Amazon EC2.