**Ayude a mejorar esta página** 

Para contribuir a esta guía del usuario, elija el enlace **Edit this page on GitHub** que se encuentra en el panel derecho de cada página.

# Roles de IAM para cuentas de servicio
<a name="iam-roles-for-service-accounts"></a>

**sugerencia**  
 [Regístrese](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) en los próximos talleres de Amazon EKS.

Las aplicaciones de los contenedores de un pod pueden usar un SDK de AWS o 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 (IRSA)** 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](eks-outposts-local-cluster-overview.md).

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**: cuando se restringe el acceso al [Servicio de metadatos de instancias (IMDS) de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html), 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](create-node-role.md) 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](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods_recommendations).

**nota**  
Los pods configurados con `hostNetwork: true` siempre tendrán acceso al IMDS, pero los SDK y la CLI de AWS utilizarán credenciales IRSA cuando estén habilitados.
+  **Auditabilidad**: el acceso y el registro de eventos se encuentra disponible a través de AWS CloudTrail para garantizar una auditoría retrospectiva.

**importante**  
Los contenedores no son un límite de seguridad, y el uso de roles de IAM para las cuentas de servicio no cambia esta situación. Los pods asignados al mismo nodo compartirán un kernel y posiblemente otros recursos, según la configuración del pod. Aunque los pods que se ejecutan en nodos separados estarán aislados en la capa de procesamiento, hay aplicaciones de nodos que tienen permisos adicionales en la API de Kubernetes más allá del ámbito de una instancia individual. Algunos ejemplos son `kubelet`, `kube-proxy`, controladores de almacenamiento CSI o sus propias aplicaciones de Kubernetes.

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

1.  [Cree un proveedor de OIDC de IAM para el clúster:](enable-iam-roles-for-service-accounts.md) solo debe completar este procedimiento una vez para cada clúster.
**nota**  
Si habilitó el punto de conexión de VPC de EKS, no se podrá acceder al punto de conexión del servicio OIDC de EKS desde dentro 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 cant 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. Como alternativa, puede crear un solucionador condicional de horizonte dividido en la VPC, como Route 53 Resolver, para usar un solucionador diferente para la URL del emisor de OIDC y no usar el DNS de la VPC para ello. Para ver un ejemplo de reenvío condicional en CoreDNS, consulte [Amazon EKS feature request](https://github.com/aws/containers-roadmap/issues/2038) en GitHub.

1.  [Asigne roles de IAM a cuentas de servicio de Kubernetes:](associate-service-account-role.md) complete este procedimiento para cada conjunto único de permisos que desee que una aplicación tenga.

1.  [Configure los pods para que usen una cuenta de servicio de Kubernetes](pod-configuration.md): complete este procedimiento para cada pod que necesite acceder a los servicios de AWS.

1.  [Utilice ISRA con el AWS SDK](iam-roles-for-service-accounts-minimum-sdk.md): confirme que la carga de trabajo utilice un AWS SDK de una versión compatible y que utilice la cadena de credenciales predeterminada.

## Información general de IAM, Kubernetes y OpenID Connect (OIDC)
<a name="irsa-oidc-background"></a>

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 AWS con proveedores de identidad compatibles y recibir un token web JSON (JWT) de OIDC válido. Puede transferir este token a la operación API de AWS STS `AssumeRoleWithWebIdentity` 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 a [obtener las claves de firma para validar los tokens de OIDC](irsa-fetch-keys.md).

Kubernetes tiene cuentas de servicio de uso largo como su propio sistema de identidad interno. Los pods pueden autenticarse con el servidor de la API de Kubernetes mediante un token montado automáticamente (que era un JWT no OIDC) que solo el servidor de la API de Kubernetes podía validar. Estos tokens de cuenta de servicio heredados no caducan, y rotar la clave de firma es un proceso difícil. En la versión `1.12` de Kubernetes, 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.

# Crear un proveedor de OIDC de IAM para su clúster
<a name="enable-iam-roles-for-service-accounts"></a>

Su clúster tiene una URL de emisor de [OpenID Connect](https://openid.net/connect/) (OIDC) asociada. Para utilizar roles de AWS Identity and Access Management (IAM) para cuentas de servicio, debe existir un proveedor de OIDC de IAM para la URL del emisor de OIDC de su clúster.

## Requisitos previos
<a name="_prerequisites"></a>
+ Un clúster existente de Amazon EKS. Para implementar uno, consulte [Introducción a Amazon EKS](getting-started.md).
+ La versión `2.12.3` o posterior, o bien, la versión `1.27.160` o posterior de la AWS interfaz de la línea de comandos (AWS CLI) instalada y configurada en su dispositivo o AWS CloudShell. Para comprobar su versión actual, utilice `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Los administradores de paquetes, como `yum`, `apt-get` o Homebrew para macOS, suelen estar atrasados varias versiones respecto de la versión de la AWS CLI más reciente. Para instalar la versión más reciente, consulte [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) y [Configuración rápida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) en la *Guía del usuario de la interfaz de la línea de comandos de AWS*. La versión de AWS CLI instalada en AWS CloudShell también puede estar atrasada varias versiones respecto de la versión más reciente. Para actualizarla, consulte [Instalación de la CLI de AWS en su directorio principal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) en la *Guía del usuario de AWS CloudShell*.
+ La herramienta de línea de comandos de `kubectl` está instalada en su dispositivo o AWS CloudShell. La versión puede ser la misma o hasta una versión secundaria anterior o posterior a la versión de Kubernetes de su clúster. Por ejemplo, si la versión del clúster es `1.29`, puede usar la versión `1.28`, `1.29` o `1.30` de `kubectl` con él. Para instalar o actualizar `kubectl`, consulte [Configuración de `kubectl` y `eksctl`](install-kubectl.md).
+ Un archivo `config` de `kubectl` existente que contenga la configuración del clúster. Para crear un archivo `config` de `kubectl`, consulte [Conexión de kubectl a un clúster de EKS mediante la creación de un archivo kubeconfig](create-kubeconfig.md).

Puede crear un proveedor de OIDC de IAM para el clúster mediante `eksctl` o la Consola de administración de AWS.

## Creación de un proveedor de OIDC (eksctl)
<a name="_create_oidc_provider_eksctl"></a>

1. La versión `0.215.0` o posterior de la herramienta de línea de comandos de `eksctl` instalada en su dispositivo o AWS CloudShell. Para instalar o actualizar `eksctl`, consulte la sección de [Instalación](https://eksctl.io/installation) en la documentación de `eksctl`.

1. Determine el ID de emisor de OIDC correspondiente a su clúster.

   Recupere el ID de emisor de OIDC de su clúster y almacénelo en una variable. Reemplace `<my-cluster>` por su propio valor.

   ```
   cluster_name=<my-cluster>
   oidc_id=$(aws eks describe-cluster --name $cluster_name --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)
   echo $oidc_id
   ```

1. Determine si ya hay un proveedor de OIDC de IAM con el ID del proveedor de su clúster en su cuenta.

   ```
   aws iam list-open-id-connect-providers | grep $oidc_id | cut -d "/" -f4
   ```

   Si el comando anterior devuelve la salida, significa que ya tiene un proveedor de OIDC de IAM para su clúster y puede ir al siguiente paso. Si no se devuelve ninguna salida, debe crear un proveedor de OIDC de IAM para el clúster.

1. Cree un proveedor de identidad de OIDC de IAM para su clúster con el siguiente comando.

   ```
   eksctl utils associate-iam-oidc-provider --cluster $cluster_name --approve
   ```
**nota**  
Si habilitó el punto de conexión de VPC de EKS, no se podrá acceder al punto de conexión del servicio OIDC de EKS desde dentro de esa VPC. Por lo tanto, operaciones como la creación de un proveedor de OIDC con `eksctl` en la VPC no se ejecutarán correctamente y generarán un agotamiento del tiempo de espera. A continuación se muestra un ejemplo de mensaje de error:  

   ```
   ** server cant find oidc.eks.<region-code>.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. Como alternativa, puede crear un solucionador condicional de horizonte dividido en la VPC, como Route 53 Resolver, para usar un solucionador diferente para la URL del emisor de OIDC y no usar el DNS de la VPC para ello. Para ver un ejemplo de reenvío condicional en CoreDNS, consulte [Amazon EKS feature request](https://github.com/aws/containers-roadmap/issues/2038) en GitHub.

## Creación de un proveedor de OIDC (Consola de AWS)
<a name="create_oidc_provider_shared_aws_console"></a>

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

1. En el panel de la izquierda, seleccione **Clústeres** y, a continuación, seleccione el nombre de su clúster en la página **Clusters** (Clústeres).

1. En la sección de **Details** (Detalles) en la pestaña **Overview** (Resumen), anote el valor de la **OpenID Connect provider URL** (URL del proveedor de OpenID Connect).

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

1. En el panel de navegación, elija **Identity Providers** (Proveedores de identidad) en **Access management** (Administración de acceso). Si aparece un **Proveedor** que coincide con la URL de su clúster, ya cuenta con un proveedor para su clúster. Si no aparece un proveedor en la lista que coincida con la URL del clúster, debe crear uno.

1. Para crear un proveedor, elija **Add Provider** (Agregar proveedor).

1. En **Tipo de proveedor**, seleccione **OpenID Connect**.

1. En **URL de proveedor**, ingrese la URL del proveedor de OIDC correspondiente al clúster.

1. En **Audiencia**, ingrese `sts.amazonaws.com`.

1. (Opcional) Agregue cualquier etiqueta, por ejemplo, una para identificar qué clúster corresponde a este proveedor.

1. Elija **Agregar proveedor**.

Siguiente paso: [Asignación de roles de IAM a cuentas de servicio de Kubernetes](associate-service-account-role.md) 

# Asignación de roles de IAM a cuentas de servicio de Kubernetes
<a name="associate-service-account-role"></a>

En este tema, se explica cómo configurar una cuenta de servicio de Kubernetes para asumir un rol de AWS Identity and Access Management (IAM). Los pods que estén configurados para usar la cuenta de servicio pueden acceder a cualquier servicio de AWS al que el rol tenga permisos para acceder.

## Requisitos previos
<a name="_prerequisites"></a>
+ Un clúster existente. Si no tiene uno, puede crearlo mediante una de las siguientes guías de [Introducción a Amazon EKS](getting-started.md).
+ Cree un proveedor de OpenID Connect (OIDC) de IAM para su clúster. Para saber si ya tiene un proveedor o cómo crear uno, consulte [Crear un proveedor de OIDC de IAM para su clúster](enable-iam-roles-for-service-accounts.md).
+ La versión `2.12.3` o posterior, o bien, la versión `1.27.160` o posterior de la AWS interfaz de la línea de comandos (AWS CLI) instalada y configurada en su dispositivo o AWS CloudShell. Para comprobar su versión actual, utilice `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Los administradores de paquetes, como `yum`, `apt-get` o Homebrew para macOS, suelen estar atrasados varias versiones respecto de la versión de la AWS CLI más reciente. Para instalar la versión más reciente, consulte [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) y [Configuración rápida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) en la *Guía del usuario de la interfaz de la línea de comandos de AWS*. La versión de AWS CLI instalada en AWS CloudShell también puede estar atrasada varias versiones respecto de la versión más reciente. Para actualizarla, consulte [Instalación de la CLI de AWS en su directorio principal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) en la *Guía del usuario de AWS CloudShell*.
+ La herramienta de línea de comandos de `kubectl` está instalada en su dispositivo o AWS CloudShell. La versión puede ser la misma o hasta una versión secundaria anterior o posterior a la versión de Kubernetes de su clúster. Por ejemplo, si la versión del clúster es `1.29`, puede usar la versión `1.28`, `1.29` o `1.30` de `kubectl` con él. Para instalar o actualizar `kubectl`, consulte [Configuración de `kubectl` y `eksctl`](install-kubectl.md).
+ Un archivo `config` de `kubectl` existente que contenga la configuración del clúster. Para crear un archivo `config` de `kubectl`, consulte [Conexión de kubectl a un clúster de EKS mediante la creación de un archivo kubeconfig](create-kubeconfig.md).

## Paso 1: creación de una política de IAM
<a name="irsa-associate-role-procedure"></a>

Si desea asociar una política de IAM existente a su rol de IAM, vaya al siguiente paso.

1. Cree una política de IAM. Puede crear su propia política o copiar una política administrada de AWS que ya conceda algunos de los permisos que necesita y personalizarla según sus requisitos específicos. Para obtener más información, consulte [Creación de políticas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) en la *Guía del usuario de IAM*.

1. Cree un archivo que incluya los permisos para los servicios de AWS a los que quiere que accedan sus pods. Para obtener una lista de todas las acciones para todos los servicios de AWS, consulte la [Referencia de autorizaciones de servicio](https://docs.aws.amazon.com/service-authorization/latest/reference/).

   Puede ejecutar el siguiente comando para crear un archivo de política de ejemplo que permita el acceso de solo lectura a un bucket de Amazon S3. Opcionalmente, puede almacenar información de configuración o un script de arranque en este bucket, y los contenedores de su pod pueden leer el archivo desde el bucket y cargarlo en su aplicación. Si desea crear esta política de ejemplo, copie el siguiente contenido en su dispositivo. Sustituya *my-pod-secrets-bucket* por el nombre de su bucket y ejecute el comando.

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "s3:GetObject",
               "Resource": "arn:aws:s3:::my-pod-secrets-bucket"
           }
       ]
   }
   ```

1. Creación de la política de IAM.

   ```
   aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
   ```

## Paso 2: creación y asociación de un rol de IAM
<a name="_step_2_create_and_associate_iam_role"></a>

Cree un rol de IAM y asócielo a una cuenta de servicio de Kubernetes. Puede utilizar `eksctl` o la AWS CLI.

### Crear y asociar un rol (eksctl)
<a name="_create_and_associate_role_eksctl"></a>

Este comando `eksctl` crea una cuenta de servicio de Kubernetes en el espacio de nombres especificado, crea un rol de IAM (si no existe) con el nombre especificado, adjunta un ARN de política de IAM existente al rol y anota la cuenta de servicio con el ARN del rol de IAM. Asegúrese de reemplazar los valores de los marcadores de posición de muestra en este comando con sus valores específicos. Para instalar o actualizar `eksctl`, consulte la sección de [Instalación](https://eksctl.io/installation) en la documentación de `eksctl`.

```
eksctl create iamserviceaccount --name my-service-account --namespace default --cluster my-cluster --role-name my-role \
    --attach-policy-arn arn:aws:iam::111122223333:policy/my-policy --approve
```

**importante**  
Si el rol o la cuenta de servicio ya existen, podría producirse un error al ejecutar el comando anterior. `eksctl` tiene diferentes opciones que puede proporcionar en esas situaciones. Para obtener más información, ejecute `eksctl create iamserviceaccount --help`.

### Crear y asociar un rol (AWS CLI)
<a name="create_and_associate_role_shared_aws_cli"></a>

Si tiene una cuenta de servicio de Kubernetes existente que desea que asuma un rol de IAM, puede omitir este paso.

1. Cree una cuenta de servicio de Kubernetes. Copie los siguientes contenidos en su dispositivo. Reemplace *my-service-account* por el nombre que desee y *default* por un espacio de nombres diferente, si es necesario. Si cambia *default*, el espacio de nombres debe existir previamente.

   ```
   cat >my-service-account.yaml <<EOF
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: my-service-account
     namespace: default
   EOF
   kubectl apply -f my-service-account.yaml
   ```

1. Establezca su ID de cuenta de AWS en una variable de entorno con el siguiente comando.

   ```
   account_id=$(aws sts get-caller-identity --query "Account" --output text)
   ```

1. Establezca el proveedor de identidades de OIDC en una variable de entorno con el siguiente comando. Reemplace *my-cluster* por el nombre de su clúster.

   ```
   oidc_provider=$(aws eks describe-cluster --name my-cluster --region $AWS_REGION --query "cluster.identity.oidc.issuer" --output text | sed -e "s/^https:\/\///")
   ```

1. Establezca variables para el espacio de nombres y el nombre de la cuenta de servicio. Reemplace *my-service-account* por la cuenta de servicio de Kubernetes que desea que asuma el rol. Reemplace *default* por el espacio de nombres de la cuenta de servicio.

   ```
   export namespace=default
   export service_account=my-service-account
   ```

1. Ejecute el siguiente comando para crear un archivo de política de confianza para el rol de IAM. Si quiere permitir que todas las cuentas de servicio de un espacio de nombres utilicen el rol, copie el siguiente contenido en su dispositivo. Reemplace *StringEquals* por `StringLike` y reemplace *\$1service\$1account* por `*`. Puede agregar varias entradas en las condiciones `StringEquals` y `StringLike` para permitir que varias cuentas de servicio o espacios de nombres asuman el rol. Para permitir que los roles de una cuenta de AWS diferente a la de su clúster asuman el rol, consulte [Autenticación en otra cuenta mediante IRSA](cross-account-access.md) para obtener más información.

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Federated": "arn:aws:iam::123456789012:oidc-provider/$oidc_provider"
         },
         "Action": "sts:AssumeRoleWithWebIdentity",
         "Condition": {
           "StringEquals": {
             "$oidc_provider:aud": "sts.amazonaws.com",
             "$oidc_provider:sub": "system:serviceaccount:$namespace:$service_account"
           }
         }
       }
     ]
   }
   ```

1. Creación del rol. Reemplace *my-role* con un nombre para el rol de IAM, y *my-role-description* con una descripción de su rol.

   ```
   aws iam create-role --role-name my-role --assume-role-policy-document file://trust-relationship.json --description "my-role-description"
   ```

1. Adjunte la política de IAM al rol. Reemplace *my-role* por el nombre de su rol de IAM y *my-policy* por el nombre de una política existente que haya creado.

   ```
   aws iam attach-role-policy --role-name my-role --policy-arn=arn:aws:iam::$account_id:policy/my-policy
   ```

1. Anote su cuenta de servicio con el nombre de recurso de Amazon (ARN) del rol de IAM que desea que asuma la cuenta de servicio. Reemplace *my-role* por el nombre de su rol de IAM existente. Supongamos que permitió que un rol de una cuenta de AWS diferente a la de su clúster asumiera el rol en un paso anterior. A continuación, asegúrese de especificar la cuenta de AWS y el rol de la otra cuenta. Para obtener más información, consulte [Autenticación en otra cuenta mediante IRSA](cross-account-access.md).

   ```
   kubectl annotate serviceaccount -n $namespace $service_account eks.amazonaws.com/role-arn=arn:aws:iam::$account_id:role/my-role
   ```

1. (Opcional) [Configure el punto de conexión de AWS Security Token Service para una cuenta de servicio](configure-sts-endpoint.md). AWS recomienda el uso de un punto de conexión regional de AWS STS en lugar del punto de conexión global. Esto reduce la latencia, proporciona redundancia integrada y aumenta la validez de los tokens de sesión.

## Paso 3: confirmación de la configuración
<a name="irsa-confirm-role-configuration"></a>

1. Confirme que la política de confianza del rol de IAM se haya configurado correctamente.

   ```
   aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
   ```

   Un ejemplo de salida sería el siguiente.

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
               },
               "Action": "sts:AssumeRoleWithWebIdentity",
               "Condition": {
                   "StringEquals": {
                       "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account",
                       "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
                   }
               }
           }
       ]
   }
   ```

1. Confirme que la política que adjuntó a su rol en un paso anterior se encuentre adjunta al rol.

   ```
   aws iam list-attached-role-policies --role-name my-role --query "AttachedPolicies[].PolicyArn" --output text
   ```

   Un ejemplo de salida sería el siguiente.

   ```
                  arn:aws:iam::111122223333:policy/my-policy
   ```

1. Establezca una variable para almacenar el nombre de recurso de Amazon (ARN) de la política que quiera utilizar. Reemplace *my-policy* por el nombre de la política para la que desea confirmar los permisos.

   ```
   export policy_arn=arn:aws:iam::111122223333:policy/my-policy
   ```

1. Vea la versión predeterminada de la política.

   ```
   aws iam get-policy --policy-arn $policy_arn
   ```

   Un ejemplo de salida sería el siguiente.

   ```
   {
       "Policy": {
           "PolicyName": "my-policy",
           "PolicyId": "EXAMPLEBIOWGLDEXAMPLE",
           "Arn": "arn:aws:iam::111122223333:policy/my-policy",
           "Path": "/",
           "DefaultVersionId": "v1",
           [...]
       }
   }
   ```

1. Vea el contenido de la política para asegurarse de que incluye todos los permisos que su pod necesita. Si es necesario, reemplace *1* en el siguiente comando por la versión devuelta en la salida anterior.

   ```
   aws iam get-policy-version --policy-arn $policy_arn --version-id v1
   ```

   Un ejemplo de salida sería el siguiente.

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "s3:GetObject",
               "Resource": "arn:aws:s3:::my-pod-secrets-bucket"
           }
       ]
   }
   ```

   Si creó la política de ejemplo en un paso anterior, el resultado es el mismo. Si creó una política diferente, el contenido de *example* es diferente.

1. Confirme que la cuenta de servicio de Kubernetes se anota con el rol.

   ```
   kubectl describe serviceaccount my-service-account -n default
   ```

   Un ejemplo de salida sería el siguiente.

   ```
   Name:                my-service-account
   Namespace:           default
   Annotations:         eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-role
   Image pull secrets:  <none>
   Mountable secrets:   my-service-account-token-qqjfl
   Tokens:              my-service-account-token-qqjfl
   [...]
   ```

## Siguientes pasos
<a name="_next_steps"></a>
+  [Configuración de pods para usar una cuenta de servicio de Kubernetes](pod-configuration.md) 

# Configuración de pods para usar una cuenta de servicio de Kubernetes
<a name="pod-configuration"></a>

Si un pod necesita acceder a los servicios de AWS, debe configurarlo para que use una cuenta de servicio de Kubernetes. La cuenta de servicio debe estar asociada a un rol de AWS Identity and Access Management (IAM) que tenga permisos para acceder a los servicios de AWS.
+ Un clúster existente. Si no tiene uno, puede crearlo mediante una de las guías de [Introducción a Amazon EKS](getting-started.md).
+ Cree un proveedor de OpenID Connect (OIDC) de IAM para su clúster. Para saber si ya tiene un proveedor o cómo crear uno, consulte [Crear un proveedor de OIDC de IAM para su clúster](enable-iam-roles-for-service-accounts.md).
+ Una cuenta de servicio de Kubernetes asociada a un rol de IAM. La cuenta de servicio debe estar anotada con el nombre de recurso de Amazon (ARN) del rol de IAM. El rol debe tener una política de IAM asociada que contenga los permisos que desee que tengan sus pods para usar servicios de AWS. Para obtener más información acerca de cómo crear y configurar la cuenta de servicio y el rol, consulte [Asignación de roles de IAM a cuentas de servicio de Kubernetes](associate-service-account-role.md).
+ La versión `2.12.3` o posterior, o bien, la versión `1.27.160` o posterior de la AWS interfaz de la línea de comandos (AWS CLI) instalada y configurada en su dispositivo o AWS CloudShell. Para comprobar su versión actual, utilice `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Los administradores de paquetes, como `yum`, `apt-get` o Homebrew para macOS, suelen estar atrasados varias versiones respecto de la versión de la AWS CLI más reciente. Para instalar la versión más reciente, consulte [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) y [Configuración rápida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) en la *Guía del usuario de la interfaz de la línea de comandos de AWS*. La versión de AWS CLI instalada en AWS CloudShell también puede estar atrasada varias versiones respecto de la versión más reciente. Para actualizarla, consulte [Instalación de la CLI de AWS en su directorio principal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) en la *Guía del usuario de AWS CloudShell*.
+ La herramienta de línea de comandos de `kubectl` está instalada en su dispositivo o AWS CloudShell. La versión puede ser la misma o hasta una versión secundaria anterior o posterior a la versión de Kubernetes de su clúster. Por ejemplo, si la versión del clúster es `1.29`, puede usar la versión `1.28`, `1.29` o `1.30` de `kubectl` con él. Para instalar o actualizar `kubectl`, consulte [Configuración de `kubectl` y `eksctl`](install-kubectl.md).
+ Un archivo `config` de `kubectl` existente que contenga la configuración del clúster. Para crear un archivo `config` de `kubectl`, consulte [Conexión de kubectl a un clúster de EKS mediante la creación de un archivo kubeconfig](create-kubeconfig.md).

  1. Use el siguiente comando para crear un manifiesto de implementación que puede implementar en un pod con el que se puede confirmar la configuración. Sustituya los valores de ejemplo por sus propios valores.

     ```
     cat >my-deployment.yaml <<EOF
     apiVersion: apps/v1
     kind: Deployment
     metadata:
       name: my-app
     spec:
       selector:
         matchLabels:
           app: my-app
       template:
         metadata:
           labels:
             app: my-app
         spec:
           serviceAccountName: my-service-account
           containers:
           - name: my-app
             image: public.ecr.aws/nginx/nginx:X.XX
     EOF
     ```

  1. Implemente el manifiesto en el clúster.

     ```
     kubectl apply -f my-deployment.yaml
     ```

  1. Confirme que existan las variables de entorno necesarias para su pod.

     1. Consulte los pods que se implementaron en el paso anterior.

        ```
        kubectl get pods | grep my-app
        ```

        Un ejemplo de salida sería el siguiente.

        ```
        my-app-6f4dfff6cb-76cv9   1/1     Running   0          3m28s
        ```

     1. Consulte el ARN del rol de IAM que esté utilizando el pod.

        ```
        kubectl describe pod my-app-6f4dfff6cb-76cv9 | grep AWS_ROLE_ARN:
        ```

        Un ejemplo de salida sería el siguiente.

        ```
        AWS_ROLE_ARN:                 arn:aws:iam::111122223333:role/my-role
        ```

        El ARN del rol debe coincidir con el ARN del rol con el que anotó la cuenta de servicio existente. Para obtener más información sobre cómo anotar la cuenta de servicio, consulte [Asignación de roles de IAM a cuentas de servicio de Kubernetes](associate-service-account-role.md).

     1. Confirme que el pod tenga un montaje de archivo de token de identidad web.

        ```
        kubectl describe pod my-app-6f4dfff6cb-76cv9 | grep AWS_WEB_IDENTITY_TOKEN_FILE:
        ```

        Un ejemplo de salida sería el siguiente.

        ```
        AWS_WEB_IDENTITY_TOKEN_FILE:  /var/run/secrets/eks.amazonaws.com/serviceaccount/token
        ```

        El `kubelet` solicita y almacena el token en nombre del pod. De forma predeterminada, el `kubelet` actualiza el token si tiene más del 80 % de su tiempo de vida total o más de 24 horas. Puede modificar la duración del vencimiento de cualquier cuenta, excepto la cuenta de servicio predeterminada, con la configuración en la especificación del pod. Para obtener más información, consulte [Proyección del volumen del token de la cuenta de servicio](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#serviceaccount-token-volume-projection) en la documentación de Kubernetes.

        El [webhook de Pod Identity de Amazon EKS](https://github.com/aws/amazon-eks-pod-identity-webhook#amazon-eks-pod-identity-webhook) del clúster observa los pods que usan una cuenta de servicio con la siguiente anotación:

        ```
        eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-role
        ```

        El webhook aplica las variables de entorno anteriores a esos pods. El clúster no necesita utilizar el webhook para configurar las variables de entorno y los montajes de archivos de token. Puede configurar manualmente los pods para que tengan estas variables de entorno. Las [versiones compatibles del SDK de AWS](iam-roles-for-service-accounts-minimum-sdk.md) buscan primero estas variables de entorno en el proveedor de la cadena de credenciales. Las credenciales del rol se utilizan para los pods que cumplen estos criterios.

  1. Confirme que sus pods puedan interactuar con los servicios de AWS mediante los permisos que asignó en la política de IAM adjunta a su rol.
**nota**  
Cuando un pod utiliza credenciales de AWS de un rol de IAM asociado a una cuenta de servicio, la AWS CLI u otros SDK de los contenedores de ese pod utilizan las credenciales proporcionadas por dicho rol. Si no restringe el acceso a las credenciales que se proporcionan al [rol de IAM del nodo de Amazon EKS](create-node-role.md), el pod sigue teniendo acceso a esas credenciales. Para obtener más información, consulte [Restringir el acceso al perfil de instancias asignado al nodo de trabajo](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).

     Si sus pods no pueden interactuar con los servicios como esperaba, siga estos pasos para confirmar que todo esté configurado correctamente.

     1. Confirme que los pods usen una versión del AWS SDK que admita asumir un rol de IAM a través de un archivo de token de identidad web de OpenID Connect. Para obtener más información, consulte [Uso de IRSA con el SDK de AWS](iam-roles-for-service-accounts-minimum-sdk.md).

     1. Confirme que la implementación use la cuenta de servicio.

        ```
        kubectl describe deployment my-app | grep "Service Account"
        ```

        Un ejemplo de salida sería el siguiente.

        ```
        Service Account:  my-service-account
        ```

     1. Si sus pods siguen sin poder acceder a los servicios, revise los [pasos](associate-service-account-role.md#irsa-confirm-role-configuration) que se describen en [Asignación de roles de IAM a cuentas de servicio de Kubernetes](associate-service-account-role.md) para confirmar que el rol y la cuenta de servicio se hayan configurado correctamente.

# Configure el punto de conexión AWS Security Token Service de una cuenta de servicio
<a name="configure-sts-endpoint"></a>

Si utiliza una cuenta de servicio de Kubernetes con [roles de IAM para cuentas de servicio](iam-roles-for-service-accounts.md), puede configurar el tipo de punto de conexión de AWS Security Token Service utilizado por la cuenta de servicio.

 AWS recomienda utilizar los puntos de conexión de AWS STS regionales en lugar del punto de conexión global. Esto reduce la latencia, proporciona redundancia integrada y aumenta la validez de los tokens de sesión. AWS Security Token Service debe estar activo en la región de AWS donde el pod se ejecuta. Además, su aplicación debe tener incorporada una redundancia para una región de AWS diferente en caso de que ocurra un error en el servicio en la región de AWS. Para obtener más información, consulte [Administración de AWS STS en una región de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html) en la Guía del usuario de IAM.
+ Un clúster existente. Si no tiene uno, puede crearlo mediante una de las guías en [Introducción a Amazon EKS](getting-started.md).
+ Un proveedor de OIDC de IAM existente para el clúster. Para obtener más información, consulte [Crear un proveedor de OIDC de IAM para su clúster](enable-iam-roles-for-service-accounts.md).
+ Una cuenta de servicio de Kubernetes existente configurada para su uso con la característica [IAM de Amazon EKS para cuentas de servicio](iam-roles-for-service-accounts.md).

Todos los siguientes ejemplos utilizan la cuenta de servicio de Kubernetes aws-node utilizada por el [complemento CNI de Amazon VPC](cni-iam-role.md). Puede reemplazar los *valores de ejemplo* por sus propias cuentas de servicio, pods, espacios de nombres y otros recursos.

1. Seleccione un pod que utilice una cuenta de servicio para la que desee cambiar el punto de conexión. Determine en qué región de AWS se ejecuta el pod. Reemplace *aws-node-6mfgv* por el nombre de su pod y *kube-system* con el espacio de nombres de su pod.

   ```
   kubectl describe pod aws-node-6mfgv -n kube-system |grep Node:
   ```

   Un ejemplo de salida sería el siguiente.

   ```
   ip-192-168-79-166.us-west-2/192.168.79.166
   ```

   En el resultado anterior, el pod se ejecuta en un nodo de la región de AWS us-west-2.

1. Determine el tipo de punto de conexión que utiliza la cuenta de servicio del pod.

   ```
   kubectl describe pod aws-node-6mfgv -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
   ```

   Un ejemplo de salida sería el siguiente.

   ```
   AWS_STS_REGIONAL_ENDPOINTS: regional
   ```

   Si el punto de conexión actual es global, `global` se devuelven en la salida. Si no se devuelve ningún resultado, el tipo de punto de conexión predeterminado está en uso y no se ha anulado.

1. Si la versión de clúster o plataforma es la misma o posterior a las enumeradas en la tabla, puede cambiar el tipo de punto de conexión utilizado por la cuenta de servicio del tipo predeterminado a otro con uno de los siguientes comandos. Reemplace *aws-node* con el nombre de su cuenta de servicio y *kube-system* con el espacio de nombres de su cuenta de servicio.
   + Si el tipo de punto de conexión predeterminado o actual es global y desea cambiarlo a regional:

     ```
     kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=true
     ```

     Si utiliza [roles de IAM para cuentas de servicio](iam-roles-for-service-accounts.md) con el fin de generar URL de S3 previamente firmadas en la aplicación que se ejecuta en los contenedores de los pods, el formato de la URL de los puntos de conexión regionales es similar al siguiente ejemplo:

     ```
     https://bucket.s3.us-west-2.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
     ```
   + Si el tipo de punto de conexión predeterminado o actual es regional y desea cambiarlo a global:

     ```
     kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=false
     ```

     Si su aplicación realiza solicitudes explícitamente a puntos de conexión globales de AWS STS y no anula el comportamiento predeterminado de utilizar puntos de conexión regionales en clústeres de Amazon EKS, las solicitudes fallarán y mostrarán un error. Para obtener más información, consulte [Los contenedores de pods muestran el siguiente error: `An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region`](security-iam-troubleshoot.md#security-iam-troubleshoot-wrong-sts-endpoint).

     Si utiliza [roles de IAM para cuentas de servicio](iam-roles-for-service-accounts.md) con el fin de generar URL de S3 previamente firmadas en la aplicación que se ejecuta en los contenedores de los pods, el formato de la URL de los puntos de conexión globales es similar al siguiente ejemplo:

     ```
     https://bucket.s3.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
     ```

   Si tiene una automatización que espera la URL prefirmada en un formato específico, o si su aplicación o sus dependencias descendentes que utilizan URL prefirmadas requieren una región de AWS de destino específica, realice los cambios necesarios para utilizar el punto de conexión de AWS STS.

1. Elimine y vuelva a crear todos los pods existentes asociados a la cuenta de servicio para aplicar las variables de entorno de credenciales. El enlace web mutante no se aplica a los pods que ya están en ejecución. Puede reemplazar *pods*, *kube-system* y *-l k8s-app=aws-node* por la información de los pods para los que configuró la anotación.

   ```
   kubectl delete Pods -n kube-system -l k8s-app=aws-node
   ```

1. Confirme que todos los pods se reiniciaron.

   ```
   kubectl get Pods -n kube-system -l k8s-app=aws-node
   ```

1. Consulte las variables de entorno de uno de los pods. Compruebe que el valor `AWS_STS_REGIONAL_ENDPOINTS` sea el que estableció en un paso anterior.

   ```
   kubectl describe pod aws-node-kzbtr -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
   ```

   Un ejemplo de salida sería el siguiente.

   ```
   AWS_STS_REGIONAL_ENDPOINTS=regional
   ```

# Autenticación en otra cuenta mediante IRSA
<a name="cross-account-access"></a>

Puede configurar permisos de IAM entre cuentas mediante la creación de un proveedor de identidades a partir del clúster de otra cuenta o mediante operaciones `AssumeRole` encadenadas. En los siguientes ejemplos, la *cuenta A* posee un clúster de Amazon EKS que admite roles de IAM para las cuentas de servicio. Los pods que se ejecutan en ese clúster deben asumir permisos de IAM de la *cuenta B*.
+  La **opción 1** es más sencilla, pero requiere que la cuenta B cree y administre un proveedor de identidad OIDC para el clúster de la cuenta A.
+  **La opción 2** mantiene la administración del OIDC en la cuenta A, pero requiere el encadenamiento de funciones a través de dos llamadas `AssumeRole`.

## Opción 1: creación de un proveedor de identidades a partir del clúster de otra cuenta
<a name="_option_1_create_an_identity_provider_from_another_accounts_cluster"></a>

En este ejemplo, la Cuenta A proporciona a la Cuenta B la URL del emisor de OpenID Connect (OIDC) desde su clúster. La cuenta B sigue las instrucciones que se encuentran en [Creación de un proveedor de OIDC de IAM para su clúster](enable-iam-roles-for-service-accounts.md) y [Asignación de roles de IAM a cuentas de servicio de Kubernetes](associate-service-account-role.md) mediante la URL del emisor de OIDC del clúster de la cuenta A. A continuación, un administrador del clúster anota la cuenta de servicio en el clúster de la cuenta A para utilizar el rol de la cuenta B (*444455556666*).

```
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::444455556666:role/account-b-role
```

## Opción 2: uso de operaciones `AssumeRole` encadenadas
<a name="_option_2_use_chained_assumerole_operations"></a>

En este enfoque, cada cuenta crea un rol de IAM. El rol de la cuenta B confía en la cuenta A y el rol de la cuenta A usa la federación OIDC para obtener las credenciales del clúster. A continuación, el pod encadena los dos roles mediante perfiles de AWS CLI.

### Paso 1: crear un rol objetivo en la cuenta B
<a name="_step_1_create_the_target_role_in_account_b"></a>

La cuenta B (*444455556666*) crea un rol de IAM con los permisos que necesitan los pods del clúster de la cuenta A. La cuenta B adjunta la política de permisos deseada a este rol y, a continuación, agrega la siguiente política de confianza.

 **Política de confianza para el rol de la cuenta B**: esta política permite que el rol IRSA específico de la cuenta A asuma este rol.

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}
```

**importante**  
Para obtener los privilegios mínimos, sustituya el ARN de `Principal` por el ARN del rol específico de la cuenta A en lugar de usar la raíz de la cuenta (`arn:aws:iam::111122223333:root`). El uso de la raíz de la cuenta permite que *cualquier* entidad principal de IAM de la cuenta A asuma este rol.

### Paso 2: crear un rol de IRSA en la cuenta A
<a name="_step_2_create_the_irsa_role_in_account_a"></a>

La cuenta A (*111122223333*) crea un rol con una política de confianza que obtiene las credenciales del proveedor de identidades creado con la dirección del emisor OIDC del clúster.

 **Política de confianza para el rol de la cuenta A (federación de OIDC)**: esta política permite al proveedor de OIDC del clúster de EKS emitir credenciales para este rol.

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}
```

**importante**  
Para obtener el privilegio mínimo, agregue una condición `StringEquals` a la notificación de `sub` para restringir este rol a una cuenta de servicio de Kubernetes específica. Sin ninguna condición `sub`, cualquier cuenta de servicio del clúster puede asumir este rol. El valor `sub` usa el formato `system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME `. Por ejemplo, para restringirlo a una cuenta de servicio denominada `my-service-account` en el espacio de nombres `default`:  

```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account"
```

### Paso 3: adjuntar el permiso de AssumeRole al rol de la cuenta A.
<a name="_step_3_attach_the_assumerole_permission_to_account_as_role"></a>

La cuenta A adjunta una política de permisos al rol creado en el paso 2. Esta política permite que el rol asuma el rol de la cuenta B.

 **Política de permisos para el rol de la cuenta A**: esta política otorga `sts:AssumeRole` en el rol objetivo de la cuenta B.

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::444455556666:role/account-b-role"
        }
    ]
}
```

### Paso 4: configurar el pod para encadenar roles
<a name="_step_4_configure_the_pod_to_chain_roles"></a>

El código de aplicación para que los pods asuman el rol de la cuenta B utiliza dos perfiles: `account_b_role` y `account_a_role`. El perfil `account_b_role` utiliza el perfil `account_a_role` como origen. Para la CLI de AWS, el archivo `~/.aws/config` es similar al siguiente.

```
[profile account_b_role]
source_profile = account_a_role
role_arn=arn:aws:iam::444455556666:role/account-b-role

[profile account_a_role]
web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token
role_arn=arn:aws:iam::111122223333:role/account-a-role
```

Para especificar perfiles encadenados para otros SDK de AWS, consulte la documentación del SDK que utiliza. Para obtener más información, consulte [herramientas para crear en AWS](https://aws.amazon.com/developer/tools/).

# Uso de IRSA con el SDK de AWS
<a name="iam-roles-for-service-accounts-minimum-sdk"></a>

**Uso de las credenciales**  
Para usar las credenciales de los roles de IAM para cuentas de servicio (IRSA), el código puede usar cualquier AWS SDK para crear un cliente para un servicio de AWS con un SDK y, de forma predeterminada, el SDK busca en una cadena de ubicaciones las credenciales de AWS Identity and Access Management para usar. Las credenciales de los roles de IAM para cuentas de servicio se utilizarán si no especifica un proveedor de credenciales al crear el cliente o al iniciar el SDK de otro modo.

Esto funciona porque los roles de IAM para cuentas de servicio se han agregado como un paso en la cadena de credenciales predeterminada. Si sus cargas de trabajo utilizan actualmente credenciales que se encuentran en una fase anterior de la cadena de credenciales, esas credenciales seguirán utilizándose aunque configure un rol de IAM para cuentas de servicio de la misma carga de trabajo.

El SDK intercambia automáticamente el token de OIDC de la cuenta de servicio por credenciales temporales de AWS Security Token Service mediante la acción `AssumeRoleWithWebIdentity`. Amazon EKS y esta acción de SDK siguen rotando las credenciales temporales y las renuevan antes de que caduquen.

Al usar [roles de IAM para cuentas de servicio](iam-roles-for-service-accounts.md), los contenedores de los pods deben usar una versión del AWS SDK que admita asumir un rol de IAM a través de un archivo de token de identidad web de OpenID Connect. Asegúrese de usar las siguientes versiones, o posteriores, para el SDK de AWS:
+ Java (Versión 2): [2.10.11](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.10.11) 
+ Java: [1.12.782](https://github.com/aws/aws-sdk-java/releases/tag/1.12.782) 
+  AWS SDK para Go v1: [1.23.13](https://github.com/aws/aws-sdk-go/releases/tag/v1.23.13) 
+  AWS SDK para Go v2: compatibilidad con todas las versiones
+ Python (Boto3): [1.9.220](https://github.com/boto/boto3/releases/tag/1.9.220) 
+ Python (botocore): [1.12.200](https://github.com/boto/botocore/releases/tag/1.12.200) 
+  AWS CLI: [1.16.232](https://github.com/aws/aws-cli/releases/tag/1.16.232) 
+ Nodo: [2.525.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.525.0) y [3.27.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.27.0) 
+ Ruby: [3.58.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#3580-2019-07-01) 
+ C\$1\$1: [1.7.174](https://github.com/aws/aws-sdk-cpp/releases/tag/1.7.174) 
+ .NET: [3.3.659.1](https://github.com/aws/aws-sdk-net/releases/tag/3.3.659.1): también debe incluir `AWSSDK.SecurityToken`.
+ PHP: [3.110.7](https://github.com/aws/aws-sdk-php/releases/tag/3.110.7) 

Muchos complementos populares de Kubernetes, como el [Escalador automático de clústeres](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), el [Enrutamiento de tráfico de Internet con el controlador del equilibrador de carga de AWS](aws-load-balancer-controller.md) y el [complemento CNI de Amazon VPC para Kubernetes](cni-iam-role.md) permiten utilizar roles de IAM para cuentas de servicio.

Para asegurarse de que esté utilizando un SDK compatible, siga las instrucciones de instalación para su SDK preferido en [Herramientas para crear en AWS](https://aws.amazon.com/tools/) al crear los contenedores.

## Consideraciones
<a name="_considerations"></a>

### Java
<a name="_java"></a>

Cuando se utiliza Java, se *debe* incluir el módulo `sts` en el classpath. Para obtener más información, consulte [WebIdentityTokenFileCredentialsProvider](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/WebIdentityTokenFileCredentialsProvider.html) en la documentación del SDK de Java.

# Obtención de las claves de firma para validar los tokens de OIDC
<a name="irsa-fetch-keys"></a>

Kubernetes emite un `ProjectedServiceAccountToken` para cada cuenta de servicio de Kubernetes. Este token es un token de OIDC, que, además, es un tipo de token web JSON (JWT). Amazon EKS aloja un punto de conexión de OIDC público por cada clúster que contiene las claves de firma para el token de modo que los sistemas externos pueden validarlo.

Para validar un `ProjectedServiceAccountToken`, necesita buscar las claves de firma pública de OIDC, también conocidas como JSON Web Key Set (JWKS). Utilice estas claves en su aplicación para validar el token. Por ejemplo, puede usar la [biblioteca Python PyJWT](https://pyjwt.readthedocs.io/en/latest/) para validar los tokens con estas claves. Para más información sobre `ProjectedServiceAccountToken`, consulte [Información general de IAM, Kubernetes y OpenID Connect (OIDC)](iam-roles-for-service-accounts.md#irsa-oidc-background).

## Requisitos previos
<a name="_prerequisites"></a>
+ Un proveedor existente de OpenID Connect (OIDC) de AWS Identity and Access Management (IAM) para su clúster. Para determinar si ya tiene un proveedor o para crear uno, consulte [Crear un proveedor de OIDC de IAM para su clúster](enable-iam-roles-for-service-accounts.md).
+  ** AWS CLI**: una herramienta de línea de comandos para trabajar con servicios de AWS, incluido Amazon EKS. Para obtener más información, consulte [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) en la Guía del usuario de AWS Command Line Interface. Después de instalar la AWS CLI, recomendamos que también la configure. Para obtener más información, consulte [Configuración rápida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) en la Guía del usuario de la interfaz de la línea de comandos de AWS.

## Procedimiento
<a name="_procedure"></a>

1. Recupere la URL de OIDC del clúster de Amazon EKS mediante la AWS CLI.

   ```
   $ aws eks describe-cluster --name my-cluster --query 'cluster.identity.oidc.issuer'
   "https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE"
   ```

1. Recupere la clave de firma pública con curl o una herramienta similar. El resultado es un [Conjunto de claves web JSON (JWKS)](https://www.rfc-editor.org/rfc/rfc7517#section-5).
**importante**  
Amazon EKS limita las llamadas al punto de conexión de OIDC. Debe almacenar en caché la clave de firma pública. Respete el encabezado `cache-control` incluido en la respuesta.
**importante**  
Amazon EKS rota la clave de firma de OIDC cada siete días.

   ```
   $ curl https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE/keys
   {"keys":[{"kty":"RSA","kid":"2284XXXX4a40","use":"sig","alg":"RS256","n":"wklbXXXXMVfQ","e":"AQAB"}]}
   ```