Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Opción 1: habilitar Pod Identity de EKS en el clúster de EKS
Las asociaciones de identidad de los pods de Amazon EKS permiten gestionar las credenciales de sus aplicaciones, de forma similar a como los perfiles de EC2 instancias de Amazon proporcionan credenciales a las EC2 instancias de Amazon. Pod Identity de Amazon EKS proporciona credenciales a sus cargas de trabajo con una API de autenticación de EKS adicional y un pod de agente que se ejecuta en cada nodo.
Amazon EMR en EKS comienza a admitir la identidad de pod de EKS desde la versión emr-7.3.0 para el modelo de envío. StartJobRun
Para obtener más información sobre Pod Identity de EKS, consulte Understand how EKS Pod Identity works.
¿Por qué Pod Identities de EKS?
Como parte de la configuración de EMR, la función de ejecución de trabajos debe establecer límites de confianza entre un rol de IAM y las cuentas de servicio en un espacio de nombres específico (de clústeres virtuales de EMR). Con IRSA, esto se logró mediante la actualización de la política de confianza del rol de ejecución de trabajos de EMR. Sin embargo, debido al límite estricto de 4096 caracteres en la longitud de la política de confianza de IAM, existía la restricción de compartir un único rol de IAM de ejecución de trabajos en un máximo de doce (12) clústeres de EKS.
Gracias a la compatibilidad de EMR con las identidades de pod, el equipo de EKS gestiona ahora el límite de confianza entre las funciones de IAM y las cuentas de servicio mediante la asociación entre las funciones de IAM y las cuentas de servicio. APIs
nota
El límite de seguridad de Pod Identity de EKS sigue estando en el nivel de la cuenta de servicio, no en el nivel del pod.
Consideraciones sobre Pod Identity
Para obtener información sobre las limitaciones de Pod Identity, consulte las consideraciones sobre Pod Identity de EKS.
Prepare Pod Identity de EKS en el clúster EKS
Comprueba si el permiso necesario existe en NodeInstanceRole
El rol de nodo NodeInstanceRole necesita un permiso para que el agente realice la acción AssumeRoleForPodIdentity en la API de autenticación de EKS. Puede añadir lo siguiente a Amazon EKSWorker NodePolicy, tal como se define en la Guía del usuario de Amazon EKS, o utilizar una política personalizada.
Si su clúster de EKS se creó con una versión eksctl superior a la 0.181.0, Amazon EKSWorkerNodePolicy, incluido el AssumeRoleForPodIdentity permiso requerido, se asociará automáticamente al rol de nodo. Si el permiso no está presente, añade manualmente el siguiente permiso a Amazon EKSWorker NodePolicy que te permita asumir un rol para la identidad del pod. El agente de Pod Identity de EKS necesita este permiso para recuperar las credenciales de los pods.
Crear un complemento agente de Pod Identity de EKS
Utilice el comando siguiente para crear el complemento agente de Pod Identity de EKS con la versión más reciente:
aws eks create-addon --cluster-name cluster-name --addon-name eks-pod-identity-agent kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
Siga estos pasos para crear el complemento agente de Pod Identity de EKS desde la consola de Amazon EKS:
Abra la consola de Amazon EK: consola de Amazon EKS
. En el panel de navegación izquierdo, seleccione Clústeres y, a continuación, seleccione el nombre del clúster para el que desea configurar el complemento de agente de Pod Identity de EKS.
Elija la pestaña Complementos.
Escoja Obtener más complementos.
Seleccione la casilla situada en la parte superior derecha del cuadro de complementos para el agente de Pod Identity de EKS y, a continuación, elija Siguiente.
En la página Configurar las opciones de complementos seleccionados, seleccione cualquier versión de la lista desplegable Versión.
(Opcional) Expanda Valores de configuración opcionales para introducir una configuración adicional. Por ejemplo, puede proporcionar una ubicación de imagen de contenedor alternativa e
ImagePullSecrets. El esquema JSON con las claves aceptadas se muestra en Esquema de configuración de complementos.Introduzca las claves y los valores de configuración en Valores de configuración.
Elija Siguiente.
Confirme que los pods agente se estén ejecutando en su clúster mediante la CLI.
kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
Un ejemplo de salida sería el siguiente:
NAME READY STATUS RESTARTS AGE eks-pod-identity-agent-gmqp7 1/1 Running 1 (24h ago) 24h eks-pod-identity-agent-prnsh 1/1 Running 1 (24h ago) 24h
Esto configura un nuevo DaemonSet en el espacio de kube-system nombres. El agente de identidad del pod de Amazon EKS, que se ejecuta en cada nodo de EKS, utiliza la AssumeRoleForPodIdentityacción para recuperar las credenciales temporales de la API de autenticación de EKS. Luego, estas credenciales están disponibles para las AWS SDKs que ejecute dentro de sus contenedores.
Para obtener más información, consulte el requisito previo del documento público: Configuración del agente de Pod Identity de Amazon EKS.
Crear un rol de ejecución de trabajos
Cree o actualice el rol de ejecución de trabajo que admite Pod Identity de EKS
Para ejecutar cargas de trabajo en Amazon EMR en EKS, debe crear un rol de IAM. En esta documentación, nos referimos a este rol como rol de ejecución de trabajos. Para obtener más información acerca de cómo crear el rol de IAM, consulte Creación de roles de IAM en la Guía del usuario.
Además, debe crear una política de IAM que especifique los permisos necesarios para el rol de ejecución de trabajos y, a continuación, adjuntar esta política a dicho rol para habilitar Pod Identity de EKS.
Por ejemplo, tiene el siguiente rol de ejecución de trabajos. Para obtener más información, consulte Create a job execution role.
arn:aws:iam::111122223333:role/PodIdentityJobExecutionRole
importante
Amazon EMR en EKS crea automáticamente cuentas de servicio de Kubernetes en función del nombre de su rol de ejecución de trabajos. Asegúrese de que el nombre del rol no sea demasiado largo, ya que su trabajo podría fallar si la combinación de cluster_name, pod_name y service_account_name supera el límite de longitud.
Configuración del rol de ejecución de trabajos: asegúrese de que el rol de ejecución de trabajos se haya creado con el siguiente permiso de confianza para Pod Identity de EKS. Para actualizar un rol de ejecución de trabajos existente, configúrelo para que confíe en la siguiente entidad principal de servicio de EKS como permiso adicional de la política de confianza. Este permiso de confianza puede coexistir con las políticas de confianza de IRSA existentes.
cat >trust-relationship.json <<EOF { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowEksAuthToAssumeRoleForPodIdentity", "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } EOF
Permiso de usuario: los usuarios necesitan el permiso iam:PassRole para ejecutar llamadas a la API StartJobRun o enviar trabajos. Este permiso permite a los usuarios transferir el rol de ejecución de trabajos a EMR en EKS. Los administradores de trabajos deberían tener el permiso de forma predeterminada.
A continuación, se muestra el permiso que necesita un usuario:
{ "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::111122223333:role/PodIdentityJobExecutionRole", "Condition": { "StringEquals": { "iam:PassedToService": "pods.eks.amazonaws.com" } } }
Para restringir aún más el acceso de los usuarios a clústeres de EKS específicos, añada el filtro de AssociatedResourceArn atributos a la política de IAM. Limita la asunción de roles a los clústeres de EKS autorizados, lo que refuerza los controles de seguridad a nivel de recursos.
"Condition": { "ArnLike": { "iam:AssociatedResourceARN": [ "arn:aws:eks:us-west-2:111122223333:cluster/*" ] }
Configurar las asociaciones de Pod Identity de EKS
Requisito previo
Asegúrese de que la identidad de IAM que crea la asociación de Pod Identity, como un usuario administrador de EKS, tenga el permiso eks:CreatePodIdentityAssociation yiam:PassRole.
Crear asociaciones para el rol y la cuenta de servicio EMR
Una vez que haya completado todos los pasos necesarios para Pod Identity de EKS, puede omitir los siguientes pasos para configurar el IRSA:
Puede pasar directamente al siguiente paso: Conceder a los usuarios acceso a Amazon EMR en EKS
Eliminar asociaciones de roles
Siempre que elimine un clúster virtual o un rol de ejecución de trabajos y ya no desee dar acceso a EMR a sus cuentas de servicio, debe eliminar las asociaciones del rol. Esto se debe a que EKS admite las asociaciones con recursos inexistentes (espacio de nombres y cuenta de servicio). Amazon EMR en EKS recomienda eliminar las asociaciones si se elimina el espacio de nombres o si el rol ya no se usa, a fin de liberar espacio para otras asociaciones.
nota
Si no las elimina, las asociaciones persistentes podrían afectar a su capacidad de escalado, ya que EKS tiene limitaciones en cuanto al número de asociaciones que puede crear (límite máximo: 1000 asociaciones por clúster). Puede enumerar las asociaciones de Pod Identity en un espacio de nombres determinado para comprobar si hay alguna asociación persistente que deba eliminarse:
aws eks list-pod-identity-associations --cluster-name mycluster --namespace mynamespace
Con la AWS CLI versión 2.24.0 o superior, ejecute el siguiente comando emr-containers para eliminar las asociaciones de funciones de EMR:
aws emr-containers delete-role-associations \ --cluster-name mycluster \ --namespace mynamespace \ --role-name JobExecutionRoleIRSAv2
Migrar automáticamente el IRSA existente a Pod Identity
Puede usar la herramienta eksctl para migrar los roles de IAM para las cuentas de servicio (IRSA) existentes a las asociaciones de Pod Identity:
eksctl utils migrate-to-pod-identity \ --cluster mycluster \ --remove-oidc-provider-trust-relationship \ --approve
Al ejecutar el comando sin la marca de --approve, solo se generará un plan que refleje los pasos de la migración y no se producirá ninguna migración real.
Resolución de problemas
Mi trabajo falló con ClassNotFound una excepción para el proveedor de credenciales, NoClassDefinitionFound o no pude obtener el proveedor de credenciales.
Pod Identity de EKS utiliza el proveedor de credenciales del contenedor para recuperar las credenciales necesarias. Si ha especificado un proveedor de credenciales personalizado, asegúrese de que funciona correctamente. Como alternativa, asegúrate de usar una versión correcta AWS del SDK que sea compatible con EKS Pod Identity. Para obtener más información, consulte Introducción a Amazon EKS.
El trabajo falló y el error «No se pudieron recuperar las credenciales debido al límite de tamaño [x]» que aparece en el eks-pod-identity-agent registro.
EMR en EKS crea cuentas de servicio de Kubernetes en función del nombre del rol de ejecución del trabajo. Si el nombre del rol es demasiado largo, EKS Auth no podrá recuperar las credenciales porque la combinación de cluster_name, pod_name, y service_account_name supera el límite de longitud. Identifique qué componente ocupa más espacio y ajuste el tamaño según corresponda.
El trabajo falló y en el eks-pod-identity registro aparece el error «No se pudieron recuperar las credenciales xxx».
Una posible causa de este problema podría ser que el clúster EKS esté configurado en subredes privadas sin PrivateLink configurarlo correctamente. Compruebe si el clúster está en una red privada y AWS PrivateLink configúrelo para solucionar el problema. Para obtener instrucciones detalladas, consulte Introducción a Amazon EKS.
