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.

# Habilitar los roles de IAM para el clúster de EKS
<a name="setting-up-enable-IAM-roles"></a>

En los siguientes temas se detallan las opciones para habilitar los roles de IAM.

**Topics**
+ [Opción 1: habilitar Pod Identity de EKS en el clúster de EKS](setting-up-enable-IAM.md)
+ [Opción 2: habilite los roles de IAM para las cuentas de servicio (IRSA) en el clúster de EKS](setting-up-enable-IAM-service-accounts.md)

# Opción 1: habilitar Pod Identity de EKS en el clúster de EKS
<a name="setting-up-enable-IAM"></a>

Las asociaciones de Pod Identity de Amazon EKS 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. 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](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html).

## ¿Por qué Pod Identities de EKS?
<a name="setting-up-enable-IAM-pod-identity-why"></a>

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
<a name="setting-up-enable-IAM-pod-identity-consider"></a>

Para obtener información sobre las limitaciones de Pod Identity, consulte las [consideraciones sobre Pod Identity de EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html#pod-id-considerations).

## Prepare Pod Identity de EKS en el clúster EKS
<a name="setting-up-enable-IAM-pod-eks-cluster"></a>

### Comprueba si el permiso necesario existe en NodeInstanceRole
<a name="setting-up-enable-IAM-pod-eks-cluster-permission"></a>

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](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/security-iam-awsmanpol.html#security-iam-awsmanpol-amazoneksworkernodepolicy), 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.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks-auth:AssumeRoleForPodIdentity"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowEKSAUTHAssumeroleforpodidentity"
    }
  ]
}
```

------

### Crear un complemento agente de Pod Identity de EKS
<a name="setting-up-enable-IAM-pod-eks-cluster-agent"></a>

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:

1. Abra la consola de Amazon EK: [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).

1. 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.

1. Elija la pestaña **Complementos**.

1. Escoja **Obtener más complementos**.

1. 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**.

1. En la página **Configurar las opciones de complementos seleccionados**, seleccione cualquier versión de la lista desplegable **Versión**.

1. (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**.

1. Elija **Siguiente**.

1. 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 [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html)acció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](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html).

## Crear un rol de ejecución de trabajos
<a name="setting-up-enable-IAM-pod-create-job-role"></a>

### Cree o actualice el rol de ejecución de trabajo que admite Pod Identity de EKS
<a name="setting-up-enable-IAM-pod-create-job-role-update"></a>

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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) 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](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html).

```
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
<a name="setting-up-enable-IAM-pod-identity-asociations"></a>

### Requisito previo
<a name="setting-up-enable-IAM-pod-identity-asociations-prereq"></a>

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` y`iam:PassRole`.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks:CreatePodIdentityAssociation"
      ],
      "Resource": [
        "arn:aws:eks:*:*:cluster/*"
      ],
      "Sid": "AllowEKSCreatepodidentityassociation"
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:PassRole"
      ],
      "Resource": [
        "arn:aws:iam::*:role/*"
      ],
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": "pods.eks.amazonaws.com"
        }
      },
      "Sid": "AllowIAMPassrole"
    }
  ]
}
```

------

### Crear asociaciones para el rol y la cuenta de servicio EMR
<a name="setting-up-enable-IAM-pod-identity-asociations-emr-service"></a>

------
#### [ Create EMR role associations through the AWS CLI ]

Cuando envía un trabajo a un espacio de nombres de Kubernetes, el administrador debe crear asociaciones entre el rol de ejecución de trabajos y la identidad de la cuenta de servicio administrado de EMR. Tenga en cuenta que la cuenta de servicio administrado de EMR se crea automáticamente en el momento del envío del trabajo y tiene como límite el espacio de nombres donde se envía el trabajo.

Con la versión 2.24.0 AWS CLI (anterior), ejecute el siguiente comando para crear asociaciones de roles con la identidad del pod.

Ejecute los siguientes comandos para crear asociaciones de roles con Pod Identity.

```
aws emr-containers create-role-associations \
        --cluster-name mycluster \
        --namespace mynamespace \
        --role-name JobExecutionRoleIRSAv2
```

Nota:
+ Cada clúster puede tener un límite de 1000 asociaciones. Todos los roles de ejecución de trabajos: el mapeo de espacios de nombres requerirá 3 asociaciones para los pods de remitente, controlador y ejecutor del trabajo.
+ Solo puedes asociar roles que estén en la misma AWS cuenta que el clúster. Puede delegar el acceso desde otra cuenta al rol de esta cuenta que haya configurado para que lo utilice Pod Identities de EKS. Para ver un tutorial sobre cómo delegar el acceso`AssumeRole`, consulte el [tutorial de IAM: Delegar el acceso entre AWS cuentas mediante funciones de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html).

------
#### [ Create EMR role associations through Amazon EKS ]

EMR crea una cuenta de servicio con un patrón de nombres determinado cuando se envía un trabajo. Para realizar asociaciones manuales o integrar este flujo de trabajo con el AWS SDK, sigue estos pasos:

Cree el nombre de la cuenta de servicio:

```
emr-containers-sa-spark-%(SPARK_ROLE)s-%(AWS_ACCOUNT_ID)s-%(BASE36_ENCODED_ROLE_NAME)s
```

Los siguientes ejemplos crean una asociación de roles para un ejemplo de rol de ejecución de tareas JobExecutionRoleIRSAv2.

**Ejemplos de asociaciones de roles:**

```
RoleName: JobExecutionRoleIRSAv2
Base36EncodingOfRoleName: 2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
```

**Ejemplo de comando CLI:**

```
# setup for the client service account (used by job runner pod)
# emr-containers-sa-spark-client-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-client-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe

# driver service account
# emr-containers-sa-spark-driver-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe        
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-driver-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe

# executor service account
# emr-containers-sa-spark-executor-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-executor-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
```

------

Una vez que haya completado todos los pasos necesarios para Pod Identity de EKS, puede omitir los siguientes pasos para configurar el IRSA:
+ [Habilite las funciones de IAM para las cuentas de servicio (IRSA) en el clúster EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html)
+ [Cree un rol de ejecución de tareas](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html)
+ [Actualice la política de confianza del rol de ejecución del trabajo](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html)

Puede pasar directamente al siguiente paso: [Conceder a los usuarios acceso a Amazon EMR en EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html)

## Eliminar asociaciones de roles
<a name="setting-up-enable-IAM-pod-identity-asociations-delete-associations"></a>

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
<a name="setting-up-enable-IAM-pod-identity-auto-migrate"></a>

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
<a name="setting-up-enable-IAM-pod-identity-troubleshooting"></a>

### Mi trabajo falló con ClassNotFound una excepción para el proveedor de credenciales, NoClassDefinitionFound o no pude obtener el proveedor de credenciales.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-no-class"></a>

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](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html).

### 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.
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds"></a>

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».
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds-error"></a>

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](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html).

# Opción 2: habilite los roles de IAM para las cuentas de servicio (IRSA) en el clúster de EKS
<a name="setting-up-enable-IAM-service-accounts"></a>

La característica de roles de IAM para cuentas de servicio está disponible en los nuevos clústeres de la versión 1.14 de Amazon EKS y posteriores, y para clústeres de EKS que se actualizaron a las versiones 1.13 o posteriores a partir del 3 de septiembre de 2019. Para utilizar esta característica, puede actualizar los clústeres de EKS existentes a la versión 1.14 o posteriores. Para obtener más información, consulte [Actualización de una versión de Kubernetes de clúster de Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html).

Si el clúster admite roles de IAM para cuentas de servicio, tiene asociada una URL de emisor de [OpenID Connect](https://openid.net/connect/). Puede ver esta URL en la consola de Amazon EKS o utilizar el siguiente AWS CLI comando para recuperarla.

**importante**  
Debe usar la última versión de AWS CLI para recibir el resultado correcto de este comando.

```
aws eks describe-cluster --name cluster_name --query "cluster.identity.oidc.issuer" --output text
```

El resultado esperado es el siguiente.

```
https://oidc.eks.<region-code>.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E
```

Para utilizar roles de IAM para cuentas de servicio en su clúster, debe crear un proveedor de identidad OIDC con [eksctl](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-eksctl) o la [Consola de administración de AWS](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-console).

## A fin de crear un proveedor de identidad de OIDC de IAM para su clúster con `eksctl`
<a name="setting-up-OIDC-eksctl"></a>

Consulte su versión de `eksctl` con el siguiente comando. En este procedimiento, se presupone que ha instalado `eksctl` y que su versión de `eksctl` es al menos 0.32.0 o posterior.

```
eksctl version
```

Para obtener más información sobre cómo instalar o actualizar eksctl, consulte [Instalación o actualización de eksctl](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html#installing-eksctl).

Cree su proveedor de identidad OIDC para su clúster con el siguiente comando. Reemplace *cluster\$1name* por su propio valor.

```
eksctl utils associate-iam-oidc-provider --cluster cluster_name --approve
```

## Para crear un proveedor de identidades OIDC de IAM para su clúster con el Consola de administración de AWS
<a name="setting-up-OIDC-console"></a>

Recupere la URL del emisor del OIDC de la descripción de su clúster en la consola Amazon EKS o utilice el siguiente comando. AWS CLI 

Utilice el siguiente comando para recuperar la URL del emisor de OIDC de la AWS CLI.

```
aws eks describe-cluster --name <cluster_name> --query "cluster.identity.oidc.issuer" --output text
```

Siga estos pasos para recuperar la URL del emisor de OIDC de la consola de Amazon EKS. 

1. Abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. En el panel de navegación, elija **Proveedores de identidad** y, a continuación, elija **Crear un proveedor**.

   1. En **Provider Type (Tipo de proveedor)**, elija **Choose a provider type (Elegir un tipo de proveedor)** y, luego, elija **OpenID Connect**.

   1. En **Provider URL (URL del proveedor)**, pegue la URL del emisor OIDC de su clúster.

   1. En Audiencia, ingrese sts.amazonaws.com y seleccione **Paso siguiente**.

1. Compruebe que la información del proveedor es correcta y, a continuación, seleccione **Create (Crear)** para crear su proveedor de identidad.

# Crear un rol de ejecución de trabajos
<a name="creating-job-execution-role"></a>

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 un rol de IAM, consulte [Creación de roles de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) en la Guía del usuario de IAM. 

También debe crear una política de IAM que especifique los permisos para el rol de ejecución de trabajos y, a continuación, adjuntar la política de IAM a dicho rol. 

La siguiente política para la función de ejecución de tareas permite el acceso a los objetivos de recursos, Amazon S3 y CloudWatch. Estos permisos son necesarios para supervisar los trabajos y acceder a los registros. Para seguir el mismo proceso, utilice AWS CLI: 

Cree el rol de IAM para la ejecución del trabajo: creemos el rol que EMR utilizará para la ejecución del trabajo. Este es el rol que asumirán los trabajos de EMR cuando se ejecuten en EKS.

```
cat <<EoF > ~/environment/emr-trust-policy.json
 {
   "Version": "2012-10-17",		 	 	 
   "Statement": [
     {
       "Effect": "Allow",
       "Principal": {
         "Service": "elasticmapreduce.amazonaws.com"
       },
       "Action": "sts:AssumeRole"
     }
   ]
 }
 EoF
  
 aws iam create-role --role-name EMRContainers-JobExecutionRole --assume-role-policy-document file://~/environment/emr-trust-policy.json
```

A continuación, debemos adjuntar las políticas de IAM requeridas al rol para que pueda escribir registros en s3 y cloudwatch.

```
cat <<EoF > ~/environment/EMRContainers-JobExecutionRole.json
 {
     "Version": "2012-10-17",		 	 	 
     "Statement": [
         {
             "Effect": "Allow",
             "Action": [
                 "s3:PutObject",
                 "s3:GetObject",
                 "s3:ListBucket"
             ],
             "Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
         },
         {
             "Effect": "Allow",
             "Action": [
                 "logs:PutLogEvents",
                 "logs:CreateLogStream",
               "logs:DescribeLogGroups",
                 "logs:DescribeLogStreams"
             ],
             "Resource": [
                 "arn:aws:logs:*:*:*"
             ]
         }
     ]
 } 
 EoF
 aws iam put-role-policy --role-name EMRContainers-JobExecutionRole --policy-name EMR-Containers-Job-Execution --policy-document file://~/environment/EMRContainers-JobExecutionRole.json
```

**nota**  
El acceso debe tener el alcance adecuado y no debe concederse a todos los objetos de S3 que desempeñen el rol de ejecución de trabajos.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket"
      ],
      "Sid": "AllowS3Putobject"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:PutLogEvents",
        "logs:CreateLogStream",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": [
        "arn:aws:logs:*:*:*"
      ],
      "Sid": "AllowLOGSPutlogevents"
    }
  ]
}
```

------

Para obtener más información, consulte [Usar funciones de ejecución de tareas](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/iam-execution-role.html), [Configurar una ejecución de tareas para usar registros de S3](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3) y [Configurar una ejecución de tareas para usar CloudWatch registros](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch).

# Actualizar la política de confianza del rol de ejecución de trabajos
<a name="setting-up-trust-policy"></a>

Cuando utiliza los roles de IAM para cuentas de servicio (IRSA) para ejecutar tareas en un espacio de nombres de Kubernetes, el administrador debe crear una relación de confianza entre el rol de ejecución de trabajos y la identidad de la cuenta de servicio administrada de EMR. Para crear la relación de confianza, se puede actualizar la política de confianza del rol de ejecución de trabajos. Tenga en cuenta que la cuenta de servicio administrado de EMR se crea automáticamente en el momento del envío del trabajo y tiene como límite el espacio de nombres donde se envía el trabajo.

Para actualizar la política de confianza, ejecute el siguiente comando.

```
 aws emr-containers update-role-trust-policy \
       --cluster-name cluster \
       --namespace namespace \
       --role-name iam_role_name_for_job_execution
```

Para obtener más información, consulte [Uso de roles de ejecución de trabajos con Amazon EMR en EKS](iam-execution-role.md).

**importante**  
El operador que ejecute el comando anterior debe tener los siguientes permisos: `eks:DescribeCluster`, `iam:GetRole`, `iam:UpdateAssumeRolePolicy`.