**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.
# Información sobre el funcionamiento del control de acceso en Amazon EKS
Obtenga información sobre cómo administrar el acceso a su clúster de Amazon EKS. El uso de Amazon EKS requiere saber cómo Kubernetes y AWS Identity and Access Management (AWS IAM) gestionan el control de acceso.
**Esta sección incluye:**
**[Concesión a los usuarios y roles de IAM de acceso a las API de Kubernetes](grant-k8s-access.md)**: obtenga información sobre cómo permitir que las aplicaciones o los usuarios se autentiquen en la API de Kubernetes. Puede usar entradas de acceso, el aws-auth ConfigMap o un proveedor de OIDC externo.
**[Visualización de los recursos de Kubernetes en la Consola de administración de AWS](view-kubernetes-resources.md)**: obtenga información sobre cómo configurar la Consola de administración de AWS para que se comunique con su clúster de Amazon EKS. Utilice la consola para ver los recursos de Kubernetes en el clúster, como espacios de nombres, nodos y pods.
**[Concesión a los servicios de AWS de acceso de escritura a las API de Kubernetes](mutate-kubernetes-resources.md)**: obtenga información sobre los permisos necesarios para modificar recursos de Kubernetes.
** [Conexión de kubectl a un clúster de EKS mediante la creación de un archivo kubeconfig](create-kubeconfig.md) ** — obtenga información sobre cómo configurar kubectl para que se comunique con su clúster de Amazon EKS. Use la CLI de AWS para crear un archivo kubeconfig.
**[Concesión de acceso a las cargas de trabajo de Kubernetes a AWS mediante las cuentas de servicio de Kubernetes](service-accounts.md)**: obtenga información sobre cómo asociar una cuenta de servicio de Kubernetes con roles de AWS IAM. Puede usar los roles de IAM o de Pod Identity para las cuentas de servicio (IRSA).
## Tareas comunes
+ Conceda a los desarrolladores acceso a la API de Kubernetes. Visualice los recursos de Kubernetes en la Consola de administración de AWS.
+ Solución: [utilice las entradas de acceso](access-entries.md) para asociar los permisos de RBAC de Kubernetes a los roles o usuarios de AWS IAM.
+ Configure kubectl para que se comunique con un clúster de Amazon EKS mediante credenciales de AWS.
+ Solución: utilice la CLI de AWS para [crear un archivo kubeconfig](create-kubeconfig.md).
+ Utilice un proveedor de identidad externo, como Ping Identity, para autenticar usuarios en la API de Kubernetes.
+ Solución: [vincule un proveedor de OIDC externo](authenticate-oidc-identity-provider.md).
+ Conceda a las cargas de trabajo de su clúster de Kubernetes la capacidad de llamar a las API de AWS.
+ Solución: [use Pod Identity](pod-identities.md) para asociar un rol de AWS IAM a una cuenta de servicio de Kubernetes.
## Introducción
+ [Obtenga información sobre cómo funcionan las cuentas de servicio de Kubernetes.](https://kubernetes.io/docs/concepts/security/service-accounts/)
+ [Revise el modelo de control de acceso basado en roles (RBAC) de Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
+ Para obtener más información sobre la gestión del acceso a los recursos de AWS, consulte la [Guía del usuario de AWS IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html). Como alternativa, haga una [formación introductoria gratuita sobre el uso de AWS IAM](https://explore.skillbuilder.aws/learn/course/external/view/elearning/120/introduction-to-aws-identity-and-access-management-iam).
## Consideraciones para el modo automático de EKS
El modo automático de EKS se integra con las entradas de acceso de EKS EKS y EKS Pod Identity.
+ El modo automático de EKS utiliza entradas de acceso para conceder permisos de Kubernetes al plano de control de EKS. Por ejemplo, las políticas de acceso permiten al modo automático de EKS leer información sobre puntos de conexión y servicios de red.
+ No puede desactivar las entradas de acceso en un clúster de modo automático de EKS.
+ Si lo desea, puede habilitar `aws-auth` `ConfigMap`.
+ Las entradas de acceso para el modo automático de EKS se configuran automáticamente. Puede ver estas entradas de acceso, pero no puede modificarlas.
+ Si utiliza una NodeClass para crear un rol de IAM de nodo personalizado, deberá crear una entrada de acceso para el rol mediante la política de acceso AmazonEKSAutoNodePolicy.
+ Si quiere conceder permisos de carga de trabajo para los servicios de AWS, utilice EKS Pod Identity.
+ No necesita instalar el agente de Pod Identity en los clusters de modo automático de EKS.
# Concesión a los usuarios y roles de IAM de acceso a las API de Kubernetes
Su clúster tiene un punto de conexión de la API de Kubernetes. Kubectl usa esta API. Puede autenticarse en esta API mediante dos tipos de identidades:
+ **Una *entidad principal* de AWS Identity and Access Management (IAM) (rol o usuario)**: este tipo requiere autenticación ante IAM. Los usuarios pueden iniciar sesión en AWS como un usuario de [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) o con una [identidad federada](https://aws.amazon.com/identity/federation/) mediante las credenciales proporcionadas a través de una fuente de identidad. Los usuarios solo pueden iniciar sesión con una identidad federada si su administrador previamente configuró la federación de identidades mediante los roles de IAM. Cuando los usuarios acceden a AWS mediante la federación, están [asumiendo un rol](https://docs.aws.amazon.com/IAM/latest/UserGuide/when-to-use-iam.html#security-iam-authentication-iamrole) de forma indirecta. Cuando los usuarios utilizan este tipo de identidad, puede hacer lo siguiente:
+ Puede asignarles permisos de Kubernetes para que puedan trabajar con los objetos de Kubernetes en su clúster. Para obtener más información sobre cómo asignar permisos a las entidades principales de IAM para que puedan acceder a los objetos de Kubernetes en su clúster, consulte [Concesión de acceso para los usuarios de IAM a las entradas de acceso de Kubernetes con EKS](access-entries.md).
+ Puede asignarles permisos de IAM para que puedan trabajar con su clúster de Amazon EKS y sus recursos mediante la API de Amazon EKS, AWS CLI, AWS CloudFormation, Consola de administración de AWS o `eksctl`. Para obtener más información, consulte [Acciones definidas por Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) en la Referencia de autorización de servicios.
+ Los nodos se unen al clúster asumiendo un rol de IAM. El acceso al clúster mediante las entidades principales de IAM está habilitado por el [Autenticador de IAM de AWS para Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme), que se ejecuta en el plano de control de Amazon EKS.
+ **Un usuario en su propio proveedor de OpenID Connect (OIDC):** este tipo requiere la autenticación de su proveedor de [OIDC](https://openid.net/connect/). Para obtener más información acerca de cómo configurar su propio proveedor de OIDC con su clúster de Amazon EKS, consulte [Concesión de acceso a Kubernetes con un proveedor de OIDC externo para los usuarios](authenticate-oidc-identity-provider.md). Cuando los usuarios utilizan este tipo de identidad, puede hacer lo siguiente:
+ Puede asignarles permisos de Kubernetes para que puedan trabajar con los objetos de Kubernetes en su clúster.
+ No puede asignarles permisos de IAM para que puedan trabajar con su clúster de Amazon EKS y sus recursos mediante la API de Amazon EKS, la AWS CLI, la AWS CloudFormation, la Consola de administración de AWS o el `eksctl`.
Puede utilizar ambos tipos de identidades con su clúster. El método de autenticación de IAM no se puede deshabilitar. El método de autenticación de OIDC es opcional.
## Asociación de las identidades de IAM con los permisos de Kubernetes
El [Autenticador de AWS IAM para Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme) se instala en el plano de control del clúster. Permite a las entidades principales de [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) (IAM) (roles y usuarios) acceder a los recursos de Kubernetes en su clúster. Puede permitir que las entidades principales de IAM accedan a los objetos de Kubernetes en su clúster mediante uno de los siguientes métodos:
+ **Creación de entradas de acceso**: si su clúster tiene la versión de la plataforma igual o posterior a la que se indica en la sección [Requisitos previos](access-entries.md) de la versión de Kubernetes del clúster, le recomendamos que utilice esta opción.
Utilice las *entradas de acceso* para administrar los permisos de Kubernetes de las entidades principales de IAM ajenos al clúster. Puede agregar y administrar el acceso al clúster mediante la API de EKS, la Interfaz de la línea de comandos de AWS, los SDK de AWS, AWS CloudFormation y la Consola de administración de AWS. Esto significa que puede administrar los usuarios con las mismas herramientas con las que creó el clúster.
Para comenzar, siga [Cambio del modo de autenticación para usar entradas de acceso](setting-up-access-entries.md) y, a continuación, [Migración de las entradas existentes de aws-auth ConfigMap a entradas de acceso](migrating-access-entries.md).
+ **Agregar entradas al `aws-auth` `ConfigMap` **: si la versión de la plataforma del clúster es anterior a la que aparece en la sección de [Requisitos previos](access-entries.md), debe utilizar esta opción. Si la versión de la plataforma de su clúster es igual o posterior a la versión de la plataforma que aparece en la sección [Requisitos previos](access-entries.md) de la versión de Kubernetes de su clúster y ha agregado entradas al `ConfigMap`, le recomendamos que migre esas entradas para acceder a las ellas. Sin embargo, no puede migrar las entradas que Amazon EKS haya agregado al `ConfigMap`, como las entradas para los roles de IAM utilizadas con los grupos de nodos administrados o los perfiles de Fargate. Para obtener más información, consulte [Concesión a los usuarios y roles de IAM de acceso a las API de Kubernetes](#grant-k8s-access).
+ Si tiene que usar la opción de `ConfigMap` de `aws-auth`, puede añadir entradas al `ConfigMap` mediante el comando `eksctl create iamidentitymapping`. Para obtener más información, consulte [Administrar usuarios y roles de IAM](https://eksctl.io/usage/iam-identity-mappings/) en la documentación de `eksctl`.
## Establecimiento de nodos de autenticación del clúster
Cada clúster tiene un *modo de autenticación*. El modo de autenticación determina los métodos que puede utilizar para permitir que las entidades principales de IAM accedan a los objetos de Kubernetes en su clúster. Existen tres modos de autenticación.
**importante**
Una vez que se habilita el método de entrada de acceso, no se puede deshabilitar.
Si el método `ConfigMap` no está habilitado durante la creación del clúster, no se podrá habilitar más adelante. Todos los clústeres creados antes de la introducción de las entradas de acceso tienen el método `ConfigMap` activado.
Si usa nodos híbridos con el clúster, debe usar los modos de autenticación de clúster `API` o `API_AND_CONFIG_MAP`.
**El `aws-auth` `ConfigMap` dentro del clúster**
Este es el modo de autenticación original de los clústeres de Amazon EKS. La entidad principal de IAM que creó el clúster es el usuario inicial que puede acceder al clúster con `kubectl`. El usuario inicial debe añadir otros usuarios a la lista en el `ConfigMap` de `aws-auth` y asignar los permisos que afecten a los demás usuarios del clúster. Estos otros usuarios no pueden administrar ni eliminar al usuario inicial, ya que no hay ninguna entrada en el `ConfigMap` que administrar.
**Tanto el `ConfigMap` como las entradas de acceso**
Con este modo de autenticación, puede utilizar ambos métodos para añadir las entidades principales de IAM al clúster. Tenga en cuenta que cada método almacena entradas independientes; por ejemplo, si agrega una entrada de acceso desde la AWSCLI, el `aws-auth` `ConfigMap` no se actualiza.
**Solo entradas de acceso**
Con este modo de autenticación, puede utilizar la API de EKS, la Interfaz de la línea de comandos de AWS, los SDK de AWS, AWS CloudFormation y la Consola de administración de AWS para administrar el acceso al clúster de las entidades principales de IAM.
Cada entrada de acceso tiene un *tipo* y puede utilizar la combinación de un *enlace de acceso* para limitar a la entidad principal a un espacio de nombres específico y una *política de acceso* para establecer políticas de permisos preconfiguradas y reutilizables. Como alternativa, puede usar el tipo STANDARD y los grupos de RBAC de Kubernetes para asignar permisos personalizados.
| Modo de autenticación | Métodos |
| --- | --- |
| Solo `ConfigMap` (`CONFIG_MAP`) | `aws-auth` `ConfigMap` |
| API de EKS y `ConfigMap` (`API_AND_CONFIG_MAP`) | entradas de acceso en la API de EKS, la Interfaz de línea de comandos de AWS, los SDK de AWS, AWS CloudFormation, la Consola de administración de AWS y `aws-auth` `ConfigMap` |
| Solo la API de EKS (`API`) | entradas de acceso en la API de EKS, la Interfaz de línea de comandos de AWS, los SDK de AWS, AWS CloudFormation y la Consola de administración de AWS |
**nota**
El modo automático de Amazon EKS requiere entradas de acceso.
# Concesión de acceso para los usuarios de IAM a las entradas de acceso de Kubernetes con EKS
Esta sección está diseñada para mostrarle cómo administrar el acceso de la entidad principal de IAM a los clústeres de Kubernetes en Amazon Elastic Kubernetes Service (EKS) utilizando entradas y políticas de acceso. Encontrará detalles sobre cómo cambiar los modos de autenticación, cómo migrar desde entradas de `aws-auth` ConfigMap heredadas, cómo crear, actualizar y eliminar entradas de acceso, cómo asociar políticas a entradas, cómo revisar los permisos de políticas predefinidas y los requisitos previos y las consideraciones clave para la administración segura del acceso.
## Descripción general
Las entradas de acceso de EKS son la mejor forma de conceder acceso a la API de Kubernetes a los usuarios. Por ejemplo, puede utilizar entradas de acceso para conceder a los desarrolladores acceso para utilizar kubectl. Básicamente, una entrada de acceso de EKS asocia un conjunto de permisos de Kubernetes a una identidad de IAM, como un rol de IAM. Por ejemplo, un desarrollador puede asumir un rol de IAM y utilizarlo para autenticarse en un clúster de EKS.
## Características
+ **Autenticación y autorización centralizadas**: controla el acceso a los clústeres de Kubernetes directamente a través de las API de Amazon EKS, lo que elimina la necesidad de cambiar entre las API de AWS y de Kubernetes para obtener permisos de usuario.
+ **Administración detallada de los permisos**: utiliza entradas y políticas de acceso para definir permisos detallados para las entidades principales de AWS IAM, incluida la capacidad de modificar o revocar los permisos de administrador del clúster a su creador.
+ **Integración con la herramienta de IaC**: admite infraestructura como herramientas de código, como AWS CloudFormation, Terraform y AWS CDK, lo que permite definir las configuraciones de acceso durante la creación del clúster.
+ **Recuperación de errores de configuración**: permite restaurar el acceso al clúster a través de la API de Amazon EKS sin acceso directo a la API de Kubernetes.
+ **Reducción de gastos y seguridad mejorada**: centraliza las operaciones para reducir los gastos al tiempo que aprovecha las características de AWS IAM, como el registro de auditorías de CloudTrail y la autenticación multifactor.
## Cómo adjuntar permisos
Puede asociar permisos de Kubernetes a entradas de acceso dos maneras:
+ Utilice una política de acceso. Las políticas de acceso son plantillas de permisos de Kubernetes predefinidas mantenidas por AWS. Para obtener más información, consulte [Revisión de los permisos de la política de acceso](access-policy-permissions.md).
+ Haga referencia a un grupo de Kubernetes. Si asocia una identidad de IAM a un grupo de Kubernetes, podrá crear recursos de Kubernetes que concedan permisos al grupo. Para obtener más información, consulte [Utilización de la autorización de RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) en la documentación de Kubernetes.
## Consideraciones
Al habilitar las entradas de acceso de EKS en los clústeres existentes, se debe tener en cuenta lo siguiente:
+ **Comportamiento de los clústeres heredados**: para los clústeres creados antes de la introducción de las entradas de acceso (aquellos con versiones de la plataforma iniciales anteriores a las especificadas en los [requisitos de versión de la plataforma](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html)), EKS crea automáticamente una entrada de acceso que refleja los permisos preexistentes. Esta entrada incluye la identidad de IAM que creó originalmente el clúster y los permisos administrativos otorgados a esa identidad durante la creación del clúster.
+ **Gestión del `aws-auth` ConfigMap heredado**: si su clúster se basa en el `aws-auth` ConfigMap heredado para la administración del acceso, solo se crea automáticamente la entrada de acceso del creador del clúster original al habilitar las entradas de acceso. Los roles o permisos adicionales agregados al ConfigMap (por ejemplo, roles de IAM personalizados para desarrolladores o servicios) no se migran automáticamente. Para solucionarlo, se deben crear manualmente las entradas de acceso correspondientes.
## Introducción
1. Determine la identidad de IAM y la política de acceso que desea utilizar.
+ [Revisión de los permisos de la política de acceso](access-policy-permissions.md)
1. Habilite las entradas de acceso de EKS en el clúster. Confirme que tiene una versión de la plataforma compatible.
+ [Cambio del modo de autenticación para utilizar las entradas de acceso](setting-up-access-entries.md)
1. Cree una entrada de acceso que asocie una identidad de IAM a un permiso de Kubernetes.
+ [Creación de entradas de acceso](creating-access-entries.md)
1. Autentíquese en el clúster mediante la identidad de IAM.
+ [Configurar AWS CLI](install-awscli.md)
+ [Configuración de `kubectl` y `eksctl`](install-kubectl.md)
# Asociación de políticas de acceso a entradas de acceso
Puede asignar una o más políticas de acceso a las *entradas de acceso* del *tipo* `STANDARD`. Amazon EKS concede automáticamente a los demás tipos de entradas de acceso los permisos necesarios para funcionar correctamente en el clúster. Las políticas de acceso de Amazon EKS incluyen permisos de Kubernetes, no permisos de IAM. Antes de asociar una política de acceso a una entrada de acceso, asegúrese de haberse familiarizado con los permisos de Kubernetes incluidos en cada política de acceso. Para obtener más información, consulte [Revisión de los permisos de la política de acceso](access-policy-permissions.md). Si ninguna de las políticas de acceso cumple con sus requisitos, no asocie una política de acceso a una entrada de acceso. En su lugar, especifique uno o más *nombres de grupo* para la entrada de acceso, y cree y administre objetos de control de acceso basados en roles de Kubernetes. Para obtener más información, consulte [Creación de entradas de acceso](creating-access-entries.md).
+ Una entrada de acceso existente. Para crear uno, consulte [Creación de entradas de acceso](creating-access-entries.md).
+ Un rol o usuario de AWS Identity and Access Management con los siguientes permisos: `ListAccessEntries`, `DescribeAccessEntry`, `UpdateAccessEntry`, `ListAccessPolicies`, `AssociateAccessPolicy` y `DisassociateAccessPolicy`. Para obtener más información, consulte [Acciones definidas por Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) en la *Referencia de autorizaciones del servicio*.
Antes de asociar políticas de acceso con entradas de acceso, tenga en cuenta los siguientes requisitos:
+ Puede asociar varias políticas de acceso a cada entrada de acceso, pero solo puede asociar cada política a una entrada de acceso una vez. Si asocia varias políticas de acceso, la entidad principal de IAM de la entrada de acceso tendrá todos los permisos incluidos en todas las políticas de acceso asociadas.
+ Puede limitar una política de acceso a todos los recursos de un clúster o especificar el nombre de uno o más espacios de nombres de Kubernetes. Puede utilizar caracteres comodín para el nombre de un espacio de nombres. Por ejemplo, si desea limitar una política de acceso a todos los espacios de nombres que comiencen con `dev-`, puede especificar `dev-*` como nombre de un espacio de nombres. Asegúrese de que los espacios de nombres existan en su clúster y de que la ortografía coincida con el nombre real del espacio de nombres del clúster. Amazon EKS no confirma la ortografía ni la existencia de los espacios de nombres del clúster.
+ Puede cambiar el *alcance del acceso* de una política de acceso después de asociarla a una entrada de acceso. Si limitó la política de acceso a los espacios de nombres de Kubernetes, puede agregar y eliminar espacios de nombres para la asociación, según sea necesario.
+ Si asocia una política de acceso a una entrada de acceso que también tenga *nombres de grupo* especificados, la entidad principal de IAM tendrá todos los permisos en todas las políticas de acceso asociadas. También tiene todos los permisos en cualquier objeto `Role` o `ClusterRole` de Kubernetes que se especifique en cualquier objeto `Role` y `RoleBinding` de Kubernetes que especifican los nombres de grupo.
+ Si ejecuta el comando `kubectl auth can-i --list`, no verá ningún permiso de Kubernetes asignado por las políticas de acceso asociadas a una entrada de acceso para la entidad principal de IAM que esté utilizando cuando ejecute el comando. El comando solo muestra los permisos de Kubernetes si los concedió en los objetos `Role` o `ClusterRole` de Kubernetes que vinculó a los nombres de grupo o al nombre de usuario que especificó para una entrada de acceso.
+ Si se hace pasar por un usuario o un grupo de Kubernetes al interactuar con los objetos de Kubernetes del clúster, por ejemplo, al utilizar el comando `kubectl` con `--as username ` o `--as-group group-name `, forzará el uso de una autorización RBAC de Kubernetes. Como resultado, la entidad principal de IAM no tiene permisos asignados por ninguna política de acceso asociada a la entrada de acceso. Los únicos permisos de Kubernetes que tiene el usuario o grupo al que está suplantando la entidad principal de IAM son los permisos de Kubernetes que concedió en los objetos `Role` o `ClusterRole` de Kubernetes, los cuales vinculó a los nombres de grupo o al nombre de usuario. Para que su entidad principal de IAM tenga los permisos de las políticas de acceso asociadas, no suplante un usuario o un grupo de Kubernetes. La entidad principal de IAM también seguirá teniendo todos los permisos que le haya concedido en los objetos `Role` o `ClusterRole` de Kubernetes que usted haya vinculado con los nombres de grupo o el nombre de usuario que especificó para la entrada de acceso. Para obtener más información, consulte [User impersonation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) en la documentación de Kubernetes.
Puede asociar una política de acceso a una entrada de acceso mediante la Consola de administración de AWS o la AWS CLI.
## Consola de administración de AWS
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Elija el nombre del clúster que tenga una entrada de acceso a la que desea asociar una política de acceso.
1. Elija la pestaña **Acceso**.
1. Si el tipo de entrada de acceso es **Estándar**, puede asociar o desasociar **las políticas de acceso** de Amazon EKS. Si el tipo de entrada de acceso no es **Estándar**, entonces esta opción no está disponible.
1. Elija **Asociar política de acceso**.
1. En **Nombre de la política**, seleccione la política con los permisos que desea que tenga la entidad principal de IAM. Para ver los permisos incluidos en cada política, consulte [Revisión de los permisos de la política de acceso](access-policy-permissions.md).
1. En **Alcance del acceso**, elija un alcance del acceso. Si elige **Clúster**, los permisos de la política de acceso se otorgan a la entidad principal de IAM para los recursos de todos los espacios de nombres de Kubernetes. Si elige **espacio de nombres de Kubernetes**, luego puede elegir **Agregar nuevo espacio de nombres**. En el campo **Espacio de nombres** que aparece, puede ingresar el nombre de un espacio de nombres de Kubernetes en el clúster. Si quiere que la entidad principal de IAM tenga los permisos en varios espacios de nombres, puede introducir varios espacios de nombres.
1. Seleccione **Añadir política de acceso**.
## AWS CLI
1. 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*.
1. Ver las políticas de acceso disponibles.
```
aws eks list-access-policies --output table
```
Un ejemplo de salida sería el siguiente.
```
---------------------------------------------------------------------------------------------------------
| ListAccessPolicies |
+-------------------------------------------------------------------------------------------------------+
|| accessPolicies ||
|+---------------------------------------------------------------------+-------------------------------+|
|| arn | name ||
|+---------------------------------------------------------------------+-------------------------------+|
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSAdminPolicy | AmazonEKSAdminPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy | AmazonEKSClusterAdminPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSEditPolicy | AmazonEKSEditPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSViewPolicy | AmazonEKSViewPolicy ||
|+---------------------------------------------------------------------+-------------------------------+|
```
Para ver los permisos incluidos en cada política, consulte [Revisión de los permisos de la política de acceso](access-policy-permissions.md).
1. Ver las entradas de acceso existentes. Reemplace *my-cluster* por el nombre de su clúster.
```
aws eks list-access-entries --cluster-name my-cluster
```
Un ejemplo de salida sería el siguiente.
```
{
"accessEntries": [
"arn:aws:iam::111122223333:role/my-role",
"arn:aws:iam::111122223333:user/my-user"
]
}
```
1. Asocie una política de acceso a una entrada de acceso. El siguiente ejemplo asocia la política de acceso de `AmazonEKSViewPolicy` a una entrada de acceso. Siempre que el rol de IAM *my-role* intente acceder a los objetos de Kubernetes del clúster, Amazon EKS autorizará al rol a usar los permisos en la política para acceder únicamente a los objetos de Kubernetes en los espacios de nombres *my-namespace1* y *my-namespace2* de Kubernetes. Reemplace *my-cluster* por el nombre de su clúster, *111122223333* por el ID de su cuenta de AWS y *my-role* por el nombre del rol de IAM para el que desea que Amazon EKS autorice el acceso a los objetos del clúster de Kubernetes.
```
aws eks associate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role \
--access-scope type=namespace,namespaces=my-namespace1,my-namespace2 --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy
```
Si desea que la entidad principal de IAM tenga los permisos en todo el clúster, reemplace `type=namespace,namespaces=my-namespace1,my-namespace2 ` con `type=cluster`. Si desea asociar varias políticas de acceso a la entrada de acceso, ejecute el comando varias veces, cada una con una política de acceso única. Cada política de acceso asociada tiene su propio alcance.
**nota**
Si más adelante desea cambiar el alcance de una política de acceso asociada, vuelva a ejecutar el comando anterior con el nuevo alcance. Por ejemplo, si quisiera eliminar *my-namespace2*, debería volver a ejecutar el comando usando solamente `type=namespace,namespaces=my-namespace1 `. Si quisiera cambiar el alcance de `namespace` a `cluster`, debería volver a ejecutar el comando usando `type=cluster` y eliminar `type=namespace,namespaces=my-namespace1,my-namespace2 `.
1. Determine qué políticas de acceso están asociadas a una entrada de acceso.
```
aws eks list-associated-access-policies --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role
```
Un ejemplo de salida sería el siguiente.
```
{
"clusterName": "my-cluster",
"principalArn": "arn:aws:iam::111122223333",
"associatedAccessPolicies": [
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
"accessScope": {
"type": "cluster",
"namespaces": []
},
"associatedAt": "2023-04-17T15:25:21.675000-04:00",
"modifiedAt": "2023-04-17T15:25:21.675000-04:00"
},
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy",
"accessScope": {
"type": "namespace",
"namespaces": [
"my-namespace1",
"my-namespace2"
]
},
"associatedAt": "2023-04-17T15:02:06.511000-04:00",
"modifiedAt": "2023-04-17T15:02:06.511000-04:00"
}
]
}
```
En el ejemplo anterior, la entidad principal de IAM para esta entrada de acceso tiene permisos de visualización en todos los espacios de nombres del clúster y permisos de administrador en dos espacios de nombres de Kubernetes.
1. Desasocie una política de acceso de una entrada de acceso. En este ejemplo, la política de `AmazonEKSAdminPolicy` está disociada de una entrada de acceso. Sin embargo, la entidad principal de IAM conserva los permisos de la política de acceso de `AmazonEKSViewPolicy` para los objetos en los espacios de nombres *my-namespace1* y *my-namespace2*, ya que esa política de acceso no está disociada de la entrada de acceso.
```
aws eks disassociate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy
```
Para ver una lista de las políticas de acceso disponibles, consulte [Revisión de los permisos de la política de acceso](access-policy-permissions.md).
# Migración de las entradas existentes de `aws-auth ConfigMap` a entradas de acceso
Si ha agregado entradas al `ConfigMap` de `aws-auth` en su clúster, le recomendamos que cree entradas de acceso para las entradas existentes en su `ConfigMap` de `aws-auth`. Después de crear las entradas de acceso, puede eliminarlas de su `ConfigMap`. No puede asociar [políticas de acceso](access-policies.md) a las entradas del `ConfigMap` de `aws-auth`. Si desea asociar políticas de acceso a sus entidades principales de IAM, cree entradas de acceso.
**importante**
Cuando un clúster está en modo de autenticación de `API_AND_CONFIGMAP` y hay una asignación para el mismo rol de IAM tanto en `aws-auth` `ConfigMap` como en las entradas de acceso, el rol utilizará la asignación de la entrada de acceso para la autenticación. Las entradas de acceso tienen prioridad sobre las entradas de `ConfigMap` de la misma entidad principal de IAM.
Antes de eliminar las entradas `aws-auth` `ConfigMap` existentes que Amazon EKS creó para un [grupo de nodos administrado](managed-node-groups.md) o un [perfil de Fargate](fargate-profile.md) en su clúster, verifique si las entradas de acceso correctas para esos recursos específicos existen en su clúster de Amazon EKS. Si elimina las entradas que Amazon EKS creó en el `ConfigMap` sin tener las entradas de acceso equivalentes, el clúster no funcionará correctamente.
## Requisitos previos
+ Familiaridad con las entradas de acceso y las políticas de acceso. Para obtener más información, consulte [Concesión de acceso para los usuarios de IAM a las entradas de acceso de Kubernetes con EKS](access-entries.md) y [Asociación de políticas de acceso a entradas de acceso](access-policies.md).
+ Un clúster existente con una versión de la plataforma que es igual o posterior a las versiones enumeradas en los requisitos previos del tema [Concesión de acceso para los usuarios de IAM a las entradas de acceso de Kubernetes con EKS](access-entries.md).
+ 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`.
+ Permisos de Kubernetes para modificar el `ConfigMap` `aws-auth` en el espacio de nombres `kube-system`.
+ Un rol o usuario de AWS Identity and Access Management con los siguientes permisos: `CreateAccessEntry` y `ListAccessEntries`. Para obtener más información, consulte [Acciones definidas por Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) en la Referencia de autorizaciones del servicio.
## `eksctl`
1. Visualización de las entradas existentes en su `aws-auth ConfigMap`. Reemplace *my-cluster* por el nombre de su clúster.
```
eksctl get iamidentitymapping --cluster my-cluster
```
Un ejemplo de salida sería el siguiente.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws:iam::111122223333:role/EKS-my-cluster-Admins Admins system:masters
arn:aws:iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers my-namespace-Viewers Viewers
arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws:iam::111122223333:user/my-user my-user
arn:aws:iam::111122223333:role/EKS-my-cluster-fargateprofile1 system:node:{{SessionName}} system:bootstrappers,system:nodes,system:node-proxier
arn:aws:iam::111122223333:role/EKS-my-cluster-managed-ng system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
```
1. [Creación de entradas de acceso](creating-access-entries.md) para cualquiera de las entradas del `ConfigMap` que haya creado y que se mostraron en el resultado anterior. Al crear las entradas de acceso, asegúrese de especificar los mismos valores para `ARN`, `USERNAME`, `GROUPS` y `ACCOUNT` que aparecen en el resultado. En el resultado de ejemplo, crearía entradas de acceso para todas las entradas, excepto las dos últimas, ya que Amazon EKS creó esas entradas para un perfil de Fargate y un grupo de nodos administrados.
1. Elimine las entradas del `ConfigMap` para cualquier entrada de acceso que haya creado. Si no elimina la entrada del `ConfigMap`, la configuración de la entrada de acceso para el ARN de entidad principal de IAM anula la entrada del `ConfigMap`. Reemplace *111122223333* por el ID de su cuenta de AWS y *EKS-my-cluster-my-namespace-Viewers* por el nombre del rol en la entrada de su `ConfigMap`. Si la entrada que va a eliminar es para un usuario de IAM y no para un rol de IAM, reemplace el `role` por el `user` y *EKS-my-cluster-my-namespace-Viewers* por el nombre de usuario.
```
eksctl delete iamidentitymapping --arn arn:aws:iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers --cluster my-cluster
```
# Revisión de los permisos de la política de acceso
Las políticas de acceso incluyen `rules` que contienen `verbs` (permisos) y `resources` de Kubernetes. Las políticas de acceso no incluyen los permisos ni los recursos de IAM. Al igual que los objetos `Role` y `ClusterRole` de Kubernetes, las políticas de acceso solo incluyen `rules` `allow`. No puede modificar el contenido de una política de acceso. No puede crear sus propias políticas de acceso. Si los permisos de las políticas de acceso no satisfacen sus necesidades, cree objetos RBAC de Kubernetes y especifique los *nombres de grupo* para las entradas de acceso. Para obtener más información, consulte [Creación de entradas de acceso](creating-access-entries.md). Los permisos contenidos en las políticas de acceso son similares a los permisos de los roles del clúster orientados a los usuarios de Kubernetes. Para obtener más información, consulte [User-facing roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) en la documentación de Kubernetes.
## Enumeración de todas las políticas
Utilice cualquiera de las políticas de acceso que se enumeran en esta página o recupere una lista de todas las políticas de acceso disponibles mediante la CLI de AWS:
```
aws eks list-access-policies
```
El resultado esperado debería ser similar al siguiente (abreviado para mayor brevedad):
```
{
"accessPolicies": [
{
"name": "AmazonAIOpsAssistantPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonAIOpsAssistantPolicy"
},
{
"name": "AmazonARCRegionSwitchScalingPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonARCRegionSwitchScalingPolicy"
},
{
"name": "AmazonEKSAdminPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy"
},
{
"name": "AmazonEKSAdminViewPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy"
},
{
"name": "AmazonEKSAutoNodePolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy"
}
// Additional policies omitted
]
}
```
## AmazonEKSAdminPolicy
Esta política de acceso incluye permisos que otorgan a una entidad principal de IAM la mayoría de los permisos a los recursos. Cuando se asocia a una entrada de acceso, su alcance de acceso suele ser uno o más espacios de nombres de Kubernetes. Si desea que una entidad principal de IAM tenga acceso de administrador a todos los recursos de su clúster, asocie la política de acceso de [AmazonEKSClusterAdminPolicy](#access-policy-permissions-amazoneksclusteradminpolicy) a su entrada de acceso.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy`
| Grupos de API de Kubernetes | Recursos de Kubernetes | Verbos de Kubernetes (permisos) |
| --- | --- | --- |
| `apps` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `replicasets`, `replicasets/scale`, `statefulsets`, `statefulsets/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `authorization.k8s.io` | `localsubjectaccessreviews` | `create` |
| `autoscaling` | `horizontalpodautoscalers` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `batch` | `cronjobs`, `jobs` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `ingresses`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicationcontrollers/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `networkpolicies` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| `rbac.authorization.k8s.io` | `rolebindings`, `roles` | `create`, `delete`, `deletecollection`, `get`, `list`, `patch`, `update`, `watch` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`,`list`, `watch` |
| | `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy`, `secrets`, `services/proxy` | `get`, `list`, `watch` |
| | `configmaps`, `events`, `persistentvolumeclaims`, `replicationcontrollers`, `replicationcontrollers/scale`, `secrets`, `serviceaccounts`, `services`, `services/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `pods`, `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `serviceaccounts` | `impersonate` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, `resourcequotas/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`,`list`, `watch` |
## AmazonEKSClusterAdminPolicy
Esta política de acceso incluye permisos que permiten a un administrador de la entidad principal de IAM acceder a un clúster. Cuando se asocia a una entrada de acceso, su alcance de acceso suele ser el clúster, en lugar de un espacio de nombres de Kubernetes. Si desea que una entidad principal de IAM tenga un alcance administrativo más limitado, considere la posibilidad de asociar la política de acceso de [AmazonEKSAdminPolicy](#access-policy-permissions-amazoneksadminpolicy) a su entrada de acceso.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy`
| Grupos de API de Kubernetes | nonResourceURLs de Kubernetes | Recursos de Kubernetes | Verbos de Kubernetes (permisos) |
| --- | --- | --- | --- |
| `*` | | `*` | `*` |
| | `*` | | `*` |
## AmazonEKSAdminViewPolicy
Esta política de acceso incluye permisos que permiten a una entidad principal de IAM acceder para enumerar/visualizar todos los recursos en un clúster. Tenga en cuenta que esto incluye [Kubernetes Secrets.](https://kubernetes.io/docs/concepts/configuration/secret/)
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy`
| Grupos de API de Kubernetes | Recursos de Kubernetes | Verbos de Kubernetes (permisos) |
| --- | --- | --- |
| `*` | `*` | `get`, `list`, `watch` |
## AmazonEKSEditPolicy
Esta política de acceso incluye permisos que permiten a una entidad principal de IAM editar la mayoría de los recursos de Kubernetes.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy`
| Grupos de API de Kubernetes | Recursos de Kubernetes | Verbos de Kubernetes (permisos) |
| --- | --- | --- |
| `apps` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `replicasets`, `replicasets/scale`, `statefulsets`, `statefulsets/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `jobs` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `ingresses`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicationcontrollers/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `networkpolicies` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `policy` | `poddisruptionbudgets` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`, `list`, `watch` |
| | `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy`, `secrets`, `services/proxy` | `get`, `list`, `watch` |
| | `serviceaccounts` | `impersonate` |
| | `pods`, `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `configmaps`, `events`, `persistentvolumeclaims`, `replicationcontrollers`, `replicationcontrollers/scale`, `secrets`, `serviceaccounts`, `services`, `services/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`, `list`, `watch` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, `resourcequotas/status` | `get`, `list`, `watch` |
## AmazonEKSViewPolicy
Esta política de acceso incluye permisos que permiten a una entidad principal de IAM ver la mayoría de los recursos de Kubernetes.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy`
| Grupos de API de Kubernetes | Recursos de Kubernetes | Verbos de Kubernetes (permisos) |
| --- | --- | --- |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`, `list`, `watch` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, r`esourcequotas/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`, `list`, `watch` |
## AmazonEKSSecretReaderPolicy
Esta política de acceso incluye permisos que permiten a una entidad principal de IAM leer [secretos de Kubernetes.](https://kubernetes.io/docs/concepts/configuration/secret/)
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy`
| Grupos de API de Kubernetes | Recursos de Kubernetes | Verbos de Kubernetes (permisos) |
| --- | --- | --- |
| | `secrets` | `get`, `list`, `watch` |
## AmazonEKSAutoNodePolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy`
Esta política incluye los siguientes permisos que permiten a los componentes de Amazon EKS realizar las siguientes tareas:
+ `kube-proxy`: supervise los puntos de conexión y los servicios de red, y administre los eventos relacionados. Esto habilita la funcionalidad de proxy de red a nivel de clúster.
+ `ipamd`: administre los recursos de red de AWS VPC y las interfaces de red de contenedores (CNI). Esto permite al daemon de administración de direcciones IP manejar la red de pods.
+ `coredns`: acceda a recursos de detección de servicios, como puntos de conexión y servicios. Esto habilita la funcionalidad de proxy de red a nivel de clúster.
+ `ebs-csi-driver`: trabaje con recursos relacionados con el almacenamiento para los volúmenes de Amazon EBS. Esto permite el aprovisionamiento dinámico y la conexión de volúmenes persistentes.
+ `neuron`: supervise los nodos y los pods de los dispositivos de AWS Neuron. Esto permite administrar los aceleradores de AWS Inferentia y Trainium.
+ `node-monitoring-agent`: acceda a los diagnósticos y eventos de los nodos. Esto permite la supervisión del estado del clúster y la recopilación de diagnósticos.
Cada componente utiliza una cuenta de servicio dedicada y está restringido únicamente a los permisos necesarios para su función específica.
Si especifica manualmente un rol de IAM de nodo en una NodeClass, tiene que crear una entrada de acceso que asocie el nuevo rol de IAM de nodo a esta política de acceso.
## AmazonEKSBlockStoragePolicy
**nota**
Esta política está destinada exclusivamente a los roles vinculados a servicios de AWS y no se puede utilizar con roles administrados por el cliente.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSBlockStoragePolicy`
Esta política incluye permisos que permiten a Amazon EKS administrar la elección de líderes y los recursos de coordinación para las operaciones de almacenamiento:
+ `coordination.k8s.io`: cree y administre objetos de arrendamiento para la elección del líder. Esto permite a los componentes de almacenamiento de EKS coordinar sus actividades en todo el clúster mediante un mecanismo de elección de líderes.
La política está limitada a recursos específicos de arrendamiento utilizados por los componentes de almacenamiento de EKS para evitar accesos conflictivos a otros recursos de coordinación en el clúster.
Amazon EKS crea automáticamente una entrada de acceso con esta política de acceso para el rol de IAM del clúster cuando el modo automático está habilitado, garantizando que los permisos necesarios estén configurados correctamente para que la capacidad de almacenamiento en bloques funcione adecuadamente.
## AmazonEKSLoadBalancingPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSLoadBalancingPolicy`
Esta política incluye permisos que permiten a Amazon EKS administrar recursos de elección de líderes para el equilibrio de carga:
+ `coordination.k8s.io`: cree y administre objetos de arrendamiento para la elección del líder. Esto permite a los componentes de equilibrio de carga de EKS coordinar las actividades entre varias réplicas mediante la elección de un líder.
El alcance de la política se aplica específicamente a los recursos de arrendamiento de equilibrio de carga para garantizar una coordinación adecuada y, al mismo tiempo, impedir el acceso a otros recursos de arrendamiento en el clúster.
Amazon EKS crea automáticamente una entrada de acceso con esta política de acceso para el rol de IAM del clúster cuando se habilita el modo automático, lo que garantiza que se disponga de los permisos necesarios para que la capacidad de red funcione correctamente.
## AmazonEKSNetworkingPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSNetworkingPolicy`
Esta política incluye permisos que permiten a Amazon EKS administrar recursos de elección de líderes para las redes:
+ `coordination.k8s.io`: cree y administre objetos de arrendamiento para la elección del líder. Esto permite a los componentes de red de EKS coordinar las actividades de asignación de direcciones IP mediante la elección de un líder.
El alcance de la política se aplica específicamente a los recursos de arrendamiento de red para garantizar una coordinación adecuada y, al mismo tiempo, impedir el acceso a otros recursos de arrendamiento del clúster.
Amazon EKS crea automáticamente una entrada de acceso con esta política de acceso para el rol de IAM del clúster cuando se habilita el modo automático, lo que garantiza que se disponga de los permisos necesarios para que la capacidad de red funcione correctamente.
## AmazonEKSComputePolicy
**nota**
Esta política está destinada exclusivamente a los roles vinculados a servicios de AWS y no se puede utilizar con roles administrados por el cliente.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSComputePolicy`
Esta política incluye permisos que permiten a Amazon EKS administrar recursos de elección de líderes para operaciones de computación:
+ `coordination.k8s.io`: cree y administre objetos de arrendamiento para la elección del líder. Esto permite a los componentes de computación de EKS coordinar las actividades de escalado de nodos mediante la elección de un líder.
El alcance de la política se aplica específicamente a los recursos de arrendamiento de administración de computación, al tiempo que se permite el acceso de lectura básico (`get`,`watch`) a todos los recursos de arrendamiento del clúster.
Amazon EKS crea automáticamente una entrada de acceso con esta política de acceso para el rol de IAM del clúster cuando se habilita el modo automático, lo que garantiza que se disponga de los permisos necesarios para que la capacidad de red funcione correctamente.
## AmazonEKSBlockStorageClusterPolicy
**nota**
Esta política está destinada exclusivamente a los roles vinculados a servicios de AWS y no se puede utilizar con roles administrados por el cliente.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSBlockStorageClusterPolicy`
Esta política concede los permisos necesarios para la capacidad de almacenamiento en bloque del modo automático de Amazon EKS. Permite una administración eficaz de los recursos de almacenamiento en bloque dentro de los clústeres de Amazon EKS. La política incluye los siguientes permisos:
Administración de controladores de CSI:
+ Cree, lea, actualice y elimine controladores CSI, específicamente para el almacenamiento en bloques.
Administración de los volúmenes:
+ Enumerar, vigilar, crear, actualizar, aplicar parches y eliminar volúmenes persistentes.
+ Enumerar, vigilar y actualizar las reclamaciones de volumen persistentes.
+ Aplique parches a los estados de reclamación de volúmenes persistentes.
Interacción entre nodos y pods:
+ Lea la información sobre nodos y pods.
+ Administre los eventos relacionados con las operaciones de almacenamiento.
Clases y atributos de almacenamiento:
+ Lea las clases de almacenamiento y los nodos CSI.
+ Lea las clases de atributos de volumen.
Conexiones de volúmenes:
+ Enumerar, vigilar y modificar las conexiones de volúmenes y sus estados.
Operaciones de instantáneas:
+ Administre las instantáneas de volúmenes, el contenido de las instantáneas y las clases de instantáneas.
+ Gestione operaciones para instantáneas de grupos de volúmenes y recursos relacionados.
Esta política está diseñada para admitir la administración integral del almacenamiento en bloques dentro de los clústeres de Amazon EKS que se ejecutan en modo automático. Combina permisos para diversas operaciones, como el aprovisionamiento, la conexión, el cambio de tamaño y la creación de instantáneas de volúmenes de almacenamiento en bloque.
Amazon EKS crea automáticamente una entrada de acceso con esta política de acceso para el rol de IAM del clúster cuando el modo automático está habilitado, garantizando que los permisos necesarios estén configurados correctamente para que la capacidad de almacenamiento en bloques funcione adecuadamente.
## AmazonEKSComputeClusterPolicy
**nota**
Esta política está destinada exclusivamente a los roles vinculados a servicios de AWS y no se puede utilizar con roles administrados por el cliente.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSComputeClusterPolicy`
Esta política concede los permisos necesarios para la capacidad de administración de computación del modo automático de Amazon EKS. Permite orquestar y escalar eficazmente los recursos de computación dentro de los clústeres de Amazon EKS. La política incluye los siguientes permisos:
Administración de nodos:
+ Cree, lea, actualice, elimine y administre el estado de NodePools y NodeClaims.
+ Administre NodeClasses, lo que incluye la creación, modificación y eliminación.
Programación y administración de recursos:
+ Acceso de lectura a pods, nodos, volúmenes persistentes, reclamaciones de volúmenes persistentes, controladores de replicación y espacios de nombres.
+ Acceso de lectura a clases de almacenamiento, nodos de CSI y conexiones de volúmenes.
+ Enumere y observe implementaciones, conjuntos de daemon, conjuntos de réplicas y conjuntos con estado.
+ Lea los presupuestos de disrupción de pods.
Control de eventos:
+ Cree, lea y administre los eventos de clústeres.
Desaprovisionamiento de nodos y expulsión de nodos:
+ Actualice, aplique parches y elimine nodos.
+ Cree expulsiones de pods y elimínelos cuando sea necesario.
Administración de definiciones personalizadas de recursos (CRD):
+ Creación de nuevas CRD.
+ Administre CRD específicas relacionadas con la administración de nodos (NodeClasses, NodePools, NodeClaims y NodeDiagnostics).
Esta política se ha diseñado para admitir una administración de computación completa en los clústeres de Amazon EKS que se ejecutan en modo automático. Combina permisos para diversas operaciones, como el aprovisionamiento de nodos, la programación, el escalado y la optimización de recursos.
Amazon EKS crea automáticamente una entrada de acceso con esta política de acceso para el rol de IAM del clúster cuando se habilita el modo automático, lo que garantiza que se disponga de los permisos necesarios para que la capacidad de administración de computación funcione correctamente.
## AmazonEKSLoadBalancingClusterPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSLoadBalancingClusterPolicy`
Esta política concede los permisos necesarios para la capacidad de equilibrio de carga del modo automático de Amazon EKS. Permite administrar y configurar eficazmente los recursos de equilibrio de carga dentro de los clústeres de Amazon EKS. La política incluye los siguientes permisos:
Administración de eventos y recursos:
+ Crear eventos y aplicarles parches.
+ Acceso de lectura a pods, nodos, puntos de conexión y espacios de nombres.
+ Actualice los estados de los pods.
Administración de servicios e ingresos:
+ Administración completa de los servicios y sus estados.
+ Control completo de los ingresos y sus estados.
+ Acceso de lectura a segmentos de puntos de conexión y clases de ingreso.
Vinculaciones de grupos de destino:
+ Cree y modifique vinculaciones de grupos de destino y sus estados.
+ Acceso de lectura a los parámetros de las clases de ingreso.
Administración de definiciones personalizadas de recursos (CRD):
+ Cree y lea todas las CRD.
+ Administración específica de las CRD de targetgroupbindings.eks.amazonaws.com e ingressclassparams.eks.amazonaws.com.
Configuración de webhook:
+ Cree y lea las configuraciones de webhook que mutan y validan.
+ Administre la configuración de eks-load-balancing-webhook.
Esta política está diseñada para admitir la administración integral del equilibrio de carga en los clústeres de Amazon EKS que se ejecutan en modo automático. Combina permisos para diversas operaciones, como la exposición de servicios, el enrutamiento de ingreso y la integración con servicios de equilibrio de carga de AWS.
Amazon EKS crea automáticamente una entrada de acceso con esta política de acceso para el rol de IAM del clúster cuando se habilita el modo automático, lo que garantiza que se disponga de los permisos necesarios para que la capacidad de equilibrio de carga funcione correctamente.
## AmazonEKSNetworkingClusterPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSNetworkingClusterPolicy`
AmazonEKSNetworkingClusterPolicy
Esta política concede los permisos necesarios para la capacidad de conexión en red del modo automático de Amazon EKS. Permite administrar y configurar eficazmente los recursos de red dentro de los clústeres de Amazon EKS. La política incluye los siguientes permisos:
Administración de nodos y pods:
+ Acceso de lectura a las clases de nodos y sus estados.
+ Acceso de lectura a las NodeClaims y sus estados.
+ Acceso de lectura a los pods.
Administración de nodos de CNI:
+ Permisos para CNINodes y sus estados, que incluyen crear, leer, actualizar, eliminar y aplicar parches.
Administración de definiciones personalizadas de recursos (CRD):
+ Cree y lea todas las CRD.
+ Administración específica (actualizar, parchear, eliminar) del CRD cninodes.eks.amazonaws.com.
Evento de administración:
+ Crear eventos y aplicarles parches.
Esta política está diseñada para admitir la administración integral de redes dentro de los clústeres de Amazon EKS que se ejecutan en modo automático. Combina permisos para varias operaciones, como la configuración de redes de nodos, la administración de la interfaz de red de contenedores (CNI) y la administración de recursos personalizados relacionados.
La política permite a los componentes de red interactuar con recursos relacionados con nodos, administrar configuraciones de nodos específicas de CNI y administrar recursos personalizados críticos para las operaciones de red en el clúster.
Amazon EKS crea automáticamente una entrada de acceso con esta política de acceso para el rol de IAM del clúster cuando se habilita el modo automático, lo que garantiza que se disponga de los permisos necesarios para que la capacidad de red funcione correctamente.
## AmazonEKSHybridPolicy
**nota**
Esta política está destinada exclusivamente a los roles vinculados a servicios de AWS y no se puede utilizar con roles administrados por el cliente.
Esta política de acceso incluye permisos que conceden a EKS acceso a los nodos de un clúster. Cuando se asocia a una entrada de acceso, su alcance de acceso suele ser el clúster, en lugar de un espacio de nombres de Kubernetes. Los Nodos híbridos de Amazon EKS utilizan esta política.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSHybridPolicy`
| Grupos de API de Kubernetes | nonResourceURLs de Kubernetes | Recursos de Kubernetes | Verbos de Kubernetes (permisos) |
| --- | --- | --- | --- |
| `*` | | `nodes` | `list` |
## AmazonEKSClusterInsightsPolicy
**nota**
Esta política está destinada exclusivamente a los roles vinculados a servicios de AWS y no se puede utilizar con roles administrados por el cliente.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterInsightsPolicy`
Esta política otorga permisos de solo lectura a Información del clúster de Amazon EKS. La política incluye los siguientes permisos:
Acceso a los nodos: - Enumeración y visualización de los nodos del clúster - Lectura de la información de estado de los nodos
Acceso al DaemonSet: - Acceso de lectura a la configuración de kube-proxy
El servicio de EKS de Información del clúster administra automáticamente esta política. Para obtener más información, consulte [Preparación para las actualizaciones de las versiones de Kubernetes y solución de problemas de configuración incorrecta con información sobre clústeres](cluster-insights.md).
## AWSBackupFullAccessPolicyForBackup
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AWSBackupFullAccessPolicyForBackup`
AWSBackupFullAccessPolicyForBackup
Esta política otorga los permisos necesarios para que AWS Backup administre y cree copias de seguridad del clúster de EKS. Esta política incluye los permisos siguientes:
| Grupos de API de Kubernetes | Recursos de Kubernetes | Verbos de Kubernetes (permisos) |
| --- | --- | --- |
| `*` | `*` | `list`, `get` |
## AWSBackupFullAccessPolicyForRestore
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AWSBackupFullAccessPolicyForRestore`
AWSBackupFullAccessPolicyForRestore
Esta política otorga los permisos necesarios para que AWS Backup administre y restaure copias de seguridad del clúster de EKS. Esta política incluye los permisos siguientes:
| Grupos de API de Kubernetes | Recursos de Kubernetes | Verbos de Kubernetes (permisos) |
| --- | --- | --- |
| `*` | `*` | `list`, `get`, `create` |
## AmazonEKSACKPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSACKPolicy`
Esta política otorga los permisos necesarios para que la capacidad Controladores de AWS para Kubernetes (ACK) administre los recursos de AWS desde Kubernetes. La política incluye los siguientes permisos:
Administración de recursos personalizados de ACK:
+ Acceso total a todos los recursos personalizados del servicio de ACK en más de 50 servicios de AWS, incluidos S3, RDS, DynamoDB, Lambda, EC2, etc.
+ Cree, lea, actualice y elimine definiciones de recursos personalizados de ACK.
Acceso al espacio de nombres:
+ Acceso de lectura a los espacios de nombres para organizar los recursos.
Elección de líder:
+ Cree y lea asignaciones de coordinación para la elección de líder.
+ Actualice y elimine las asignaciones específicas de controladores de servicios de ACK.
Evento de administración:
+ Cree eventos y aplíqueles parches para las operaciones de ACK.
Esta política está diseñada para admitir la administración integral de recursos de AWS a través de las API de Kubernetes. Amazon EKS crea automáticamente una entrada de acceso con esta política de acceso para el rol de IAM de la capacidad que se proporciona cuando se crea la capacidad de ACK.
| Grupos de API de Kubernetes | Recursos de Kubernetes | Verbos de Kubernetes (permisos) |
| --- | --- | --- |
| | `namespaces` | `get`, `watch`, `list` |
| `services.k8s.aws`, `acm.services.k8s.aws`, `acmpca.services.k8s.aws`, `apigateway.services.k8s.aws`, `apigatewayv2.services.k8s.aws`, `applicationautoscaling.services.k8s.aws`, `athena.services.k8s.aws`, `bedrock.services.k8s.aws`, `bedrockagent.services.k8s.aws`, `bedrockagentcorecontrol.services.k8s.aws`, `cloudfront.services.k8s.aws`, `cloudtrail.services.k8s.aws`, `cloudwatch.services.k8s.aws`, `cloudwatchlogs.services.k8s.aws`, `codeartifact.services.k8s.aws`, `cognitoidentityprovider.services.k8s.aws`, `documentdb.services.k8s.aws`, `dynamodb.services.k8s.aws`, `ec2.services.k8s.aws`, `ecr.services.k8s.aws`, `ecrpublic.services.k8s.aws`, `ecs.services.k8s.aws`, `efs.services.k8s.aws`, `eks.services.k8s.aws`, `elasticache.services.k8s.aws`, `elbv2.services.k8s.aws`, `emrcontainers.services.k8s.aws`, `eventbridge.services.k8s.aws`, `iam.services.k8s.aws`, `kafka.services.k8s.aws`, `keyspaces.services.k8s.aws`, `kinesis.services.k8s.aws`, `kms.services.k8s.aws`, `lambda.services.k8s.aws`, `memorydb.services.k8s.aws`, `mq.services.k8s.aws`, `networkfirewall.services.k8s.aws`, `opensearchservice.services.k8s.aws`, `organizations.services.k8s.aws`, `pipes.services.k8s.aws`, `prometheusservice.services.k8s.aws`, `ram.services.k8s.aws`, `rds.services.k8s.aws`, `recyclebin.services.k8s.aws`, `route53.services.k8s.aws`, `route53resolver.services.k8s.aws`, `s3.services.k8s.aws`, `s3control.services.k8s.aws`, `sagemaker.services.k8s.aws`, `secretsmanager.services.k8s.aws`, `ses.services.k8s.aws`, `sfn.services.k8s.aws`, `sns.services.k8s.aws`, `sqs.services.k8s.aws`, `ssm.services.k8s.aws`, `wafv2.services.k8s.aws` | `*` | `*` |
| `coordination.k8s.io` | `leases` | `create`, `get`, `list`, `watch` |
| `coordination.k8s.io` | `leases` (solo asignaciones de controladores de servicios de ACK específicos) | `delete`, `update`, `patch` |
| | `events` | `create`, `patch` |
| `apiextensions.k8s.io` | `customresourcedefinitions` | `*` |
## AmazonEKSArgoCDClusterPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy`
Esta política otorga los permisos de clúster necesarios para que la capacidad de Argo CD pueda detectar recursos y administrar objetos del ámbito del clúster. La política incluye los siguientes permisos:
Administración de espacios de nombres:
+ Cree, lea, actualice y elimine espacios de nombres para la administración de los espacios de nombres de las aplicaciones.
Administración de definiciones de recursos personalizados:
+ Administre CRD específicos de Argo CD (Aplicaciones, AppProjects, ApplicationSets).
Detección de API:
+ Lea el acceso a los puntos de conexión de la API de Kubernetes para la detección de recursos.
Esta política está diseñada para admitir las operaciones de clústeres de Argo CD, lo que incluye la administración del espacio de nombres y la instalación de CRD. Amazon EKS crea automáticamente una entrada de acceso con esta política de acceso para el rol de IAM de la capacidad que se proporciona cuando se crea la capacidad de Argo CD.
| Grupos de API de Kubernetes | nonResourceURLs de Kubernetes | Recursos de Kubernetes | Verbos de Kubernetes (permisos) |
| --- | --- | --- | --- |
| | | `namespaces` | `create`, `get`, `update`, `patch`, `delete` |
| `apiextensions.k8s.io` | | `customresourcedefinitions` | `create` |
| `apiextensions.k8s.io` | | `customresourcedefinitions` (solo CRD de Argo CD) | `get`, `update`, `patch`, `delete` |
| | `/api`, `/api/*`, `/apis`, `/apis/*` | | `get` |
## AmazonEKSArgoCDPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy`
Esta política otorga los permisos de espacio de nombres necesarios para que la capacidad de Argo CD pueda implementar y administrar aplicaciones. La política incluye los siguientes permisos:
Administración de secretos:
+ Acceso completo a los secretos para las credenciales de Git y los secretos de clústeres.
Acceso a ConfigMap:
+ Lea el acceso a ConfigMaps para enviar advertencias si los clientes intentan utilizar ConfigMaps de Argo CD no compatibles.
Evento de administración:
+ Lea y cree eventos para el seguimiento del ciclo de vida de la aplicación.
Administración de recursos de Argo CD:
+ Obtenga acceso completo a aplicaciones, ApplicationSets y AppProjects.
+ Administre los finalizadores y el estado de los recursos de Argo CD.
Esta política está diseñada para admitir las operaciones de espacios de nombres de Argo CD, lo que incluye la implementación y la administración de aplicaciones. Amazon EKS crea automáticamente una entrada de acceso con esta política de acceso para el rol de IAM de la capacidad que se proporciona cuando se crea la capacidad de Argo CD, en el ámbito del espacio de nombres de Argo CD.
| Grupos de API de Kubernetes | Recursos de Kubernetes | Verbos de Kubernetes (permisos) |
| --- | --- | --- |
| | `secrets` | `*` |
| | `configmaps` | `get`, `list`, `watch` |
| | `events` | `get`, `list`, `watch`, `patch`, `create` |
| `argoproj.io` | `applications`, `applications/finalizers`, `applications/status`, `applicationsets`, `applicationsets/finalizers`, `applicationsets/status`, `appprojects`, `appprojects/finalizers`, `appprojects/status` | `*` |
## AmazonEKSKROPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSKROPolicy`
Esta política otorga los permisos necesarios para que la capacidad de kro (Kube Resource Orchestrator) cree y administre las API de Kubernetes personalizadas. La política incluye los siguientes permisos:
Administración de recursos de kro:
+ Acceso completo a todos los recursos de kro, lo que incluye ResourceGraphDefinitions y las instancias de recursos personalizados.
Administración de definiciones de recursos personalizados:
+ Cree, lea, actualice y elimine CRD para API personalizadas definidas por ResourceGraphDefinitions.
Elección de líder:
+ Cree y lea asignaciones de coordinación para la elección de líder.
+ Actualice y elimine la asignación de controladores de kro.
Evento de administración:
+ Cree eventos y aplíqueles parches para las operaciones de kro.
Esta política está diseñada para admitir la composición integral de recursos y la administración de API personalizadas a través de kro. Amazon EKS crea automáticamente una entrada de acceso con esta política de acceso para el rol de IAM de la capacidad que se proporciona cuando se crea la capacidad de kro.
| Grupos de API de Kubernetes | Recursos de Kubernetes | Verbos de Kubernetes (permisos) |
| --- | --- | --- |
| `kro.run` | `*` | `*` |
| `apiextensions.k8s.io` | `customresourcedefinitions` | `*` |
| `coordination.k8s.io` | `leases` | `create`, `get`, `list`, `watch` |
| `coordination.k8s.io` | `leases` (solo asignación de controladores de kro) | `delete`, `update`, `patch` |
| | `events` | `create`, `patch` |
## Actualizaciones de la política de acceso
Vea detalles sobre las actualizaciones de las políticas de acceso desde su introducción. Para obtener alertas automáticas sobre cambios en esta página, suscríbase a la fuente RSS en [Historial de documentos](doc-history.md).
| Cambio | Descripción | Fecha |
| --- | --- | --- |
| Adición de políticas para capacidades de EKS | Publicación de `AmazonEKSACKPolicy`, `AmazonEKSArgoCDClusterPolicy`, `AmazonEKSArgoCDPolicy` y `AmazonEKSKROPolicy` para administrar capacidades de EKS | 22 de noviembre de 2025 |
| Añada `AmazonEKSSecretReaderPolicy` | Adición de una nueva política para el acceso de solo lectura a los secretos | 6 de noviembre de 2025 |
| Agregue una política para Información del clúster de EKS | Publicar `AmazonEKSClusterInsightsPolicy` | 2 de diciembre de 2024 |
| Agregar políticas para Amazon EKS Hybrid | Publicar `AmazonEKSHybridPolicy` | 2 de diciembre de 2024 |
| Agregar políticas para el modo automático de Amazon EKS | Estas políticas de acceso conceden al rol de IAM del clúster y al rol de IAM del nodo permiso para llamar a las API de Kubernetes. AWS las utiliza para automatizar tareas rutinarias para los recursos de almacenamiento, computación y redes. | 2 de diciembre de 2024 |
| Añada `AmazonEKSAdminViewPolicy` | Agregue una nueva política para ampliar el acceso a las vistas, incluidos recursos como Secretos. | 23 de abril de 2024 |
| Se introdujeron políticas de acceso. | Amazon EKS introdujo políticas de acceso. | 29 de mayo de 2023 |
# Cambio del modo de autenticación para utilizar las entradas de acceso
Para empezar a utilizar las entradas de acceso, cambie el modo de autenticación del clúster a los modos `API_AND_CONFIG_MAP` o `API`. Esto añade la API para las entradas de acceso.
## Consola de AWS
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Elija el nombre del clúster en el que desea crear una entrada de acceso.
1. Elija la pestaña **Acceso**.
1. En **Modo de autenticación** se muestra el modo de autenticación actual del clúster. Si el modo indica API de EKS, ya puede agregar entradas de acceso y puede omitir los pasos restantes.
1. Elija **Administrar acceso**.
1. En **Modo de autenticación de clústeres**, seleccione un modo con la API de EKS. Tenga en cuenta que no puede volver a cambiar el modo de autenticación a un modo que elimine la API de EKS y las entradas de acceso.
1. Seleccione **Save changes (Guardar cambios)**. Amazon EKS comienza a actualizar el clúster, el estado del clúster cambia a Actualizando y el cambio se registra en la pestaña **Historial de actualizaciones**.
1. Espere a que el estado del clúster vuelva a ser Activo. Cuando el clúster esté activo, puede seguir los pasos que se indican en [Creación de entradas de acceso](creating-access-entries.md) para agregar acceso al clúster para las entidades principales de IAM.
## AWS CLI
1. Instale AWS CLI, tal y como se describe en [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) en la *Guía del usuario de la interfaz de la línea de comandos de AWS*.
1. Ejecute el siguiente comando. Reemplace *my-cluster* por el nombre de su clúster. Si desea deshabilitar permanentemente el método `ConfigMap`, reemplace`API_AND_CONFIG_MAP` por `API`.
Amazon EKS comienza a actualizar el clúster, el estado del clúster cambia a ACTUALIZANDO y el cambio se registra en **aws eks list-updates**.
```
aws eks update-cluster-config --name my-cluster --access-config authenticationMode=API_AND_CONFIG_MAP
```
1. Espere a que el estado del clúster vuelva a ser Activo. Cuando el clúster esté activo, puede seguir los pasos que se indican en [Creación de entradas de acceso](creating-access-entries.md) para agregar acceso al clúster para las entidades principales de IAM.
## Versión de la plataforma requerida
Para usar *entradas de acceso*, el clúster debe tener una versión de la plataforma igual o posterior a la que se indica en la siguiente tabla, o una versión de Kubernetes posterior a las versiones que se muestran en la tabla. Si su versión de Kubernetes no aparece en la lista, todas las versiones de la plataforma admiten entradas de acceso.
| Versión de Kubernetes | Versión de la plataforma |
| --- | --- |
| No se muestra | Todos los compatibles |
| `1.30` | `eks.2` |
| `1.29` | `eks.1` |
| `1.28` | `eks.6` |
Para obtener más información, consulte [Versiones de la plataforma](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html).
# Creación de entradas de acceso
Antes de crear entradas de acceso, tenga en cuenta lo siguiente:
+ Un modo de autenticación configurado correctamente. Consulte [Cambio del modo de autenticación para utilizar las entradas de acceso](setting-up-access-entries.md).
+ Una *entrada de acceso* incluye el Nombre de recurso de Amazon (ARN) de una sola entidad principal de IAM existente. No se puede incluir una entidad principal de IAM en más de una entrada de acceso. Consideraciones adicionales para el ARN que especifique:
+ Las prácticas recomendadas de IAM sugieren acceder al clúster mediante *roles* de IAM que tengan credenciales a corto plazo, en lugar de *usuarios* de IAM que tengan credenciales a largo plazo. Para obtener más información, consulte [Solicitar que los usuarios humanos utilicen la federación con un proveedor de identidades para acceder a AWS mediante credenciales temporales](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) en la *Guía del usuario de IAM*.
+ Si el ARN es para un rol de IAM, *puede* incluir una ruta. Los ARN de las entradas del `ConfigMap` de `aws-auth` *no pueden* incluir una ruta. Por ejemplo, su ARN puede ser ` arn:aws:iam::<111122223333>:role/` o ` arn:aws:iam::<111122223333>:role/`.
+ Si el tipo de entrada de acceso es distinto a `STANDARD` (consulte la siguiente consideración sobre los tipos), el ARN debe estar en la misma cuenta de AWS que el clúster. Si el tipo es `STANDARD`, el ARN puede estar en la misma cuenta de AWS o en una cuenta diferente a la cuenta en la que se encuentra el clúster.
+ Después de crear la entrada de acceso, no se puede cambiar la entidad principal de IAM.
+ Si alguna vez elimina la entidad principal de IAM con este ARN, la entrada de acceso no se elimina automáticamente. Le recomendamos que elimine la entrada de acceso con un ARN para la entidad principal de IAM que desea eliminar. Si no elimina la entrada de acceso y vuelve a crear la entidad principal de IAM, la entrada de acceso no funcionará aunque tenga el mismo ARN. Esto se debe a que, aunque el ARN es el mismo para la entidad principal de IAM recreada, el `roleID` o `userID` (puede verlo con el comando `aws sts get-caller-identity` de la CLI de AWS) es diferente para la entidad principal de IAM recreada que para la entidad principal de IAM original. Aunque no vea el `roleID` o el `userID` de la entidad principal de IAM para una entrada de acceso, Amazon EKS lo almacena junto con la entrada de acceso.
+ Cada entrada de acceso tiene un *tipo*. El tipo de entrada de acceso depende del tipo de recurso con el que está asociada y no define los permisos. Si no especifica ningún tipo, Amazon EKS establece automáticamente el tipo en `STANDARD`.
+ `EC2_LINUX`: para un rol de IAM utilizado con nodos autoadministrados de Linux o Bottlerocket
+ `EC2_WINDOWS`: para un rol de IAM utilizado con nodos autoadministrados de Windows
+ `FARGATE_LINUX`: para un rol de IAM utilizado con AWS Fargate (Fargate)
+ `HYBRID_LINUX`: para un rol de IAM utilizado con nodos híbridos
+ `STANDARD`: tipo predeterminado si no se especifica ninguno
+ `EC2`: para las clases de nodos personalizados del modo automático de EKS. Para obtener más información, consulte [Creación de una entrada de acceso a una clase de nodos](create-node-class.md#auto-node-access-entry).
+ Después de crear la entrada de acceso, no se puede cambiar el tipo.
+ No es necesario crear una entrada de acceso para un rol de IAM que se utiliza para un grupo de nodos administrados o un perfil de Fargate. EKS creará entradas de acceso (si están habilitadas) o actualizará las asignaciones de configuración de autenticación (si las entradas de acceso no están disponibles).
+ Si el tipo de entrada de acceso es `STANDARD`, puede especificar un *nombre de usuario* para la entrada de acceso. Si no especifica un valor para el nombre de usuario, Amazon EKS establece uno de los siguientes valores en función del tipo de entrada de acceso y de si la entidad principal de IAM que especificó es un rol de IAM o un usuario de IAM. A menos que tenga un motivo específico para especificar su propio nombre de usuario, le recomendamos que no especifique ninguno y deje que Amazon EKS lo genere automáticamente. Si especifica su propio nombre de usuario:
+ No puede empezar con `system:`, `eks:`, `aws:`, `amazon:` o `iam:`.
+ Si el nombre de usuario corresponde a un rol de IAM, le recomendamos que añada `{{SessionName}}` o `{{SessionNameRaw}}` al final de este. Si añade `{{SessionName}}` o `{{SessionNameRaw}}` a su nombre de usuario, este debe incluir dos puntos *antes de* \$1\$1SessionName\$1\$1. Cuando se asume este rol, el nombre de la sesión de AWS STS especificada al asumir el rol se transfiere automáticamente al clúster y aparece en los registros de CloudTrail. Por ejemplo, no puede tener un nombre de usuario como `john{{SessionName}}`. El nombre de usuario tendría que ser `:john{{SessionName}}` o `jo:hn{{SessionName}}`. Los dos puntos deben estar antes de `{{SessionName}}`. El nombre de usuario generado por Amazon EKS en la siguiente tabla incluye un ARN. Como un ARN incluye dos puntos, cumple con este requisito. Los dos puntos no son obligatorios si no incluye `{{SessionName}}` en su nombre de usuario. Tenga en cuenta que, en `{{SessionName}}`, el carácter especial “@” se sustituye por “-” en el nombre de la sesión. `{{SessionNameRaw}}` mantiene todos los caracteres especiales en el nombre de la sesión.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/creating-access-entries.html)
Puede cambiar el nombre de usuario después de crear la entrada de acceso.
+ Si el tipo de entrada de acceso es `STANDARD` y desea utilizar la autorización RBAC de Kubernetes, puede agregar uno o más *nombres de grupo* a la entrada de acceso. Después de crear una entrada de acceso, puede añadir y eliminar nombres de grupos. Para que la entidad principal de IAM tenga acceso a los objetos de Kubernetes del clúster, debe crear y administrar los objetos de autorización basados en roles (RBAC) de Kubernetes. Cree objetos `RoleBinding` o `ClusterRoleBinding` de Kubernetes en el clúster que especifique el nombre del grupo como `subject` para `kind: Group`. Kubernetes autoriza el acceso de la entidad principal de IAM a cualquier objeto del clúster que haya especificado en un objeto `Role` o `ClusterRole` de Kubernetes que también haya especificado en el `roleRef` del enlace. Si especifica los nombres de grupo, recomendamos que esté familiarizado con los objetos de Autorizaciones basados en roles (RBAC) de Kubernetes. Para obtener más información, consulte [Utilización de la autorización de RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) en la documentación de Kubernetes.
**importante**
Amazon EKS no confirma que ninguno de los objetos de RBAC de Kubernetes en el clúster incluya alguno de los nombres de grupo que especifique. Por ejemplo, si crea una entrada de acceso para un grupo que no existe actualmente, EKS creará el grupo en lugar de arrojar un error.
En lugar de autorizar a Kubernetes para que la entidad principal de IAM acceda a los objetos de Kubernetes de su clúster, o además de ello, puede asociar las *políticas de acceso* de Amazon EKS a una entrada de acceso. Amazon EKS autoriza a las entidades principales de IAM a acceder a los objetos de Kubernetes del clúster con los permisos de la política de acceso. Puede limitar los permisos de una política de acceso a los espacios de nombres de Kubernetes que especifique. El uso de políticas de acceso no requiere que administre los objetos de RBAC de Kubernetes. Para obtener más información, consulte [Asociación de políticas de acceso a entradas de acceso](access-policies.md).
+ Si crea una entrada de acceso con el tipo `EC2_LINUX` o `EC2_Windows`, la entidad principal de IAM que crea la entrada de acceso debe tener el permiso `iam:PassRole`. Para obtener más información, consulte [Concesión de permisos a un usuario para transferir un rol a un servicio de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) en la *Guía del usuario de IAM*.
+ Al igual que el [comportamiento de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency) estándar, la creación y las actualizaciones de las entradas de acceso son eventualmente uniformes y pueden tardar varios segundos en hacerse efectivas una vez que la llamada inicial a la API se haya completado con éxito. Debe diseñar sus aplicaciones teniendo en cuenta estos posibles retrasos. Le recomendamos que no incluya las creaciones o las actualizaciones de las entradas de acceso en las rutas de código de gran importancia y alta disponibilidad de su aplicación. En su lugar, realice los cambios de en otra rutina de inicialización o configuración que ejecute con menos frecuencia. Además, asegúrese de verificar que los cambios se han propagado antes de que los flujos de trabajo de producción dependan de ellos.
+ Las entradas de acceso no admiten [roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html). No puede crear entradas de acceso en las que el ARN principal sea un rol vinculado al servicio. Puede identificar los roles vinculados al servicio por su ARN, que está en el formato ` arn:aws:iam::*:role/aws-service-role/*`.
Puede crear una entrada de acceso mediante la Consola de administración de AWS o la CLI de AWS.
## Consola de administración de AWS
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Elija el nombre del clúster en el que desea crear una entrada de acceso.
1. Elija la pestaña **Acceso**.
1. Elija **Crear entrada de acceso**.
1. En **Entidad principal de IAM**, seleccione un usuario o rol de IAM existente. Las prácticas recomendadas de IAM sugieren acceder al clúster mediante *roles* de IAM que tengan credenciales a corto plazo, en lugar de *usuarios* de IAM que tengan credenciales a largo plazo. Para obtener más información, consulte [Solicitar que los usuarios humanos utilicen la federación con un proveedor de identidades para acceder a AWS mediante credenciales temporales](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) en la *Guía del usuario de IAM*.
1. **En **Tipo**, si la entrada de acceso es para el rol de nodo utilizado para los nodos Amazon EC2 autoadministrados, seleccione **EC2 Linux** o EC2 Windows**. De lo contrario, acepte el valor predeterminado (**Estándar**).
1. Si el **Tipo** que ha elegido es **Estándar** y desea especificar un **Nombre de usuario**, introdúzcalo.
1. Si el **Tipo** que ha elegido es **Estándar** y desea utilizar la autorización RBAC de Kubernetes para la entidad principal de IAM, especifique uno o más nombres para los **Grupos**. Si no especifica ningún nombre de grupo y desea utilizar la autorización de Amazon EKS, puede asociar una política de acceso en un paso posterior o después de crear la entrada de acceso.
1. (Opcional) En **Etiquetas**, asigne etiquetas a la entrada de acceso. Por ejemplo, para facilitar la búsqueda de todos los recursos con la misma etiqueta.
1. Elija **Siguiente**.
1. En la página **Agregar política de acceso**, si el tipo que ha elegido es **Estándar** y quiere que Amazon EKS autorice a la entidad principal de IAM a tener permisos para los objetos de Kubernetes de su clúster, complete los siguientes pasos. En caso contrario, elija **Siguiente**.
1. En **Nombre de la política**, elija una política de acceso. No puede ver los permisos de las políticas de acceso, pero incluyen permisos similares a los de los objetos `ClusterRole` orientados al usuario de Kubernetes. Para obtener más información, consulte [User-facing roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) en la documentación de Kubernetes.
1. Seleccione una de las siguientes opciones:
+ **Clúster**: elija esta opción si desea que Amazon EKS autorice a la entidad principal de IAM a tener los permisos de la política de acceso para todos los objetos de Kubernetes de su clúster.
+ **Espacio de nombres de Kubernetes**: elija esta opción si desea que Amazon EKS autorice a la entidad principal de IAM a tener los permisos de la política de acceso para todos los objetos de Kubernetes en un espacio de nombres específico de Kubernetes en su clúster. En **Espacio de nombres**, ingrese el nombre del espacio de nombres de Kubernetes en el clúster. Si quiere añadir espacios de nombres adicionales, seleccione **Añadir nuevo espacio de nombres** e ingrese el nombre del espacio de nombres.
1. Si desea añadir políticas adicionales, seleccione **Añadir política**. Puede establecer el ámbito de cada política de forma diferente, pero puede añadir cada política solo una vez.
1. Elija **Siguiente**.
1. Revise la configuración de su entrada de acceso. Si algo parece incorrecto, seleccione **Anterior** para volver a repasar los pasos y corregir el error. Si la configuración es correcta, seleccione **Crear**.
## AWS CLI
1. Instale la CLI de AWS, tal y como se describe en [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) en la Guía del usuario de la interfaz de la línea de comandos de AWS.
1. Puede utilizar cualquiera de los siguientes ejemplos para crear entradas de acceso:
+ Cree una entrada de acceso para un grupo de nodos autoadministrados de Amazon EC2 Linux. Reemplace *my-cluster* por el nombre del clúster, *111122223333* por el ID de la cuenta de AWS y *EKS-my-cluster-self-managed-ng-1* por el nombre del [rol de IAM del nodo](create-node-role.md). Si el grupo de nodos es un grupo de nodos de Windows, sustituya *EC2\$1Linux* por `EC2_Windows`.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 --type EC2_LINUX
```
No puede utilizar la opción `--kubernetes-groups` cuando especifica un tipo que no sea `STANDARD`. No puede asociar una política de acceso a esta entrada de acceso porque su tipo es un valor distinto a `STANDARD`.
+ Cree una entrada de acceso que permita a un rol de IAM, no utilizado por un grupo de nodos autoadministrados de Amazon EC2, autorizar a Kubernetes el acceso a su clúster. Reemplace *my-cluster* por el nombre de su clúster, *111122223333* por el ID de su cuenta de AWS y *my-role* por el nombre de su rol de IAM. Reemplace *Espectadores* por el nombre de un grupo que haya especificado en un objeto `RoleBinding` o `ClusterRoleBinding` de Kubernetes de su clúster.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role --type STANDARD --user Viewers --kubernetes-groups Viewers
```
+ Cree una entrada de acceso que permita a un usuario de IAM autenticarse en su clúster. Este ejemplo se proporciona porque es posible, aunque las prácticas recomendadas de IAM sugieren acceder a su clúster mediante *roles* de IAM que tengan credenciales a corto plazo, en lugar de *usuarios* de IAM que tengan credenciales a largo plazo. Para obtener más información, consulte [Solicitar que los usuarios humanos utilicen la federación con un proveedor de identidades para acceder a AWS mediante credenciales temporales](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) en la *Guía del usuario de IAM*.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:user/my-user --type STANDARD --username my-user
```
Si desea que este usuario tenga más acceso a su clúster que los permisos en los roles de detección de la API de Kubernetes, debe asociar una política de acceso a la entrada de acceso, ya que la opción `--kubernetes-groups` no se utiliza. Para obtener más información, consulte [Asociación de políticas de acceso a entradas de acceso](access-policies.md) y [API discovery roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#discovery-roles) en la documentación de Kubernetes.
# Actualización de entradas de acceso
Puede actualizar una entrada de acceso mediante la Consola de administración de AWS o la AWS CLI.
## Consola de administración de AWS
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Elija el nombre del clúster en el que desea crear una entrada de acceso.
1. Elija la pestaña **Acceso**.
1. Elija la entrada de acceso que desea actualizar.
1. Elija **Editar**.
1. En **Nombre de usuario**, puede cambiar el valor existente.
1. En **Grupos**, puede eliminar los nombres de los grupos existentes o añadir nuevos nombres de grupos. Si existen los siguientes nombres de grupos, no los elimine: **system:nodes** o **system:bootstrappers**. Si elimina estos grupos, puede provocar que el clúster no funcione correctamente. Si no especifica ningún nombre de grupo y desea utilizar la autorización de Amazon EKS, asocie una [política de acceso](access-policies.md) en un paso posterior.
1. En **Etiquetas**, puede asignar etiquetas a la entrada de acceso. Por ejemplo, para facilitar la búsqueda de todos los recursos con la misma etiqueta. También puede eliminar las etiquetas existentes.
1. Elija **Guardar cambios**.
1. Si desea asociar una política de acceso a la entrada, consulte [Asociación de políticas de acceso a entradas de acceso](access-policies.md).
## AWS CLI
1. Instale la AWS CLI, tal y como se describe en [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) en la Guía del usuario de la interfaz de la línea de comandos de AWS.
1. Para actualizar una entrada de acceso Sustituya *my-cluster* por el nombre de su clúster, *111122223333* por el ID de su cuenta de AWS y *EKS-my-cluster-my-namespace-Viewers* por el nombre de un rol de IAM.
```
aws eks update-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers --kubernetes-groups Viewers
```
No puede usar la opción de `--kubernetes-groups` si el tipo de entrada de acceso es un valor distinto a `STANDARD`. Tampoco puede asociar una política de acceso a una entrada de acceso de un tipo distinto a `STANDARD`.
# Eliminación de entradas de acceso
Si descubre que ha eliminado una entrada de acceso por error, siempre podrá volver a crearla. Si la entrada de acceso que va a eliminar está asociada a alguna política de acceso, las asociaciones se eliminarán automáticamente. No es necesario desasociar las políticas de acceso de una entrada de acceso antes de eliminarla.
Puede eliminar una entrada de acceso de mediante la Consola de administración de AWS o la CLI de AWS.
## Consola de administración de AWS
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Elija el nombre del clúster del que desea eliminar una entrada de acceso.
1. Elija la pestaña **Acceso**.
1. En la lista de **Entradas de acceso**, elija la entrada de acceso que desea eliminar.
1. Elija Eliminar.
1. En el cuadro de diálogo de confirmación, elija **Eliminar**.
## AWS CLI
1. Instale la CLI de AWS, tal y como se describe en [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) la Guía del usuario de la interfaz de la línea de comandos de AWS.
1. Para eliminar una entrada de acceso, reemplace *my-cluster* por el nombre de su clúster, *111122223333* por el ID de su cuenta de AWS y *my-role* por el nombre del rol de IAM que ya no quiere que tenga acceso a su clúster.
```
aws eks delete-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role
```
# Establecimiento de un nombre de usuario personalizado para las entradas de acceso de EKS
Al crear entradas de acceso para Amazon EKS, puede utilizar el nombre de usuario generado automáticamente o especificar un nombre de usuario personalizado. En esta página se explican ambas opciones y se le guía por la configuración de un nombre de usuario personalizado.
## Descripción general
El nombre de usuario de una entrada de acceso se utiliza para identificar la entidad principal de IAM en las pistas de auditoría y los registros de Kubernetes. De forma predeterminada, Amazon EKS genera un nombre de usuario en función del ARN de la identidad de IAM, pero puede especificar un nombre de usuario personalizado si es necesario.
## Generación de nombres de usuario predeterminados
Si no especifica ningún valor para el nombre de usuario, Amazon EKS genera automáticamente un nombre de usuario en función de la identidad de IAM:
+ **Para usuarios de IAM**:
+ EKS establece el nombre de usuario de Kubernetes en el ARN del usuario de IAM
+ Ejemplo:
```
{arn-aws}iam::<111122223333>:user/
```
+ **Para roles de IAM**:
+ EKS establece el nombre de usuario de Kubernetes en función del ARN del rol de IAM
+ El ARN de STS del rol cuando se asume. Amazon EKS agrega `{{SessionName}}` al rol. Si el ARN del rol que especificó contenía una ruta, Amazon EKS la elimina del nombre de usuario generado.
+ Ejemplo:
```
{arn-aws}sts::<111122223333>:assumed-role//{{SessionName}}
```
A menos que tenga un motivo concreto para especificar su propio nombre de usuario, le recomendamos que no especifique ninguno y deje que Amazon EKS lo genere automáticamente.
## Establecimiento de un nombre de usuario personalizado
Al crear una entrada de acceso, puede especificar un nombre de usuario personalizado mediante el parámetro `--username`:
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD --username
```
### Requisitos para los nombres de usuario personalizados
Si especifica un nombre de usuario personalizado:
+ El nombre de usuario no puede empezar por `system:`, `eks:`, `aws:`, `amazon:` ni `iam:`.
+ Si el nombre de usuario corresponde a un rol de IAM, le recomendamos que añada `{{SessionName}}` o `{{SessionNameRaw}}` al final de este.
+ Si añade `{{SessionName}}` o `{{SessionNameRaw}}` a su nombre de usuario, este debe incluir dos puntos *antes de* \$1\$1SessionName\$1\$1.
# Creación de una entrada de acceso para un usuario o rol de IAM mediante una política de acceso y la AWS CLI
Cree entradas de acceso a Amazon EKS que utilicen políticas de acceso de EKS administradas de AWS para conceder permisos estandarizados a las identidades de IAM para acceder a los clústeres de Kubernetes y administrarlos.
## Descripción general
Las entradas de acceso en Amazon EKS definen cómo las identidades de IAM (usuarios y roles) pueden acceder a sus clústeres de Kubernetes e interactuar con ellos. Al crear entradas de acceso con las políticas de acceso de EKS, puede hacer lo siguiente:
+ Conceder permisos a roles o usuarios de IAM específicos para acceder a su clúster de EKS
+ Controlar los permisos mediante políticas de acceso de EKS administradas de AWS que proporcionan conjuntos de permisos estandarizados y predefinidos
+ Limitar los permisos a espacios de nombres específicos o a todo el clúster
+ Simplificar la administración del acceso sin modificar `aws-auth` ConfigMap ni crear recursos de RBAC de Kubernetes
+ Utilizar un enfoque integrado de AWS para el control de acceso de Kubernetes que trate los casos de uso más comunes y, al mismo tiempo, mantenga las prácticas recomendadas de seguridad
Este enfoque se recomienda para la mayoría de los casos de uso porque proporciona permisos estandarizados y administrados de AWS sin requerir ninguna configuración manual de RBAC de Kubernetes. Las políticas de acceso de EKS eliminan la necesidad de configurar manualmente los recursos de RBAC de Kubernetes y ofrecen conjuntos de permisos predefinidos que tratan los casos de uso más comunes.
## Requisitos previos
+ El *modo de autenticación* del clúster debe estar configurado para habilitar las *entradas de acceso*. Para obtener más información, consulte [Cambio del modo de autenticación para utilizar las entradas de acceso](setting-up-access-entries.md).
+ Instale y configure la AWS CLI, tal y como se describe en [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) en la Guía del usuario de la Interfaz de la línea de comandos de AWS.
## Paso 1: definición de la entrada de acceso
1. Busque el ARN de la identidad de IAM (por ejemplo, un usuario o rol) al que desea conceder permisos.
+ Cada identidad de IAM solo puede tener una entrada de acceso a EKS.
1. Determine si desea que los permisos de la política de acceso de Amazon EKS se apliquen solo a un espacio de nombres de Kubernetes específico o a todo el clúster.
+ Si desea limitar los permisos a un espacio de nombres específico, anote el nombre del espacio de nombres.
1. Seleccione la política de acceso de EKS que desee para la identidad de IAM. Esta política concede permisos en el clúster. Anote el ARN de la política.
+ Para ver una lista de políticas, consulte las [políticas de acceso disponibles](access-policy-permissions.md).
1. Determine si el nombre de usuario generado automáticamente es adecuado para la entrada de acceso o si necesita especificar un nombre de usuario manualmente.
+ AWS genera automáticamente este valor en función de la identidad de IAM. Puede configurar un nombre de usuario personalizado. Esto es visible en los registros de Kubernetes.
+ Para obtener más información, consulte [Establecimiento de un nombre de usuario personalizado para las entradas de acceso de EKS](set-custom-username.md).
## Paso 2: creación de una entrada de acceso
Después de planificar la entrada de acceso, utilice la AWS CLI para crearla.
El siguiente ejemplo trata la mayoría de los casos de uso. [Consulte la referencia de CLI para ver todas las opciones de configuración](https://docs.aws.amazon.com/cli/latest/reference/eks/create-access-entry.html).
Adjuntará la política de acceso en el siguiente paso.
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD
```
## Paso 3: asociación de la política de acceso
El comando varía en función de si desea que la política se limite a un espacio de nombres de Kubernetes específico.
Necesita el ARN de la política de acceso. Consulte las [políticas de acceso disponibles](access-policy-permissions.md).
### Creación de una política sin ámbito de espacio de nombres
```
aws eks associate-access-policy --cluster-name --principal-arn --policy-arn
```
### Creación con ámbito de espacio de nombres
```
aws eks associate-access-policy --cluster-name --principal-arn \
--access-scope type=namespace,namespaces=my-namespace1,my-namespace2 --policy-arn
```
## Pasos a seguir a continuación
+ [Creación de kubeconfig para poder usar kubectl con una identidad de IAM](create-kubeconfig.md)
# Creación de una entrada de acceso mediante grupos de Kubernetes con la AWS CLI
Cree entradas de acceso de Amazon EKS que utilicen grupos de Kubernetes para la autorización y que requieran una configuración de RBAC manual.
**nota**
Para la mayoría de los casos de uso, recomendamos utilizar las políticas de acceso de EKS en lugar del enfoque de grupos de Kubernetes que se describe en esta página. Las políticas de acceso de EKS proporcionan una forma más sencilla e integrada con AWS de administrar el acceso sin requerir una configuración de RBAC manual. Utilice el enfoque de grupos de Kubernetes solo cuando necesite un control más detallado que el que ofrecen las políticas de acceso de EKS.
## Descripción general
Las entradas de acceso definen cómo las identidades de IAM (usuarios y roles) acceden a sus clústeres de Kubernetes. El enfoque de grupos de Kubernetes concede a los usuarios o roles de IAM permiso para acceder al clúster de EKS a través de grupos de RBAC estándar de Kubernetes. Este método requiere crear y administrar recursos de RBAC de Kubernetes (Roles, RoleBindings, ClusterRoles y ClusterRoleBindings) y se recomienda cuando se necesitan conjuntos de permisos altamente personalizados, requisitos de autorización complejos o si se desea mantener patrones de control de acceso consistentes en los entornos híbridos de Kubernetes.
En este tema no se trata la creación de entradas de acceso para las identidades de IAM utilizadas para que las instancias de Amazon EC2 se unan a los clústeres de EKS.
## Requisitos previos
+ El *modo de autenticación* del clúster debe estar configurado para habilitar las *entradas de acceso*. Para obtener más información, consulte [Cambio del modo de autenticación para utilizar las entradas de acceso](setting-up-access-entries.md).
+ Instale y configure la AWS CLI, tal y como se describe en [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) en la Guía del usuario de la Interfaz de la línea de comandos de AWS.
+ Se recomienda haberse familiarizado con RBAC de Kubernetes. Para obtener más información, consulte [Utilización de la autorización de RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) en la documentación de Kubernetes.
## Paso 1: definición de la entrada de acceso
1. Busque el ARN de la identidad de IAM (por ejemplo, un usuario o rol) al que desea conceder permisos.
+ Cada identidad de IAM solo puede tener una entrada de acceso a EKS.
1. Defina los grupos de Kubernetes que desea asociar a esta identidad de IAM.
+ Deberás crear o usar los recursos `Role`/`ClusterRole` y `RoleBinding`/`ClusterRoleBinding` de Kubernetes existentes que hagan referencia a estos grupos.
1. Determine si el nombre de usuario generado automáticamente es adecuado para la entrada de acceso o si necesita especificar un nombre de usuario manualmente.
+ AWS genera automáticamente este valor en función de la identidad de IAM. Puede configurar un nombre de usuario personalizado. Esto es visible en los registros de Kubernetes.
+ Para obtener más información, consulte [Establecimiento de un nombre de usuario personalizado para las entradas de acceso de EKS](set-custom-username.md).
## Paso 2: creación de una entrada de acceso con grupos de Kubernetes
Tras planificar la entrada de acceso, utilice la AWS CLI para crearla con los grupos de Kubernetes correspondientes.
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD --kubernetes-groups
```
Reemplace:
+ `` por el nombre del clúster de EKS
+ `` por el ARN del rol o usuario de IAM
+ `` por una lista de grupos de Kubernetes separados por comas (por ejemplo, “system:developers,system:readers”)
[Consulte la referencia de CLI para ver todas las opciones de configuración](https://docs.aws.amazon.com/cli/latest/reference/eks/create-access-entry.html).
## Paso 3: configuración de RBAC de Kubernetes
Para que la entidad principal de IAM tenga acceso a los objetos de Kubernetes del clúster, debe crear y administrar los objetos de control de acceso basados en roles (RBAC) de Kubernetes:
1. Cree objetos `Role` o `ClusterRole` de Kubernetes que definan los permisos.
1. Cree objetos `RoleBinding` o `ClusterRoleBinding` de Kubernetes en el clúster que especifique el nombre del grupo como `subject` para `kind: Group`.
Para obtener información detallada sobre la configuración de grupos y permisos en Kubernetes, consulte [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) en la documentación de Kubernetes.
## Pasos a seguir a continuación
+ [Creación de kubeconfig para poder usar kubectl con una identidad de IAM](create-kubeconfig.md)
# Concesión de acceso a Kubernetes con un ConfigMap para los usuarios de IAM
**importante**
`aws-auth ConfigMap` se ha quedado obsoleto. Para conocer el método recomendado a fin de administrar el acceso a las API de Kubernetes, consulte [Concesión de acceso para los usuarios de IAM a las entradas de acceso de Kubernetes con EKS](access-entries.md).
El acceso al clúster mediante [las entidades principales de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) está habilitado por el [AWSAutenticador de IAM para Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme), que se ejecuta en el plano de control de Amazon EKS. El autenticador obtiene la información de la configuración del `ConfigMap` de `aws-auth`. Para todos las configuraciones del `ConfigMap` de `aws-auth`, consulte el [formato de configuración completa](https://github.com/kubernetes-sigs/aws-iam-authenticator#full-configuration-format) en GitHub.
## Agregar las entidades principales de IAM al clúster de Amazon EKS
Cuando se crea un clúster de Amazon EKS, la [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que crea el clúster recibe permisos de `system:masters` de forma automática en la configuración del Control de acceso basado en roles (RBAC) del clúster en el plano de control de Amazon EKS. Esta entidad principal no aparece en ninguna configuración visible, así que asegúrese de realizar un seguimiento de la entidad principal que creó el clúster originalmente. Para conceder a entidades principales adicionales de IAM la capacidad de interactuar con el clúster, edite el `aws-auth ConfigMap` dentro de Kubernetes y cree un `rolebinding` o `clusterrolebinding` de Kubernetes con el nombre de un `group` que especifique en el `aws-auth ConfigMap`.
**nota**
Para obtener más información sobre la configuración del control de acceso basado en roles (RBAC) de Kubernetes, consulte [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) en la documentación de Kubernetes.
1. Determine qué credenciales de `kubectl` utiliza para obtener acceso al clúster. En la computadora, puede ver qué credenciales de `kubectl` utiliza con el siguiente comando. Si no utiliza la ruta predeterminada, reemplace *\$1/.kube/config* por la ruta al archivo `kubeconfig`.
```
cat ~/.kube/config
```
Un ejemplo de salida sería el siguiente.
```
[...]
contexts:
- context:
cluster: my-cluster.region-code.eksctl.io
user: admin@my-cluster.region-code.eksctl.io
name: admin@my-cluster.region-code.eksctl.io
current-context: admin@my-cluster.region-code.eksctl.io
[...]
```
En la salida de ejemplo anterior, se configuran las credenciales de un usuario llamado *admin* para un clúster con el nombre *my-cluster*. Si este es el usuario que creó el clúster, entonces ya tiene acceso a él. Si no es el usuario el que creó el clúster, deberá completar los pasos restantes para habilitar el acceso al clúster para otras entidades principales de IAM. Según las [prácticas recomendadas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html), se recomienda conceder permisos a los roles en lugar de a los usuarios. Puede ver qué otras entidades principales tienen acceso actualmente al clúster con el siguiente comando:
```
kubectl describe -n kube-system configmap/aws-auth
```
Un ejemplo de salida sería el siguiente.
```
Name: aws-auth
Namespace: kube-system
Labels:
Annotations:
Data
====
mapRoles:
----
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::111122223333:role/my-node-role
username: system:node:{{EC2PrivateDNSName}}
BinaryData
====
Events:
```
El ejemplo anterior es un valor predeterminado `aws-auth` `ConfigMap`. Solo el rol de la instancia de nodos tiene acceso al clúster.
1. Asegúrese de tener `roles` y `rolebindings` de Kubernetes o `clusterroles` y `clusterrolebindings` existentes a los que pueda asignar entidades principales de IAM. Para obtener más información sobre estos recursos, consulte [Utilización de la autorización de RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) en la documentación de Kubernetes.
1. Vea sus Kubernetes existentes `roles` o `clusterroles`. Los `Roles` están asignados a un `namespace`, pero los `clusterroles` se ajustan al clúster.
```
kubectl get roles -A
```
```
kubectl get clusterroles
```
1. Consulte los detalles de cualquier `role` o `clusterrole` devuelto en la salida anterior y confirme que tiene los permisos (`rules`) que desea que las entidades principales de IAM tengan en el clúster.
Reemplace *role-name* con un nombre de `role` devuelto en el resultado del comando anterior. Reemplace *kube-system* con el espacio de nombres del `role`.
```
kubectl describe role role-name -n kube-system
```
Reemplace *cluster-role-name* con un nombre de `clusterrole` devuelto en el resultado del comando anterior.
```
kubectl describe clusterrole cluster-role-name
```
1. Vea sus Kubernetes existentes `rolebindings` o `clusterrolebindings`. Los `Rolebindings` están asignados a un `namespace`, pero los `clusterrolebindings` se ajustan al clúster.
```
kubectl get rolebindings -A
```
```
kubectl get clusterrolebindings
```
1. Vea los detalles de cualquier `rolebinding` o `clusterrolebinding` y confirme que tiene un `role` o `clusterrole` del paso anterior enumerado como `roleRef` y un nombre de grupo enumerado para `subjects`.
Reemplace *role-binding-name* con un nombre `rolebinding` devuelto en el resultado del comando anterior. Reemplace *kube-system* con `namespace` del `rolebinding`.
```
kubectl describe rolebinding role-binding-name -n kube-system
```
Un ejemplo de salida sería el siguiente.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: eks-console-dashboard-restricted-access-role-binding
namespace: default
subjects:
- kind: Group
name: eks-console-dashboard-restricted-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: eks-console-dashboard-restricted-access-role
apiGroup: rbac.authorization.k8s.io
```
Reemplace *cluster-role-binding-name* con un nombre `clusterrolebinding` devuelto en el resultado del comando anterior.
```
kubectl describe clusterrolebinding cluster-role-binding-name
```
Un ejemplo de salida sería el siguiente.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: eks-console-dashboard-full-access-binding
subjects:
- kind: Group
name: eks-console-dashboard-full-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: eks-console-dashboard-full-access-clusterrole
apiGroup: rbac.authorization.k8s.io
```
1. Edite el `ConfigMap` de `aws-auth`. Puede utilizar una herramienta como `eksctl` para actualizar el `ConfigMap` o puede actualizarlo manualmente editándolo.
**importante**
Recomendamos utilizar `eksctl`, u otra herramienta, para editar el `ConfigMap`. Para obtener información acerca de otras herramientas que puede utilizar, consulte [Utilice herramientas para realizar cambios en el aws-authConfigMap](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#use-tools-to-make-changes-to-the-aws-auth-configmap) en las guías de prácticas recomendadas de Amazon EKS. Un formato incorrecto de `aws-auth` `ConfigMap` puede provocar que pierda el acceso a su clúster.
+ Vea los pasos para [editar el configmap con eksctl](#configmap-eksctl).
+ Vea los pasos para [editar el configmap manualmente](#configmap-manual).
### Edición de Configmap con Eksctl
1. Necesita 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. Vea las asignaciones actuales en la `ConfigMap`. Reemplace *my-cluster* por el nombre de su clúster. Reemplace *region-code* por la región de AWS en la que se encuentra el clúster.
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
Un ejemplo de salida sería el siguiente.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws:iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
```
1. Agregue una asignación para un rol. Reemplace *my-role* con el nombre de su rol. Reemplace *eks-console-dashboard-full-access-group* por el nombre del grupo especificado en su objeto `RoleBinding` o `ClusterRoleBinding` de Kubernetes. Reemplace *111122223333* por el ID de su cuenta. Puede reemplazar *admin* (administrador) con cualquier nombre que elija.
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws:iam::111122223333:role/my-role --username admin --group eks-console-dashboard-full-access-group \
--no-duplicate-arns
```
**importante**
El ARN del rol no puede incluir una ruta como `role/my-team/developers/my-role`. El formato del ARN debe ser ` arn:aws:iam::111122223333:role/my-role `. En este ejemplo, se necesita eliminar `my-team/developers/`.
Un ejemplo de salida sería el siguiente.
```
[...]
2022-05-09 14:51:20 [ℹ] adding identity "{arn-aws}iam::111122223333:role/my-role" to auth ConfigMap
```
1. Agregue una asignación para un usuario. Según las [prácticas recomendadas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html), se recomienda conceder permisos a los roles en lugar de a los usuarios. Reemplace *my-user* por el nombre de usuario. Reemplace *eks-console-dashboard-restricted-access-group* por el nombre del grupo especificado en su objeto `RoleBinding` o `ClusterRoleBinding` de Kubernetes. Reemplace *111122223333* por el ID de su cuenta. Puede reemplazar *my-user* (mi usuario) con cualquier nombre que elija.
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws:iam::111122223333:user/my-user --username my-user --group eks-console-dashboard-restricted-access-group \
--no-duplicate-arns
```
Un ejemplo de salida sería el siguiente.
```
[...]
2022-05-09 14:53:48 [ℹ] adding identity "arn:aws:iam::111122223333:user/my-user" to auth ConfigMap
```
1. Vea las asignaciones en el `ConfigMap` de nuevo.
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
Un ejemplo de salida sería el siguiente.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws:iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws:iam::111122223333:role/admin my-role eks-console-dashboard-full-access-group
arn:aws:iam::111122223333:user/my-user my-user eks-console-dashboard-restricted-access-group
```
### Edición de Configmap manualmente
1. Abra el icono `ConfigMap` para editar.
```
kubectl edit -n kube-system configmap/aws-auth
```
**nota**
Si recibe un error que indica “`Error from server (NotFound): configmaps "aws-auth" not found`”, utilice el procedimiento de [Aplicación de ConfigMap de aws-auth a un clúster](#aws-auth-configmap) para aplicar el `ConfigMap` estándar.
1. Agregue las entidades principales de IAM al `ConfigMap`. Un grupo de IAM no es una entidad principal de IAM, por lo que no se puede agregar al `ConfigMap`.
+ **A fin de agregar un rol de IAM (por ejemplo, para [usuarios federados](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)):** agregue los detalles del rol a la sección `mapRoles` del `ConfigMap`, en `data`. Agregue esta sección si no existe todavía en el archivo. Cada entrada admite los siguientes parámetros:
+ **rolearn**: ARN del rol de IAM que se va a agregar. Este valor no puede incluir una ruta. Por ejemplo, no puede especificar un ARN como ` arn:aws:iam::111122223333:role/my-team/developers/role-name `. El ARN se debe ` arn:aws:iam::111122223333:role/role-name ` en su lugar.
+ **username**: nombre del usuario de Kubernetes al que se mapea el rol de IAM.
+ **groups** (grupos): el grupo o la lista de grupos de Kubernetes a los que asignar el rol. El grupo puede ser un grupo predeterminado o un grupo especificado en un `clusterrolebinding` o `rolebinding`. Para obtener más información, consulte [Default roles and role bindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) en la documentación de Kubernetes.
+ **Para agregar un usuario de IAM:** Según las [prácticas recomendadas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html), se recomienda conceder permisos a los roles en lugar de a los usuarios. Agregue los detalles del usuario a la sección `mapUsers` del `ConfigMap`, en `data`. Agregue esta sección si no existe todavía en el archivo. Cada entrada admite los siguientes parámetros:
+ **userarn**: ARN del usuario de IAM que se va a agregar.
+ **username**: nombre de usuario dentro de Kubernetes al que se mapea el usuario de IAM.
+ **groups** (grupos): el grupo o la lista de grupos de Kubernetes a los que asignar el usuario. El grupo puede ser un grupo predeterminado o un grupo especificado en un `clusterrolebinding` o `rolebinding`. Para obtener más información, consulte [Default roles and role bindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) en la documentación de Kubernetes.
1. Por ejemplo, el siguiente bloque YAML contiene:
+ Una sección de `mapRoles` que asigna la instancia de nodos de IAM a grupos de Kubernetes para que los nodos puedan registrarse en el clúster y el rol de IAM `my-console-viewer-role` que se asigna a un grupo de Kubernetes que puede ver todos los recursos de Kubernetes para todos los clústeres. Para obtener una lista de los permisos de grupo de IAM y Kubernetes necesarios para el rol de IAM de `my-console-viewer-role`, consulte [Permisos necesarios](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
+ Una sección de `mapUsers` que asigna el usuario de IAM `admin` desde la cuenta de valor predeterminado de AWS al grupo Kubernetes `system:masters` y el usuario `my-user` de otra cuenta AWS asignada a un grupo de Kubernetes que puede ver los recursos de Kubernetes para un espacio de nombres específico. Para obtener una lista de los permisos de grupo de IAM y Kubernetes necesarios para el usuario de IAM de `my-user`, consulte [Permisos necesarios](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
Agregue o quite líneas según sea necesario y reemplace todos los valores de ejemplo con sus propios valores.
```
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::111122223333:role/my-role
username: system:node:{{EC2PrivateDNSName}}
- groups:
- eks-console-dashboard-full-access-group
rolearn: arn:aws:iam::111122223333:role/my-console-viewer-role
username: my-console-viewer-role
mapUsers: |
- groups:
- system:masters
userarn: arn:aws:iam::111122223333:user/admin
username: admin
- groups:
- eks-console-dashboard-restricted-access-group
userarn: arn:aws:iam::444455556666:user/my-user
username: my-user
```
1. Guarde el archivo y salga del editor de texto.
## Aplique el `ConfigMap` de `aws-auth` en su clúster
El `ConfigMap` de `aws-auth` se crea y aplica de forma automática al clúster cuando crea un grupo de nodos administrados o cuando crea un grupo de nodos mediante `eksctl`. En un principio, se crea para permitir que los nodos se unan al clúster, pero también se utiliza este `ConfigMap` para agregar acceso de control de acceso basado en roles (RBAC) a las entidades principales de IAM. Si ha lanzado nodos autoadministrados y no ha aplicado el `ConfigMap` de `aws-auth` al clúster, puede hacerlo con el siguiente procedimiento.
1. Verifique si ya ha aplicado el `ConfigMap` de `aws-auth`.
```
kubectl describe configmap -n kube-system aws-auth
```
Si recibe un error con estado “`Error from server (NotFound): configmaps "aws-auth" not found`”, continúe con los siguientes pasos para aplicar el `ConfigMap` estándar.
1. Descargue, edite y aplique el mapa de configuración del autenticador de AWS.
1. Descargue el mapa de configuración.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
```
1. En el archivo `aws-auth-cm.yaml`, establezca el `rolearn` para el Nombre de recurso de Amazon (ARN) o el rol de IAM asociado con sus nodos. Puede hacerlo con un editor de texto o puede reemplazar *my-node-instance-role* y ejecutar el siguiente comando:
```
sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml
```
No modifique ninguna otra línea de este archivo.
**importante**
El ARN de rol no puede incluir una ruta como `role/my-team/developers/my-role`. El formato del ARN debe ser ` arn:aws:iam::111122223333:role/my-role `. En este ejemplo, se debe eliminar `my-team/developers/`.
Puede inspeccionar las salidas de la pila de AWS CloudFormation para los grupos de nodos y buscar los siguientes valores:
+ **InstanceRoleARN**: para grupos de nodos que se crearon con `eksctl`
+ **NodeInstanceRole**: para grupos de nodos que se crearon con plantillas de Amazon EKS incluidas en AWS CloudFormation en la Consola de administración de AWS
1. Aplique la configuración. Este comando puede tardar varios minutos en finalizar.
```
kubectl apply -f aws-auth-cm.yaml
```
**nota**
Si recibe cualquier error de tipo de recurso o autorización, consulte [Acceso denegado o no autorizado (`kubectl`)](troubleshooting.md#unauthorized) en el tema de solución de problemas.
1. Observe el estado de los nodos y espere a que aparezca el estado `Ready`.
```
kubectl get nodes --watch
```
Ingrese `Ctrl`\$1`C` para obtener un símbolo del intérprete de comandos.
# Concesión de acceso a Kubernetes con un proveedor de OIDC externo para los usuarios
Amazon EKS admite la utilización de proveedores de identidad OpenID Connect (OIDC) como método para autenticar usuarios en su clúster. Los proveedores de identidad de OIDC se pueden utilizar con AWS Identity and Access Management (IAM) o como una alternativa de IAM. Para obtener más información acerca del uso de IAM, consulte [Concesión a los usuarios y roles de IAM de acceso a las API de Kubernetes](grant-k8s-access.md). Después de configurar la autenticación de su clúster, puede crear`roles` y `clusterroles` de Kubernetes para asignar permisos a los roles y, a continuación, vincular los roles a las identidades con `rolebindings` y `clusterrolebindings` de Kubernetes. Para obtener más información, consulte [Utilización de la autorización de RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) en la documentación de Kubernetes.
+ Puede asociar un proveedor de identidad de OIDC al clúster.
+ Kubernetes no proporciona un proveedor de identidad de OIDC. Puede utilizar un proveedor de identidad de OIDC público existente o puede ejecutar su propio proveedor de identidad. Para obtener una lista de proveedores certificados, consulte [Certificación de OpenID](https://openid.net/certification/) en la página web de OpenID.
+ La URL del emisor del proveedor de identidad de OIDC debe ser accesible de manera pública para que Amazon EKS pueda descubrir las claves de firma. Amazon EKS no admite proveedores de identidad de OIDC con certificados autofirmados.
+ No es posible desactivar el autenticador de IAM en el clúster, ya que aún es necesario para unir los nodos al clúster.
+ Un clúster de Amazon EKS aún debe crearse mediante una [entidad principal de AWS IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), en lugar de un usuario de proveedor de identidad de OIDC. Esto se debe a que el creador del clúster interactúa con las API de Amazon EKS, en lugar de con las API de Kubernetes.
+ Los usuarios autenticados por el proveedor de identidad de OIDC aparecen en el registro de auditoría del clúster si los Registros de CloudWatch están activados para el plano de control. Para obtener más información, consulte [Habilitación o deshabilitación de los registros del plano de control](control-plane-logs.md#enabling-control-plane-log-export).
+ No puede iniciar sesión en la Consola de administración de AWS con una cuenta de un proveedor de OIDC. Solo puede [Visualización de los recursos de Kubernetes en la Consola de administración de AWS](view-kubernetes-resources.md) iniciando sesión en la Consola de administración de AWS con una cuenta de AWS Identity and Access Management (IAM).
## Asociar un proveedor de identidad de OIDC
Antes de asociar un proveedor de identidad de OIDC al clúster, necesita la siguiente información de su proveedor:
**URL del emisor**
La URL del proveedor de identidad de OIDC que permite al servidor de API descubrir claves de firma públicas para verificar tokens. La URL debe comenzar con `https://` y debe corresponder a la afirmación `iss` en los tokens de ID de OIDC del proveedor. De acuerdo con el estándar de OIDC, los componentes de ruta están permitidos, pero los parámetros de consulta no lo están. Normalmente, la URL consta de solo un nombre de host, como `https://server.example.org` o `https://example.com`. Esta URL debe apuntar al siguiente nivel a `.well-known/openid-configuration` y debe ser de acceso público a través de Internet.
**ID de cliente (también conocido como *público*)**
El ID de la aplicación cliente que realiza solicitudes de autenticación al proveedor de identidad de OIDC.
Puede asociar un proveedor de identidad mediante `eksctl` o la Consola de administración de AWS.
### Asociación de un proveedor de identidad mediante eksctl
1. Cree un archivo denominado `associate-identity-provider.yaml` con el siguiente contenido. Sustituya los valores de ejemplo por sus propios valores. Los valores de la sección `identityProviders` se obtienen de su proveedor de identidad de OIDC. Los valores solo son necesarios para la configuración de `name`, `type`, `issuerUrl` y `clientId` en `identityProviders`.
```
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: your-region-code
identityProviders:
- name: my-provider
type: oidc
issuerUrl: https://example.com
clientId: kubernetes
usernameClaim: email
usernamePrefix: my-username-prefix
groupsClaim: my-claim
groupsPrefix: my-groups-prefix
requiredClaims:
string: string
tags:
env: dev
```
**importante**
No especifique `system:` o cualquier parte de esa cadena para `groupsPrefix` o `usernamePrefix`.
1. Cree el proveedor.
```
eksctl associate identityprovider -f associate-identity-provider.yaml
```
1. Para utilizar `kubectl` a fin de que trabaje con su clúster y proveedor de identidad de OIDC, consulte [Using kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl) en la documentación de Kubernetes.
### Puede asociar un proveedor de identidad mediante la consola de AWS
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Seleccione el clúster y, a continuación, seleccione la pestaña **Acceso**.
1. En la sección **Proveedores de identidad OIDC**, seleccione \$1Asociar proveedor de identidad\$1.
1. En la página **Associate OIDC Identity Provider** (Asociar proveedor de identidad de OIDC), ingrese o seleccione las siguientes opciones y, a continuación, seleccione **Associate** (Asociar).
+ En **Name (Nombre)**, ingrese un nombre único para el proveedor.
+ En **Issuer URL** (URL del emisor), ingrese la URL del proveedor. Debe ser posible el acceso a esta URL a través de Internet.
+ En **ID de cliente**, ingrese el ID de cliente del proveedor de identidad de OIDC (también conocido como **audiencia**).
+ En **Username claim** (Afirmación de nombre de usuario), ingrese la afirmación que desea utilizar como nombre de usuario.
+ En **Afirmación de grupo**, ingrese la afirmación que desea utilizar como grupo del usuario.
+ (Opcional) Seleccione **Opciones avanzadas**, e ingrese o seleccione la siguiente información.
+ **Username prefix** (Prefijo de nombre de usuario): ingrese un prefijo para anteponer a las afirmaciones de nombre de usuario. El prefijo se antepone a las afirmaciones de nombre de usuario para evitar conflictos con nombres existentes. Si no proporciona un valor y el nombre de usuario es un valor distinto de `email`, el prefijo se establece de forma predeterminada en el valor de **Issuer URL (URL del emisor)**. Puede utilizar el valor ` -` para desactivar todos los prefijos. No especifique `system:` o cualquier parte de esa cadena.
+ **Groups prefix** (Prefijo de grupos): ingrese un prefijo para anteponer a las afirmaciones de grupos. El prefijo se antepone a las afirmaciones de grupo para evitar conflictos con nombres existentes (por ejemplo, ` system: groups`). Por ejemplo, el valor `oidc:` crea nombres de grupo como `oidc:engineering` y `oidc:infra`. No especifique `system:` o cualquier parte de esa cadena.
+ **Required claims** (Afirmaciones requeridas): seleccione **Add claim** (Agregar afirmación) e ingrese uno o más pares de valor de clave que describan las afirmaciones requeridas en el token del ID de cliente. Los pares describen las contestaciones requeridas en el token del ID. Si se establece, se verifica que cada afirmación esté presente en el token del ID con un valor coincidente.
1. Para utilizar `kubectl` a fin de que trabaje con su clúster y proveedor de identidad de OIDC, consulte [Using kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl) en la documentación de Kubernetes.
## Política de IAM de ejemplo
Si desea evitar que un proveedor de identidad de OIDC se asocie a un clúster, cree y asocie la siguiente política de IAM a las cuentas de IAM de sus administradores de Amazon EKS. Para obtener más información, consulte [Cómo crear políticas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) y [Cómo agregar permisos de identidades de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console) en la *Guía del usuario de IAM* y [Acciones](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerserviceforkubernetes.html) en la Referencia de autorización de servicios.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "denyOIDC",
"Effect": "Deny",
"Action": [
"eks:AssociateIdentityProviderConfig"
],
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/*"
},
{
"Sid": "eksAdmin",
"Effect": "Allow",
"Action": [
"eks:*"
],
"Resource": "*"
}
]
}
```
La siguiente política de ejemplo permite la asociación de proveedores de identidad de OIDC si el `clientID` es `kubernetes` y la `issuerUrl` es `https://cognito-idp.us-west-2amazonaws.com/*`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCognitoOnly",
"Effect": "Deny",
"Action": "eks:AssociateIdentityProviderConfig",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-instance",
"Condition": {
"StringNotLikeIfExists": {
"eks:issuerUrl": "https://cognito-idp.us-west-2.amazonaws.com/*"
}
}
},
{
"Sid": "DenyOtherClients",
"Effect": "Deny",
"Action": "eks:AssociateIdentityProviderConfig",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-instance",
"Condition": {
"StringNotEquals": {
"eks:clientId": "kubernetes"
}
}
},
{
"Sid": "AllowOthers",
"Effect": "Allow",
"Action": "eks:*",
"Resource": "*"
}
]
}
```
# Desasociar un proveedor de identidad de OIDC del clúster
Si desasocia un proveedor de identidad de OIDC del clúster, los usuarios incluidos en el proveedor ya no podrán acceder al clúster. Sin embargo, sigue teniendo acceso al clúster con las [entidades principales de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal).
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. En la sección **OIDC Identity Providers** (Proveedores de identidad de OIDC), seleccione **Disassociate** (Desasociar), ingrese el nombre del proveedor de identidad y, a continuación, seleccione `Disassociate`.
# Visualización de los recursos de Kubernetes en la Consola de administración de AWS
Puede ver los recursos de Kubernetes implementados en su clúster con la Consola de administración de AWS. No puede ver los recursos de Kubernetes con la AWS CLI o [eksctl](https://eksctl.io/). Para ver los recursos de Kubernetes mediante una herramienta de línea de comandos, utilice [kubectl](install-kubectl.md).
**nota**
Para ver la pestaña **Recursos** y la sección **Nodos** de la pestaña **Computación** de la Consola de administración de AWS, la [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que utilice debe tener permisos de IAM y Kubernetes específicos. Para obtener más información, consulte [Permisos necesarios](#view-kubernetes-resources-permissions).
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. En la lista **Clusters** (Clústeres), seleccione el clúster que contiene los recursos de Kubernetes que desea ver.
1. Seleccione la pestaña **Recursos**.
1. Seleccione un grupo de **Tipo de recurso** del que desea ver los recursos, como **Cargas de trabajo**. Aparece una lista de los tipos de recursos de ese grupo.
1. Seleccione un tipo de recurso, como **Deployments** (Implementaciones), en el grupo **Cargas de trabajo**. Puede ver una descripción del tipo de recurso, un enlace a la documentación de Kubernetes para obtener más información sobre el tipo de recurso y una lista de los recursos de ese tipo que se implementan en el clúster. Si la lista está vacía, no hay recursos de ese tipo implementado en el clúster.
1. Seleccione un recurso para ver más información acerca de una instantánea. Pruebe los siguientes ejemplos:
+ Seleccione el grupo **Cargas de trabajo**, seleccione el tipo de recurso de **Implementaciones** y seleccione el recurso **coredns**. Al seleccionar un recurso, se encuentra en **Vista estructurada**, de forma predeterminada. Para algunos tipos de recursos, verá una sección de **Pods** en **Vista estructurada**. En esta sección se muestran los pods administrados por la carga de trabajo. Puede seleccionar cualquier pod de la lista para ver información acerca del pod. No todos los tipos de recursos muestran información en **Structured View** (Vista estructurada). Si selecciona **Raw view** (Vista sin procesar) en la esquina superior derecha de la página del recurso, verá la respuesta JSON completa de la API de Kubernetes para el recurso.
+ Seleccione el grupo **Cluster** (Clústeres) y, a continuación, seleccione el tipo de recursos **Nodes** (Nodos). Aparece una lista de todos los nodos del clúster. Los nodos pueden ser cualquier [tipo de nodo de Amazon EKS](eks-compute.md). Esta es la misma lista que ve en la sección **Nodos** al seleccionar la pestaña **Informática** de su clúster. Seleccione un recurso de nodo de la lista. En **Vista estructurada**, también ve una sección de **Pods**. En esta sección se muestran todos los pods que se ejecutan en el nodo.
## Permisos necesarios
Para ver la pestaña **Recursos** y la sección **Nodos** de la pestaña **Computación** de la Consola de administración de AWS, la [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que utilice debe tener permisos mínimos de IAM y Kubernetes específicos. Debe tener configurados correctamente tanto los permisos de IAM como los de control de acceso basado en roles de Kubernetes. Complete los siguientes pasos para asignar los permisos necesarios a las entidades principales de IAM.
1. Asegúrese de que la `eks:AccessKubernetesApi` y otros permisos de IAM necesarios para ver los recursos de Kubernetes estén asignados a la entidad principal de IAM que esté utilizando. Para obtener más información acerca de cómo editar los permisos para una entidad principal de IAM, consulte [Control del acceso para las entidades principales de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html#access_controlling-principals) en la Guía del usuario de IAM. Para obtener más información acerca de cómo editar los permisos de un rol, consulte [Modificación de una política de permisos de rol (consola)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html#roles-modify_permissions-policy) en la Guía del usuario de IAM.
En la siguiente política de ejemplo se incluyen los permisos necesarios para que una entidad principal vea los recursos de Kubernetes de todos los clústeres de su cuenta. Reemplace *111122223333* por su ID de cuenta de AWS.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:ListFargateProfiles",
"eks:DescribeNodegroup",
"eks:ListNodegroups",
"eks:ListUpdates",
"eks:AccessKubernetesApi",
"eks:ListAddons",
"eks:DescribeCluster",
"eks:DescribeAddonVersions",
"eks:ListClusters",
"eks:ListIdentityProviderConfigs",
"iam:ListRoles"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ssm:GetParameter",
"Resource": "arn:aws:ssm:*:111122223333:parameter/*"
}
]
}
```
Para ver los nodos de los [clústeres conectados](eks-connector.md), el [rol de IAM del conector de Amazon EKS](connector-iam-role.md) debería poder suplantar a la entidad principal en el clúster. Esto permite que [Amazon EKS Connector](eks-connector.md) asigne la entidad principal a un usuario de Kubernetes.
1. Configure los permisos de control de acceso basado en roles de Kubernetes mediante las entradas de acceso de EKS.
**¿Qué son las entradas de acceso de EKS?**
Las entradas de acceso de EKS son una forma simplificada de conceder a las entidades principales de IAM (usuarios y roles) acceso al clúster de Kubernetes. En lugar de administrar manualmente los recursos de control de acceso basado en roles de Kubernetes y el ConfigMap de `aws-auth`, las entradas de acceso gestionan automáticamente la asignación entre los permisos de IAM y los de Kubernetes mediante políticas administradas proporcionadas por AWS. Para obtener información detallada sobre las entradas de acceso, consulte [Concesión de acceso para los usuarios de IAM a las entradas de acceso de Kubernetes con EKS](access-entries.md). Para obtener información sobre las políticas de acceso disponibles y sus permisos, consulte [Permisos de políticas de acceso](https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html).
Puede asociar permisos de Kubernetes a entradas de acceso dos maneras:
+ **Uso de una política de acceso:** las políticas de acceso son plantillas predefinidas de permisos de Kubernetes mantenidas por AWS. Estas proporcionan conjuntos de permisos estandarizados para casos de uso comunes.
+ **Hacer referencia a un grupo de Kubernetes:** si asocia una identidad de IAM con un grupo de Kubernetes, puede crear recursos de Kubernetes que concedan permisos a ese grupo. Para obtener más información, consulte [Utilización de la autorización de RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) en la documentación de Kubernetes.
1. Cree una entrada de acceso para la entidad principal de IAM mediante la CLI de AWS. Reemplace *my-cluster* por el nombre de su clúster. Reemplace *111122223333* por el ID de su cuenta.
```
aws eks create-access-entry \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role
```
Un ejemplo de salida sería el siguiente.
```
{
"accessEntry": {
"clusterName": "my-cluster",
"principalArn": "arn:aws:iam::111122223333:role/my-console-viewer-role",
"kubernetesGroups": [],
"accessEntryArn": "arn:aws:eks:region-code:111122223333:access-entry/my-cluster/role/111122223333/my-console-viewer-role/abc12345-1234-1234-1234-123456789012",
"createdAt": "2024-03-15T10:30:45.123000-07:00",
"modifiedAt": "2024-03-15T10:30:45.123000-07:00",
"tags": {},
"username": "arn:aws:iam::111122223333:role/my-console-viewer-role",
"type": "STANDARD"
}
}
```
1. Asocie una política a la entrada de acceso. Para ver recursos de Kubernetes, utilice la `AmazonEKSViewPolicy`:
```
aws eks associate-access-policy \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=cluster
```
Un ejemplo de salida sería el siguiente.
```
{
"clusterName": "my-cluster",
"principalArn": "arn:aws:iam::111122223333:role/my-console-viewer-role",
"associatedAt": "2024-03-15T10:31:15.456000-07:00"
}
```
Para acceso específico a un espacio de nombres, puede delimitar la política a espacios de nombres específicos:
```
aws eks associate-access-policy \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=namespace,namespaces=default,kube-system
```
1. Verifique que la entrada de acceso se haya creado correctamente:
```
aws eks describe-access-entry \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role
```
1. Enumere las políticas asociadas para confirmar la asociación de la política:
```
aws eks list-associated-access-policies \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role
```
Un ejemplo de salida sería el siguiente.
```
{
"associatedAccessPolicies": [
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
"accessScope": {
"type": "cluster"
},
"associatedAt": "2024-03-15T10:31:15.456000-07:00",
"modifiedAt": "2024-03-15T10:31:15.456000-07:00"
}
]
}
```
## Visibilidad en CloudTrail
Cuando visualice recursos de Kubernetes, verá el siguiente nombre de operación en los registros de CloudTrail:
+ `AccessKubernetesApi`: cuando se leen o visualizan recursos
Este evento de CloudTrail proporciona un registro de auditoría del acceso de lectura a los recursos de Kubernetes.
**nota**
Este nombre de operación aparece en los registros de CloudTrail únicamente con fines de auditoría. No es una acción de IAM y no se puede utilizar en declaraciones de políticas de IAM. Para controlar el acceso de lectura a los recursos de Kubernetes mediante políticas de IAM, utilice el permiso `eks:AccessKubernetesApi`, como se indica en la sección [Permisos necesarios](#view-kubernetes-resources-permissions).
# Concesión a los servicios de AWS de acceso de escritura a las API de Kubernetes
## Permisos necesarios
Para permitir que los servicios de AWS realicen operaciones de escritura en los recursos de Kubernetes del clúster de Amazon EKS, debe conceder tanto el permiso `eks:AccessKubernetesApi` como el `eks:MutateViaKubernetesApi` de IAM.
Por ejemplo, Amazon SageMaker HyperPod utiliza estos permisos para habilitar la implementación de modelos desde Amazon SageMaker AI Studio. Para obtener más información, consulte [Configuración de permisos opcionales del SDK de JavaScript](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-model-deployment-setup.html#sagemaker-hyperpod-model-deployment-setup-optional-js) en la Guía para desarrolladores de Amazon SageMaker AI.
**importante**
Las operaciones de escritura, como crear, actualizar y eliminar, requieren ambos permisos; si falta alguno de ellos, las operaciones de escritura fallarán.
## Visibilidad en CloudTrail
Mientras realiza operaciones de escritura en recursos de Kubernetes, verá nombres de operaciones específicos en los registros de CloudTrail:
+ `createKubernetesObject`: cuando se crean nuevos recursos
+ `updateKubernetesObject`: cuando se modifican recursos existentes
+ `deleteKubernetesObject`: cuando se eliminan recursos
Estos eventos de CloudTrail proporcionan registros de auditoría detallados de todas las modificaciones realizadas en los recursos de Kubernetes.
**nota**
Estos nombres de operaciones aparecen en los registros de CloudTrail únicamente con fines de auditoría. No son acciones de IAM y no se pueden utilizar en declaraciones de políticas de IAM. Para controlar el acceso de escritura a los recursos de Kubernetes mediante políticas de IAM, utilice el permiso `eks:MutateViaKubernetesApi` como se muestra en la sección [Permisos necesarios](#mutate-kubernetes-resources-permissions).
# Conexión de kubectl a un clúster de EKS mediante la creación de un archivo kubeconfig
**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.
En este tema, creará un archivo `kubeconfig` para su clúster (o actualizará uno existente).
La herramienta de línea de comandos `kubectl` usa la información de configuración en los archivos `kubeconfig` para comunicarse con el servidor de API de un clúster. Para obtener más información, consulte [Organizing Cluster Access Using kubeconfig Files](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) en la documentación de Kubernetes.
Amazon EKS usa el comando `aws eks get-token` con `kubectl` para la autenticación del clúster. De forma predeterminada, la CLI de AWS utiliza las mismas credenciales que se devuelven con el siguiente comando:
```
aws sts get-caller-identity
```
+ Un clúster existente de Amazon EKS. Para implementar uno, consulte [Introducción a Amazon EKS](getting-started.md).
+ 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).
+ 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*.
+ Un rol o usuario de IAM con permisos para utilizar la acción de API `eks:DescribeCluster` en el clúster que especifique. Para obtener más información, consulte [Ejemplos de políticas de Amazon EKS basadas en identidades](security-iam-id-based-policy-examples.md). Si utiliza una identidad de su propio proveedor de OpenID Connect para acceder al clúster, consulte [Using kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl) en la documentación de Kubernetes para crear o actualizar el archivo de `kube config`.
## Crear el archivo `kubeconfig` de forma automática
+ La versión `2.12.3` o posterior, o bien, la versión `1.27.160` o posterior de la Interfaz de la línea de comandos de AWS (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*.
+ Permiso para usar la acción de API `eks:DescribeCluster` en el clúster que especifique. Para obtener más información, consulte [Ejemplos de políticas de Amazon EKS basadas en identidades](security-iam-id-based-policy-examples.md).
1. Creación o actualización de un archivo de `kubeconfig` para el clúster. Reemplace *region-code* por la región de AWS donde creó el clúster y *my-cluster* por el nombre de su clúster.
```
aws eks update-kubeconfig --region region-code --name my-cluster
```
De forma predeterminada, el archivo de configuración resultante se crea en la ruta de `kubeconfig` predeterminada (`.kube`) en el directorio de inicio o en combinación con un archivo `config` existente en dicha ubicación. Puede especificar otra ruta con la opción `--kubeconfig`.
Puede especificar un ARN de rol de IAM con la opción `--role-arn` para utilizar en la autenticación al emitir comandos `kubectl`. De lo contrario, se utilizará la [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) de la CLI predeterminada o la cadena de credencial del SDK de AWS. Puede ver su identidad de la CLI o el SDK predeterminados de AWS ejecutando el comando `aws sts get-caller-identity`.
Para ver todas las opciones disponibles, ejecute el comando `aws eks update-kubeconfig help` o consulte [update-kubeconfig](https://docs.aws.amazon.com/cli/latest/reference/eks/update-kubeconfig.html) en la *Referencia de los comandos de la CLI de AWS*.
1. Pruebe la configuración.
```
kubectl get svc
```
Un ejemplo de salida sería el siguiente.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/kubernetes ClusterIP 10.100.0.1 443/TCP 1m
```
Si recibe cualquier error de tipo de recurso o autorización, consulte [Acceso denegado o no autorizado (`kubectl`)](troubleshooting.md#unauthorized) en el tema de solución de problemas.
# Concesión de acceso a las cargas de trabajo de Kubernetes a AWS mediante las cuentas de servicio de Kubernetes
[Administración de cuentas de servicio](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin)[Roles de IAM para cuentas de servicio](iam-roles-for-service-accounts.md)[Más información sobre cómo Pod Identity de EKS concede a los pods acceso a los servicios de AWS](pod-identities.md)
## Tokens de cuenta de servicio
La característica [BoundServiceAccountTokenVolume](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume) está habilitada de forma predeterminada en las versiones de Kubernetes. Esta función mejora la seguridad de los tokens de cuenta de servicio al permitir que las cargas de trabajo se ejecuten en Kubernetes para solicitar tokens web JSON que estén vinculados a la audiencia, la hora y la clave. Los tokens de cuenta de servicio tienen una caducidad de una hora. En versiones anteriores de Kubernetes, los tokens no tenían caducidad. Esto significa que los clientes que confían en estos tokens deben actualizar los tokens en una hora. Los siguientes ejemplos [SDK de cliente de Kubernetes](https://kubernetes.io/docs/reference/using-api/client-libraries/) actualizan los tokens automáticamente dentro del plazo requerido:
+ Versión de Go `0.15.7` y posteriores
+ Versión de Python `12.0.0` y posteriores
+ Versión de Java `9.0.0` y posterior
+ Versión de JavaScript `0.10.3` y posterior
+ Rama de Ruby `master`
+ Versión de Haskell `0.3.0.0`
+ Versión `7.0.5` y posteriores de C\$1
Si su carga de trabajo utiliza una versión de cliente anterior, debe actualizarla. Para permitir una migración fluida de los clientes a los tokens de cuenta de servicio con límite de tiempo más nuevos, Kubernetes agrega un periodo de vencimiento extendido al token de cuenta de servicio durante la hora predeterminada. Para los clústeres de Amazon EKS, el período de caducidad extendido es de 90 días. El servidor de API de Kubernetes de los clústeres de Amazon EKS rechaza solicitudes con tokens de más de 90 días de antigüedad. Le recomendamos que compruebe sus aplicaciones y sus dependencias para asegurarse de que los SDK de cliente de Kubernetes son iguales o posteriores a las versiones indicadas anteriormente.
Cuando el servidor API recibe solicitudes con tokens de más de una hora de antigüedad, anota el evento de registro de auditoría de la API con `annotations.authentication.k8s.io/stale-token`. El valor de la anotación es similar al siguiente ejemplo:
```
subject: system:serviceaccount:common:fluent-bit, seconds after warning threshold: 4185802.
```
Si el clúster tiene un [registro de plano de control](control-plane-logs.md) habilitado, entonces las anotaciones se encuentran en los registros de auditoría. Puede utilizar la siguiente consulta de [Información de registros de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) para identificar todos los pods del clúster de Amazon EKS que utilizan tokens obsoletos:
```
fields @timestamp
|filter @logStream like /kube-apiserver-audit/
|filter @message like /seconds after warning threshold/
|parse @message "subject: *, seconds after warning threshold:*\"" as subject, elapsedtime
```
El `subject` hace referencia a la cuenta de servicio que utilizó el pod. El `elapsedtime` indica el tiempo transcurrido (en segundos) tras leer el último token. Las solicitudes al servidor API se denegan cuando el `elapsedtime` supera los 90 días (7 776 000 segundos). Debe actualizar de forma proactiva el SKD del cliente de Kubernetes de las aplicaciones para utilizar una de las versiones enumeradas anteriormente que actualiza automáticamente el token. Si el token de cuenta de servicio utilizado dura casi 90 días y no tiene tiempo suficiente para actualizar las versiones del SDK de cliente antes de que el token caduque, puede terminar los pods existentes y crear otros nuevos. Esto da como resultado la reactivación del token de la cuenta de servicio, lo que le da 90 días adicionales para actualizar los SDK de la versión de cliente.
Si el pod forma parte de una implementación, la forma sugerida de finalizar los pods y mantener la alta disponibilidad es efectuar un despliegue con el siguiente comando. Reemplace *my-deployment* con el nombre de la implementación.
```
kubectl rollout restart deployment/my-deployment
```
## Complementos de clúster
Los siguientes complementos de clúster se han actualizado para utilizar los SDK del cliente de Kubernetes que reactivan automáticamente los tokens de cuentas de servicio. Recomendamos asegurarse de que las versiones enumeradas, o versiones posteriores, estén instaladas en su clúster.
+ Versión `1.8.0` y posteriores de los complementos auxiliares de métricas y CNI de Amazon VPC para Kubernetes. Para comprobar su versión actual o actualizarla, consulte [Asignación de direcciones IP a pods con CNI de Amazon VPC](managing-vpc-cni.md) y [cni-metrics-helper](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/cmd/cni-metrics-helper/README.md).
+ Versión de CoreDNS `1.8.4` y posteriores. Para comprobar su versión actual o actualizarla, consulte [Administración de CoredNS para DNS en clústeres de Amazon EKS](managing-coredns.md).
+ Versión del Controlador del equilibrador de carga de AWS `2.0.0` y posteriores. Para comprobar su versión actual o actualizarla, consulte [Enrutamiento del tráfico de internet con el controlador del equilibrador de carga de AWS](aws-load-balancer-controller.md).
+ Una versión actual de `kube-proxy`. Para comprobar su versión actual o actualizarla, consulte [Administración de `kube-proxy` en clústeres de Amazon EKS](managing-kube-proxy.md).
+ AWS para Fluent Bit versión `2.25.0` o posterior. Para actualizar la versión actual, consulte [Releases](https://github.com/aws/aws-for-fluent-bit/releases) (Lanzamientos) en GitHub.
+ Versión de imagen de Fluentd [1.14.6-1.2](https://hub.docker.com/r/fluent/fluentd/tags?page=1&name=v1.14.6-1.2) o posterior y versión del complemento de filtro de Fluentd para metadatos de Kubernetes [2.11.1](https://rubygems.org/gems/fluent-plugin-kubernetes_metadata_filter/versions/2.11.1) o posterior.
## Concesión de permisos a AWS Identity and Access Management a cargas de trabajo en clústeres de Amazon Elastic Kubernetes Service
Amazon EKS ofrece dos formas de conceder a AWS Identity and Access Management permisos a las cargas de trabajo que se ejecutan en los clústeres de Amazon EKS: los *roles de IAM para cuentas de servicio* y las *identidades de Pod de EKS*.
**Roles de IAM para cuentas de servicio**
*Los roles de IAM para cuentas de servicio (IRSA)* configuran las aplicaciones de Kubernetes que se ejecutan en AWS con permisos de IAM detallados para acceder a otros recursos de AWS, como los buckets de Amazon S3, las tablas de Amazon DynamoDB y más. Puede ejecutar varias aplicaciones juntas en el mismo clúster de Amazon EKS y asegurarse de que cada aplicación tenga solo el conjunto mínimo de permisos que necesita. IRSA se creó para admitir varias opciones de implementación de Kubernetes compatibles con AWS como Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service en AWS y clústeres de Kubernetes autoadministrados en instancias de Amazon EC2. Por lo tanto, IRSA se creó utilizando un servicio de AWS básico como IAM y no dependía directamente del servicio Amazon EKS ni de la API de EKS. Para obtener más información, consulte [Roles de IAM para cuentas de servicio](iam-roles-for-service-accounts.md).
**Pod Identities de EKS**
Pod Identity de EKS ofrece a los administradores de clústeres un flujo de trabajo simplificado para autenticar las aplicaciones con el fin de acceder a otros recursos de AWS, como los buckets de Amazon S3, las tablas de Amazon DynamoDB y más. Pod Identity de EKS está dedicada solo para EKS y, como resultado, simplifica la forma en que los administradores de clústeres pueden configurar las aplicaciones de Kubernetes para obtener permisos de IAM. Estos permisos ahora se pueden configurar fácilmente con menos pasos: directamente a través de Consola de administración de AWS, la API de EKS y la AWS CLI, no es necesario llevar a cabo ninguna acción dentro del clúster ni en ningún objeto de Kubernetes. Los administradores de clústeres no necesitan cambiar entre los servicios de EKS y de IAM, ni utilizar operaciones de IAM privilegiadas para configurar los permisos que requieren sus aplicaciones. Los roles de IAM ahora se pueden usar en varios clústeres sin necesidad de actualizar la política de confianza de roles al crear nuevos clústeres. Las credenciales de IAM proporcionadas por Pod Identity de EKS incluyen etiquetas de sesión de rol, con atributos como el nombre del clúster, el espacio de nombres y el nombre de la cuenta de servicio. Las etiquetas de sesión de rol permiten a los administradores crear un único rol que puede funcionar en todas las cuentas de servicio, ya que permiten el acceso a los recursos de AWS en función de las etiquetas coincidentes. Para obtener más información, consulte [Más información sobre cómo Pod Identity de EKS concede a los pods acceso a los servicios de AWS](pod-identities.md).
### Comparación de Pod Identity de EKS e IRSA
A un nivel alto, tanto Pod Identity de EKS como IRSA permiten conceder permisos de IAM a las aplicaciones que se ejecutan en clústeres de Kubernetes. Sin embargo, son fundamentalmente diferentes en cuanto a la forma de configurarlos, los límites admitidos y las características habilitadas. A continuación, comparamos algunos de los aspectos clave de ambas soluciones.
**nota**
AWS recomienda usar EKS Pod Identities para conceder acceso a los recursos de AWS de sus pods siempre que sea posible. Para obtener más información, consulte [Más información sobre cómo Pod Identity de EKS concede a los pods acceso a los servicios de AWS](pod-identities.md).
| Atributo | Pod Identity de EKS | IRSA |
| --- | --- | --- |
| Extensibilidad de roles | Debe configurar cada rol una vez para establecer una relación de confianza con el recién introducido `pods.eks.amazonaws.com` de director de servicio de Amazon EKS. Tras este único paso, no necesitará actualizar la política de confianza del rol cada vez que lo utilice en un clúster nuevo. | Debe actualizar la política de confianza del rol de IAM con el nuevo punto de conexión del proveedor de OIDC de clústeres de EKS cada vez que desee utilizar el rol en un clúster nuevo. |
| Escalabilidad de los clústeres | Pod Identity de EKS no requiere que los usuarios configuren un proveedor de IAM OIDC, por lo que este límite no se aplica. | Cada clúster de EKS tiene una URL de emisor de OpenID Connect (OIDC) asociada. Para usar IRSA, es necesario crear un proveedor de OpenID Connect único para cada clúster de EKS de IAM. IAM tiene un límite global predeterminado de 100 proveedores de OIDC para cada cuenta de AWS. Si planea tener más de 100 clústeres de EKS para cada cuenta de AWS con IRSA, alcanzará el límite de proveedores de OIDC de IAM. |
| Escalabilidad de roles | Pod Identity de EKS no exige que los usuarios definan la relación de confianza entre el rol de IAM y la cuenta de servicio en la política de confianza, por lo que este límite no se aplica. | En IRSA, usted define la relación de confianza entre un rol de IAM y una cuenta de servicio en la política de confianza del rol. De forma predeterminada, el tamaño de la política de confianza es `2048`. Esto significa que normalmente se pueden definir 4 relaciones de confianza en una sola política de confianza. Si bien puede aumentar el límite de duración de la política de confianza, normalmente está limitado a un máximo de 8 relaciones de confianza dentro de una sola política de confianza. |
| Uso de cuotas de la API de STS | EKS Pod Identity simplifica la entrega de credenciales de AWS a sus pods y no requiere que su código realice llamadas directamente al AWS Security Token Service (STS). El servicio de EKS gestiona la asunción de roles y entrega las credenciales a las aplicaciones escritas con el SDK de AWS en sus pods sin que estos se comuniquen con AWS STS ni utilicen la cuota de la API de STS. | En IRSA, las aplicaciones escritas con el SDK de AWS de sus pods utilizan tokens para llamar a la API de `AssumeRoleWithWebIdentity` de AWS Security Token Service (STS). Según la lógica del código del SDK de AWS, es posible que el código realice llamadas innecesarias a AWS STS y reciba errores de limitación. |
| Reutilización de roles | Las credenciales temporales de AWS STS proporcionadas por Pod Identity de EKS incluyen etiquetas de sesión de rol, como el nombre del clúster, el espacio de nombres y el nombre de la cuenta de servicio. Las etiquetas de sesión de rol permiten a los administradores crear un único rol de IAM que se puede usar con varias cuentas de servicio, con diferentes permisos efectivos, ya que permiten el acceso a los recursos de AWS basados en las etiquetas adjuntas a ellas. Esto también se conoce como control de acceso basado en atributos (ABAC). Para obtener más información, consulte [Concesión de acceso a los pods a los recursos de AWS en función de las etiquetas](pod-id-abac.md). | No se admiten etiquetas de sesión de AWS STS. Puede reutilizar un rol entre clústeres, pero cada pod recibe todos los permisos del rol. |
| Entornos compatibles | Pod Identity de EKS solo está disponible en Amazon EKS. | Se puede usar IRSA como Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service en AWS y clústeres de Kubernetes autoadministrados en instancias de Amazon EC2. |
| Versiones compatibles de EKS | Todas las versiones del clúster EKS compatibles. Para saber las versiones de la plataforma específicas, consulte [Versiones del clúster de Pod Identity de EKS](pod-identities.md#pod-id-cluster-versions). | Todas las versiones del clúster EKS compatibles. |
# Roles de IAM para cuentas de servicio
**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)
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
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
+ 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)
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 `` por su propio valor.
```
cluster_name=
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..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)
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
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
+ 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
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
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)
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)
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 <
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:
Mountable secrets: my-service-account-token-qqjfl
Tokens: my-service-account-token-qqjfl
[...]
```
## Siguientes pasos
+ [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
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 <
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
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
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
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
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
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.
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
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
**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
### Java
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
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
+ 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
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"}]}
```
# Más información sobre cómo Pod Identity de EKS concede a los pods acceso a los servicios de AWS
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.
*Pod Identities de 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. 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.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/aUjJSorBE70?rel=0)
Cada asociación de Pod Identity de EKS asigna un rol a una cuenta de servicio en un espacio de nombres del clúster especificado. Si tiene la misma aplicación en varios clústeres, puede crear asociaciones idénticas en cada clúster sin modificar la política de confianza del rol.
Si un pod usa una cuenta de servicio que tiene una asociación, Amazon EKS establece las variables de entorno en los contenedores del pod. Las variables de entorno configuran los SDK de AWS, incluida la AWS de CLI, para usar las credenciales de la Pod Identity de EKS.
## Ventajas de las Pod Identities de EKS
Las Pod Identities de EKS proporcionan 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 las credenciales de Pod Identity cuando estén habilitados.
+ **Auditabilidad:** El acceso y el registro de eventos está disponible a través de AWS CloudTrail para facilitar una auditoría retrospectiva.
**importante**
Los contenedores no funcionan como un límite de seguridad, y el uso de Pod Identity no cambia esto. 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.
Pod Identity de EKS es un método más sencillo que [Roles de IAM para cuentas de servicio](iam-roles-for-service-accounts.md), ya que no utiliza proveedores de identidad de OIDC. Pod Identity de EKS incluye las siguientes mejoras:
+ **Operaciones independientes**: en muchas organizaciones, la creación de proveedores de identidad de OIDC es una responsabilidad de equipos diferentes a la de administrar los clústeres de Kubernetes. Pod Identity de EKS tiene una clara separación de funciones, en donde toda la configuración de las asociaciones de Pod Identity de EKS se realiza en Amazon EKS y toda la configuración de los permisos de IAM se realiza en IAM.
+ **Reutilización**: La Pod Identity de EKS utiliza una única entidad principal de IAM en lugar de los principios independientes para cada clúster que utilizan los roles de IAM para cuentas de servicio. El administrador de IAM añade la siguiente entidad principal a la política de confianza de cualquier función para que Pod Identities de EKS puedan utilizarla.
```
"Principal": {
"Service": "pods.eks.amazonaws.com"
}
```
+ **Escalabilidad**: cada conjunto de credenciales temporales lo asume el servicio de autenticación de EKS en Pod Identity de EKS, en lugar de cada AWS SDK que se ejecuta en cada pod. A continuación, el agente de Pod Identity de Amazon EKS que se ejecuta en cada nodo emite las credenciales de los SDK. De este modo, la carga se reduce a una vez para cada nodo y no se duplica en cada pod. Para obtener más información del proceso, consulte [Descripción del funcionamiento de Pod Identity de EKS](pod-id-how-it-works.md).
Para obtener más información sobre cómo comparar las dos alternativas, consulte [Concesión de acceso a las cargas de trabajo de Kubernetes a AWS mediante las cuentas de servicio de Kubernetes](service-accounts.md).
## Información general de configuración de las Pod Identities de EKS
Siga estos procedimientos para activar Pod Identities de EKS:
1. [Configuración del agente de Pod Identity de Amazon EKS](pod-id-agent-setup.md): solo complete este procedimiento una vez para cada clúster. No necesita completar este paso si el modo automático de EKS está habilitado en el clúster.
1. [Asignación de un rol de IAM a una cuenta de servicio de Kubernetes](pod-id-association.md): complete este procedimiento para cada conjunto único de permisos que desee que tenga una aplicación.
1. [Configuración de pods para acceder a los servicios de AWS con cuentas de servicio](pod-id-configure-pods.md): complete este procedimiento para cada pod que necesite acceso a servicios de AWS.
1. [Uso de Pod Identity con el SDK de AWS](pod-id-minimum-sdk.md): confirme que la carga de trabajo utilice un SDK de AWS de una versión compatible y que utilice la cadena de credenciales predeterminada.
## Límites
+ Se admiten hasta 5000 asociaciones de EKS Pod Identity por clúster para asignar roles de IAM a cuentas de servicio de Kubernetes.
## Consideraciones
+ **Asociación de roles de IAM**: cada cuenta de servicio de Kubernetes en un clúster se puede asociar a un rol de IAM de la misma cuenta de AWS que el clúster. Para cambiar el rol, edite la asociación de EKS Pod Identity. Para el acceso entre cuentas, delegue el acceso al rol mediante los roles de IAM. Para obtener más información, consulte [Delegación del acceso entre cuentas de AWS mediante roles de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) en la *Guía del usuario de IAM*.
+ **Agente de EKS Pod Identity**: se requiere el agente de Pod Identity para utilizar EKS Pod Identity. El agente se ejecuta como un `DaemonSet` de Kubernetes en los nodos del clúster y proporciona credenciales solo a los pods del mismo nodo. Utiliza la `hostNetwork` del nodo y ocupa los puertos `80` y `2703` en la dirección local de enlace (`169.254.170.23` para IPv4, `[fd00:ec2::23]` para IPv6). Si IPv6 está deshabilitado en su clúster, deshabilite IPv6 para el agente de Pod Identity. Para obtener más información, consulte [Deshabilitar IPv6 en el agente de EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-config-ipv6.html).
+ **Consistencia eventual**: las asociaciones de EKS Pod Identity tienen consistencia final, con posibles demoras de varios segundos después de las llamadas a la API. Evite crear o actualizar asociaciones en rutas de código críticas y de alta disponibilidad. En cambio, realice estas acciones en rutinas de inicialización o configuración separadas y menos frecuentes. Para obtener más información, consulte [Grupos de seguridad por pod](https://docs.aws.amazon.com/eks/latest/best-practices/sgpp.html) en la *Guía de prácticas recomendadas de EKS*.
+ **Consideraciones sobre el proxy y el grupo de seguridad**: para los pods que utilizan un proxy, añada `169.254.170.23` (IPv4) y `[fd00:ec2::23]` (IPv6) a las variables de entorno de `no_proxy/NO_PROXY` para evitar que se produzcan errores en las solicitudes al agente de EKS Pod Identity. Si utiliza grupos de seguridad para pods con la CNI de AWS VPC, establezca el indicador `ENABLE_POD_ENI` en “true” y el indicador `POD_SECURITY_GROUP_ENFORCING_MODE` en “standard”. Para obtener más información, consulte [Asignación de los grupos de seguridad a pods individuales](https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html).
### Versiones del clúster de Pod Identity de EKS
Para usar EKS Pod Identity, el clúster debe tener una versión de la plataforma igual o posterior a la que se indica en la siguiente tabla, o una versión de Kubernetes posterior a las versiones que se muestran en la tabla. Para buscar la versión sugerida del Agente de Amazon EKS Pod Identity para una versión de Kubernetes, consulte [Comprobación de la compatibilidad de la versión del complemento de Amazon EKS con un clúster](addon-compat.md).
| Versión de Kubernetes | Versión de la plataforma |
| --- | --- |
| Versiones de Kubernetes no enumeradas | Todas las versiones de la plataforma compatibles |
| `1.28` | `eks.4` |
### Restricciones de Pod Identity de EKS
Pod Identities de EKS están disponibles en las siguientes ubicaciones:
+ Versiones del clúster de Amazon EKS enumeradas en el tema anterior [Versiones del clúster de Pod Identity de EKS](#pod-id-cluster-versions).
+ Nodos de trabajo del clúster que son instancias Linux Amazon EC2.
Pod Identities de EKS no están disponibles en las siguientes ubicaciones:
+ AWS Outposts.
+ Amazon EKS Anywhere.
+ Los clústeres de Kubernetes que se crean y ejecutan en Amazon EC2. Los componentes de Pod Identity de EKS solo están disponibles en Amazon EKS.
No puede usar Pod Identities de EKS con:
+ Pods que se ejecutan en cualquier lugar, excepto instancias Linux Amazon EC2. No se admiten los pods de Linux y Windows que se ejecutan en AWS Fargate (Fargate). No se admiten pods que se ejecutan en instancias Windows de Amazon EC2.
# Descripción del funcionamiento de Pod Identity de EKS
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.
En sus complementos, como los *complementos de Amazon EKS* y el controlador autoadministrado, los operadores y otros complementos, el autor debe actualizar el software para utilizar los SDK de AWS más recientes. Para ver la lista de compatibilidad entre Pod Identity de EKS y los complementos fabricados por Amazon EKS, consulte la sección anterior [Restricciones de Pod Identity de EKS](pod-identities.md#pod-id-restrictions).
## Uso de Identidades de pod de EKS en el código
En su código, puede usar los SDK de AWS para acceder a los servicios de AWS. El código se escribe 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 que se van a utilizar. Una vez que se ha comprobado que las credenciales son válidas, se detiene la búsqueda. Para obtener más información sobre las ubicaciones predeterminadas utilizadas, consulte la [cadena de proveedores de credenciales](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain) en la Guía de referencia de herramientas y SDK de AWS.
Se han agregado las Pod Identities de EKS al *proveedor de credenciales del contenedor*, que se busca en un paso de 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 una asociación de Pod Identity de EKS para la misma carga de trabajo. De esta forma, puede migrar de forma segura desde otros tipos de credenciales creando primero la asociación antes de eliminar las credenciales antiguas.
El proveedor de credenciales del contenedor proporciona credenciales temporales de un agente que se ejecuta en cada nodo. En Amazon EKS, el agente de Pod Identity de Amazon EKS y en Servicio de contenedor elástico de Amazon, el agente es el `amazon-ecs-agent`. Los SDK utilizan variables de entorno para localizar el agente al que conectarse.
Por el contrario, los *roles de IAM para las cuentas de servicio* proporcionan un token de *identidad web* que el SDK de AWS debe intercambiar con AWS Security Token Service usando `AssumeRoleWithWebIdentity`.
## Cómo funciona el agente de Pod Identity de EKS con un pod
1. Cuando Amazon EKS inicia un nuevo pod que utiliza una cuenta de servicio con una asociación de Pod Identity de EKS, el clúster agrega el siguiente contenido al manifiesto de pod:
```
env:
- name: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE
value: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token"
- name: AWS_CONTAINER_CREDENTIALS_FULL_URI
value: "http://169.254.170.23/v1/credentials"
volumeMounts:
- mountPath: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/"
name: eks-pod-identity-token
volumes:
- name: eks-pod-identity-token
projected:
defaultMode: 420
sources:
- serviceAccountToken:
audience: pods.eks.amazonaws.com
expirationSeconds: 86400 # 24 hours
path: eks-pod-identity-token
```
1. Kubernetes selecciona en qué nodo se va a ejecutar el pod. A continuación, el agente de Pod Identity de Amazon EKS del nodo utiliza la acción [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html) para recuperar las credenciales temporales de la API de autenticación de EKS.
1. El agente de Pod Identity de EKS pone estas credenciales a disposición de los SDK de AWS que ejecuta en sus contenedores.
1. Utilice el SDK en su aplicación sin especificar un proveedor de credenciales para utilizar la cadena de credenciales predeterminada. O bien, puede especificar el proveedor de credenciales del contenedor. Para obtener más información sobre las ubicaciones predeterminadas utilizadas, consulte la [cadena de proveedores de credenciales](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain) en la Guía de referencia de herramientas y SDK de AWS.
1. El SDK utiliza las variables de entorno para conectarse al agente de Pod Identity de EKS y recuperar las credenciales.
**nota**
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 una asociación de Pod Identity de EKS para la misma carga de trabajo.
# Configuración del agente de Pod Identity de Amazon EKS
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.
**sugerencia**
No es necesario instalar el agente de EKS Pod Identity en los clústeres del modo automático de EKS. Esta capacidad está integrada en el modo automático de EKS.
## Consideraciones
+ De forma predeterminada, el agente de Pod Identity de EKS está preinstalado en los clústeres del Modo automático de EKS. Para obtener más información, consulte [Automatización de la infraestructura de clústeres con el modo automático de EKS](automode.md).
+ De forma predeterminada, el agente de Pod Identity de EKS escucha en una dirección `IPv4` e `IPv6` para que los pods soliciten credenciales. El agente usa la dirección IP de bucle invertido (localhost) `169.254.170.23` para `IPv4` y la dirección IP de localhost `[fd00:ec2::23]` para `IPv6`.
+ Si deshabilita las direcciones `IPv6` o evita las direcciones IP `IPv6` de localhost, el agente no podrá iniciarse. Para iniciar el agente en los nodos que no pueden usar `IPv6`, siga los pasos que se indican en [Desactivar `IPv6` en el agente de Pod Identity de EKS](pod-id-agent-config-ipv6.md) a fin de deshabilitar la configuración `IPv6`.
## Creación del agente de Pod Identity de Amazon EKS
### Requisitos previos de agente
+ Un clúster existente de Amazon EKS. Para implementar uno, consulte [Introducción a Amazon EKS](getting-started.md). La versión del clúster y la versión de la plataforma deben ser iguales o posteriores a las versiones indicadas en [Versiones del clúster de Pod Identity de EKS](pod-identities.md#pod-id-cluster-versions).
+ El rol de nodo tiene permisos para que el agente realice la acción `AssumeRoleForPodIdentity` en la API de autenticación de EKS. Puede usar la [política administrada de AWS: AmazonEKSWorkerNodePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksworkernodepolicy) o agregar una política personalizada similar a la siguiente:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks-auth:AssumeRoleForPodIdentity"
],
"Resource": "*"
}
]
}
```
Esta acción se puede limitar mediante etiquetas para restringir los roles que pueden asumir los pods que utilizan el agente.
+ Los nodos pueden acceder y descargar imágenes de Amazon ECR. La imagen del contenedor del complemento se encuentra en los registros que figuran en [Visualización de los registros de imágenes de contenedores de Amazon para los complementos de Amazon EKS](add-ons-images.md).
Tenga en cuenta que puede cambiar la ubicación de la imagen y proporcionar `imagePullSecrets` para los complementos de EKS en **Valores de configuración opcionales** en la Consola de administración de AWS, y en `--configuration-values` en la AWS CLI.
+ Los nodos pueden acceder a la API de autenticación de Amazon EKS. En el caso de los clústeres privados, se requiere el punto de conexión `eks-auth` en AWS PrivateLink.
### Configuración del agente con la consola de AWS
1. Abra la [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**, selecciona 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 de agente de Pod Identity de EKS se estén ejecutando en su clúster.
```
kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
```
Un ejemplo de salida sería el siguiente.
```
eks-pod-identity-agent-gmqp7 1/1 Running 1 (24h ago) 24h
eks-pod-identity-agent-prnsh 1/1 Running 1 (24h ago) 24h
```
Ahora puede usar las asociaciones de Pod Identity de EKS en su clúster. Para obtener más información, consulte [Asignación de un rol de IAM a una cuenta de servicio de Kubernetes](pod-id-association.md).
### Configuración del agente con AWS CLI
1. Ejecute el siguiente comando de AWS CLI. Reemplace `my-cluster` por el nombre del clúster.
```
aws eks create-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent --addon-version v1.0.0-eksbuild.1
```
**nota**
El agente de Pod Identity de EKS no utiliza el `service-account-role-arn` en *Roles de IAM para cuentas de servicio*. Debe proporcionar al agente de Pod Identity de EKS los permisos en el rol de nodo.
1. Confirme que los pods de agente de Pod Identity de EKS se estén ejecutando en su clúster.
```
kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
```
Un ejemplo de salida sería el siguiente.
```
eks-pod-identity-agent-gmqp7 1/1 Running 1 (24h ago) 24h
eks-pod-identity-agent-prnsh 1/1 Running 1 (24h ago) 24h
```
Ahora puede usar las asociaciones de Pod Identity de EKS en su clúster. Para obtener más información, consulte [Asignación de un rol de IAM a una cuenta de servicio de Kubernetes](pod-id-association.md).
# Asignación de un rol de IAM a una cuenta de servicio de Kubernetes
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) con Pod Identity de EKS. 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.
Para crear una asociación de Pod Identity de EKS, solo hay un paso: se crea la asociación en EKS a través de la Consola de administración de AWS, AWS CLI, los SDK de AWS, AWS CloudFormation y otras herramientas. No existen datos ni metadatos sobre las asociaciones dentro del clúster en ningún objeto de Kubernetes y no se agrega ninguna anotación a las cuentas de servicio.
**Requisitos previos**
+ 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).
+ La entidad principal de IAM que va a crear la asociación debe tener `iam:PassRole`.
+ La última versión de AWS CLI instalada y configurada en su dispositivo o AWS CloudShell. Puede comprobar su versión actual con `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 AWS CLI en su directorio de usuarios 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).
## Creación de una asociación de Pod Identity (consola de AWS)
1. Abra la [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 **Acceder**.
1. En las **Asociaciones de Pod Identity**, elija **Crear**.
1. Para el **Rol de IAM**, seleccione el rol de IAM con los permisos que quiere que tenga la carga de trabajo.
**nota**
La lista solo contiene roles que tienen la siguiente política de confianza, que permite a Pod Identity de EKS utilizarlas.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
`sts:AssumeRole`: Pod Identity de EKS usa `AssumeRole` para asumir el rol de IAM antes de pasar las credenciales temporales a sus pods.
`sts:TagSession`: Pod Identity de EKS usa `TagSession` para incluir *etiquetas de sesión* en las solicitudes para AWS.
Puede utilizar estas etiquetas en las *claves de condición* de la política de confianza para restringir qué cuentas de servicio, espacios de nombres y clústeres pueden utilizar este rol.
Para obtener una lista de las claves de condición de Amazon EKS, consulte [Condiciones de Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys) en la *Referencia de autorizaciones de servicio*. Para obtener más información sobre las acciones y los recursos con los que puede utilizar una clave de condición, consulte [Acciones definidas por Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).
1. Para el **espacio de nombres de Kubernetes**, seleccione el espacio de nombres de Kubernetes que contiene la cuenta de servicio y la carga de trabajo. Si lo desea, puede especificar un espacio de nombres por nombre que no existe en el clúster.
1. Para la **cuenta de servicio de Kubernetes**, seleccione la cuenta de servicio de Kubernetes que se usará. El manifiesto de su carga de trabajo de Kubernetes debe especificar esta cuenta de servicio. Si lo desea, puede especificar una cuenta de servicio por nombre que no exista en el clúster.
1. (Opcional) Seleccione **Desactivar etiquetas de sesión** para desactivar las etiquetas de sesión predeterminadas que Pod Identity agrega automáticamente cuando asume el rol.
1. (Opcional) Active **Configurar política de sesión** para configurar una política de IAM que aplique restricciones adicionales a esta asociación de Pod Identity, además de los permisos definidos en la política de IAM asociada al rol de IAM.
**nota**
Una política de sesión solo se puede aplicar cuando la opción **Desactivar etiquetas de sesión** está seleccionada.
1. (Opcional) Para las **Etiquetas**, elija **Agregar etiqueta** para agregar metadatos en un par clave-valor. Estas etiquetas se aplican a la asociación y se pueden utilizar en las políticas de IAM.
Puede repetir este paso para agregar varias etiquetas.
1. Seleccione **Crear**.
## Cree una asociación de Pod Identity (AWS CLI)
1. Si desea asociar una política de IAM existente a su rol de IAM, vaya al siguiente paso.
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
```
1. Cree un rol de IAM y asócielo a una cuenta de servicio de Kubernetes.
1. Si tiene una cuenta de servicio de Kubernetes existente que desea que asuma un rol de IAM, puede omitir este paso.
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 <
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": [
{
"Sid": "Allow EKS Auth service to assume this role for Pod Identities",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
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.
## Siguientes pasos
[Configuración de pods para acceder a los servicios de AWS con cuentas de servicio](pod-id-configure-pods.md)
# Acceso a los recursos de AWS mediante los roles de IAM de destino de EKS Pod Identity
Al ejecutar aplicaciones en Amazon Elastic Kubernetes Service (Amazon EKS), es posible que necesite acceder a los recursos de AWS que existen en cuentas de AWS diferentes. Esta guía le muestra cómo configurar el acceso entre estas cuentas mediante EKS Pod Identity, que permite a sus pods de Kubernetes acceder a otros recursos de AWS con roles de destino.
## Requisitos previos
Antes de comenzar, asegúrese de haber seguido estos pasos:
+ [Configuración del agente de Amazon EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html)
+ [Creación de un rol de EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)
## Cómo funciona
Pod Identity permite a las aplicaciones de su clúster de EKS acceder a los recursos de AWS entre cuentas mediante un proceso denominado encadenamiento de roles.
Al crear una asociación de Pod Identity, puede proporcionar dos roles de IAM: un [rol de EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) en la misma cuenta que su clúster de EKS y un rol de IAM de destino de la cuenta que contiene los recursos de AWS a los que desea acceder (como buckets de S3 o bases de datos de RDS). El [rol de EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) debe estar en la cuenta de su clúster de EKS debido a los requisitos de [PassRole de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam-passrole-service.html), mientras que el rol de IAM de destino puede estar en cualquier cuenta de AWS. PassRole permite a una entidad de AWS delegar la asunción de roles a otro servicio. EKS Pod Identity usa PassRole para conectar un rol a una cuenta de servicio de Kubernetes, lo que requiere que tanto el rol como la identidad que lo pasa estén en la misma cuenta de AWS que el clúster de EKS. Cuando el pod de la aplicación necesita acceder a los recursos de AWS, solicita las credenciales a Pod Identity. A continuación, Pod Identity lleva a cabo automáticamente dos asunciones de rol en secuencia: primero asume el [rol de EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) y, a continuación, utiliza esas credenciales para asumir el rol de IAM de destino. Este proceso proporciona al pod credenciales temporales con los permisos definidos en el rol de destino, lo que permite un acceso seguro a los recursos de otras cuentas de AWS.
## Consideraciones sobre el almacenamiento en caché
Debido a los mecanismos de almacenamiento en caché, es posible que las actualizaciones de un rol de IAM en una asociación de Pod Identity existente no se apliquen inmediatamente en los pods que se ejecutan en el clúster de EKS. El agente de Pod Identity almacena en caché las credenciales de IAM en función de la configuración de la asociación en el momento en que se obtienen las credenciales. Si la asociación incluye solo un [rol de EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) y ningún rol de IAM de destino, las credenciales almacenadas en caché duran 6 horas. Si la asociación incluye tanto el ARN del [rol de EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) como un rol de IAM de destino, las credenciales almacenadas en caché duran 59 minutos. La modificación de una asociación existente, como actualizar el ARN de [rol de EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) o agregar un rol de IAM de destino, no restablece la caché existente. Como resultado, el agente no reconocerá las actualizaciones hasta que se actualicen las credenciales almacenadas en caché. Para aplicar los cambios antes, puede volver a crear los pods existentes; de lo contrario, tendrá que esperar a que caduque la caché.
## Paso 1: creación y asociación de un rol de IAM de destino
En este paso, establecerá una cadena de confianza segura mediante la creación y configuración de un rol de IAM de destino. A modo de demostración, crearemos un nuevo rol de IAM de destino para establecer una cadena de confianza entre dos cuentas de AWS: el [rol de EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) (por ejemplo, `eks-pod-identity-primary-role`) de la cuenta de AWS del clúster de EKS obtiene permiso para asumir el rol de IAM de destino (por ejemplo, `eks-pod-identity-aws-resources`) en su cuenta de destino, lo que permite el acceso a recursos de AWS como los buckets de Amazon S3.
### Creación del rol de IAM de destino
1. Abra la [consola de Amazon IAM](https://console.aws.amazon.com/iam/home).
1. En la barra de navegación superior, compruebe que haya iniciado sesión en la cuenta que contiene los recursos de AWS (como buckets de S3 o tablas de DynamoDB) para el rol de IAM de destino.
1. En el panel de navegación izquierdo, elija **Roles**.
1. Elija el botón **Crear rol** y, a continuación, seleccione **Cuenta de AWS** en “Tipo de entidad de confianza”.
1. Elija **Otra cuenta de AWS**, ingrese su número de cuenta de AWS (la cuenta en la que existe su [rol de EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)) y, a continuación, elija **Siguiente**.
1. Agregue las políticas de permisos que desee asociar al rol (por ejemplo, AmazonS3FullAccess) y, a continuación, elija **Siguiente**.
1. Ingrese un nombre de rol (por ejemplo, `MyCustomIAMTargetRole`) y, a continuación, elija **Crear rol**.
### Actualización de la política de confianza del rol de IAM de destino
1. Después de crear el rol, volverá a la lista de **Roles**. Busque y seleccione el nuevo rol que ha creado en el procedimiento anterior (por ejemplo, `MyCustomIAMTargetRole`).
1. Seleccione la pestaña **Relaciones de confianza**.
1. Haga clic en **Editar política de confianza** en la parte derecha.
1. En el editor de políticas, reemplace el JSON predeterminado por la política de confianza. Reemplace los valores de marcadores de posición de nombre del rol y `111122223333` en el ARN del rol de IAM por el ID de cuenta de AWS que aloja el clúster de EKS. Si lo desea, también puede usar PrincipalTags en la política de confianza de roles para autorizar solo cuentas de servicio específicas de un clúster y espacio de nombres determinados para que asuman su rol de destino. Por ejemplo:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/example-cluster",
"aws:RequestTag/kubernetes-namespace": "ExampleNameSpace",
"aws:RequestTag/kubernetes-service-account": "ExampleServiceAccountName"
},
"ArnEquals": {
"aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
}
}
}
]
}
```
La política anterior permite que el rol `eks-pod-identeity-primary-role` de la cuenta 111122223333 de AWS con las [etiquetas de sesión de Pod Identity de EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html) correspondientes asuma este rol.
Si ha [desactivado las etiquetas de sesión](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html#pod-id-abac-tags) en su Pod Identity de EKS, este también establece el `sts:ExternalId` con información sobre el clúster, el espacio de nombres y la cuenta de servicio de un pod al asumir un rol de destino.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "region/111122223333/cluster-name/namespace/service-account-name"
},
"ArnEquals": {
"aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:TagSession"
}
]
}
```
La política anterior ayuda a garantizar que solo el clúster, el espacio de nombres y la cuenta de servicio esperados puedan asumir el rol de destino.
### Actualización de la política de permisos para el rol de EKS Pod Identity
En este paso, actualizará la política de permisos del [rol de EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) asociado a su clúster de Amazon EKS. Para ello, agregará el ARN del rol de IAM de destino como recurso.
1. Abra la [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 de EKS.
1. Elija la pestaña **Acceso**.
1. En **Asociaciones de Pod Identity**, seleccione su [rol de EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html).
1. Elija **Permisos**, **Agregar permisos** y, a continuación, **Crear política insertada**.
1. Elija **JSON** en el lado derecho.
1. En el editor de políticas, reemplace el JSON predeterminado por la política de permisos. Reemplace el valor de marcadores de posición de nombre del rol y `222233334444` en el ARN del rol de IAM por el rol de IAM de destino. Por ejemplo:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Resource": "arn:aws:iam::222233334444:role/eks-pod-identity-aws-resources"
}
]
}
```
## Paso 2: asociación del rol de IAM de destino a una cuenta de servicio de Kubernetes
En este paso, creará una asociación entre el rol de IAM de destino y la cuenta de servicio de Kubernetes en su clúster de EKS.
1. Abra la [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 al que desea agregar la asociación.
1. Elija la pestaña **Acceder**.
1. En las **Asociaciones de Pod Identity**, elija **Crear**.
1. Elija el [rol de EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) en **Rol de IAM** para que lo asuman sus cargas de trabajo.
1. Elija el rol de IAM de destino en **Rol de IAM de destino** que asumirá el [rol de EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html).
1. En el campo **Espacio de nombres de Kubernetes**, ingrese el nombre del espacio de nombres donde desea crear la asociación (por ejemplo, `my-app-namespace`). Esto define dónde reside la cuenta de servicio.
1. En el campo **Cuenta de servicio de Kubernetes**, ingrese el nombre de la cuenta de servicio (por ejemplo, `my-service-account`) que utilizará las credenciales de IAM. Esto vincula el rol de IAM a la cuenta de servicio.
1. (Opcional) Seleccione **Desactivar etiquetas de sesión** para desactivar las etiquetas de sesión predeterminadas que Pod Identity agrega automáticamente cuando asume el rol.
1. (Opcional) Active **Configurar política de sesión** para configurar una política de IAM que aplique restricciones adicionales a esta asociación de Pod Identity, además de los permisos definidos en la política de IAM asociada al **rol de IAM de destino**.
**nota**
1. Una política de sesión solo se puede aplicar cuando la opción **Desactivar etiquetas de sesión** está seleccionada. 2. Si especifica una política de sesión, las restricciones de la política se aplican a los permisos del **rol de IAM de destino** y no al **rol de IAM** asociado con esta asociación de Pod Identity.
1. Elija **Crear** para crear la asociación.
# Configuración de pods para acceder a los servicios de AWS con cuentas de servicio
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).
+ Una cuenta de servicio de Kubernetes existente y una asociación de Pod Identity de EKS que asocia la cuenta de servicio a un 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 un rol de IAM a una cuenta de servicio de Kubernetes](pod-id-association.md).
+ La última versión de AWS CLI instalada y configurada en su dispositivo o AWS CloudShell. Puede comprobar su versión actual con `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 AWS CLI en su directorio de usuarios 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 <
El control de acceso basado en atributos (ABAC) concede derechos a los usuarios mediante políticas que combinan atributos. Pod Identity de EKS adjunta etiquetas a las credenciales temporales de cada pod con atributos como el nombre del clúster, el espacio de nombres y el nombre de la cuenta de servicio. Estas etiquetas de sesión de roles permiten a los administradores crear un único rol que funcione en todas las cuentas de servicio al permitir el acceso a los recursos de AWS en función de las etiquetas coincidentes. Al agregar la compatibilidad con las etiquetas de sesión de roles, puede reforzar los límites de seguridad entre los clústeres y las cargas de trabajo dentro de los clústeres, mientras reutilizan los mismos roles y políticas de IAM.
## Ejemplo de política con etiquetas
A continuación, se muestra un ejemplo de política de IAM que concede permisos `s3:GetObject` cuando el objeto correspondiente está etiquetado con el nombre del clúster de EKS.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectTagging"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"s3:ExistingObjectTag/eks-cluster-name": "${aws:PrincipalTag/eks-cluster-name}"
}
}
}
]
}
```
## Activación o desactivación de etiquetas de sesión
EKS Pod Identity agrega un conjunto predefinido de etiquetas de sesión cuando asume el rol. Estas etiquetas de sesión permiten a los administradores crear un único rol que funcione en todos los recursos al permitir el acceso a los recursos de AWS en función de las etiquetas coincidentes.
### Activación de las etiquetas de sesión
Las etiquetas de sesión se activan automáticamente con EKS Pod Identity, por lo que no es necesario que haga nada. De forma predeterminada, EKS Pod Identity adjunta un conjunto de etiquetas predefinidas a la sesión. Para hacer referencia a estas etiquetas en las políticas, utilice la sintaxis `${aws:PrincipalTag/` seguida de la clave de etiqueta. Por ejemplo, `${aws:PrincipalTag/kubernetes-namespace}`.
+ `eks-cluster-arn`
+ `eks-cluster-name`
+ `kubernetes-namespace`
+ `kubernetes-service-account`
+ `kubernetes-pod-name`
+ `kubernetes-pod-uid`
### Desactivación de las etiquetas de sesión
AWS comprime las políticas de sesión insertadas, los ARN de políticas administradas y las etiquetas de sesión en un formato binario empaquetado que tiene un límite separado. Si recibe un error `PackedPolicyTooLarge` que indica que el formato binario empaquetado ha superado el límite de tamaño, puede desactivar las etiquetas de sesión agregadas por EKS Pod Identity para intentar reducir el tamaño. Para desactivar estas etiquetas de sesión, siga estos pasos:
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. En el panel de navegación izquierdo, seleccione **Clústeres** y, luego, seleccione el nombre del clúster que desea modificar.
1. Elija la pestaña **Acceso**.
1. En **Asociaciones de Pod Identity**, elija el ID de asociación que desea modificar en **ID de asociación** y, a continuación, **Editar**.
1. En **Etiquetas de sesión**, elija **Desactivar etiquetas de sesión**.
1. Seleccione **Save changes (Guardar cambios)**.
## Etiquetas entre cuentas
Todas las etiquetas de sesión que agrega Pod Identity de EKS son *transitivas*; las claves y los valores de las etiquetas se transfieren a cualquier acción `AssumeRole` que sus cargas de trabajo utilicen para cambiar los roles a otra cuenta. Puede utilizar estas etiquetas en las políticas de otras cuentas para limitar el acceso en situaciones entre cuentas. Para obtener más información, consulte [Encadenar roles con etiquetas de sesión](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html#id_session-tags_role-chaining) en la *Guía del usuario de IAM.*
## Etiquetas personalizadas
Pod Identity de Amazon EKS no puede agregar etiquetas personalizadas adicionales a la acción `AssumeRole` que realiza. Sin embargo, las etiquetas que se aplican al rol de IAM siempre están disponibles en el mismo formato: `${aws:PrincipalTag/` seguido de la clave, por ejemplo, `${aws:PrincipalTag/MyCustomTag}`.
**nota**
Las etiquetas agregadas a la sesión mediante la solicitud de `sts:AssumeRole` tienen prioridad en caso de conflicto. Por ejemplo, supongamos que:
Amazon EKS agrega una clave `eks-cluster-name` y un valor `my-cluster` a la sesión cuando EKS asume el rol de cliente y
Agrega una etiqueta `eks-cluster-name` al rol de IAM con el valor `my-own-cluster`.
En este caso, prevalecerá la primera y el valor de la etiqueta `eks-cluster-name` será `my-cluster`.
# Uso de Pod Identity con el SDK de AWS
## Uso de las credenciales de Pod Identity de EKS
Para usar las credenciales de una asociación de Pod Identity de EKS, el código puede usar cualquier SDK de AWS 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 que desee utilizar. Las credenciales de Pod Identity de EKS 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 las Pod Identities de EKS se han agregado al *proveedor de credenciales del contenedor*, que se busca en un paso de 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 una asociación de Pod Identity de EKS para la misma carga de trabajo.
Para obtener más información sobre cómo funcionan las Pod Identities de EKS, consulte [Descripción del funcionamiento de Pod Identity de EKS](pod-id-how-it-works.md).
Para usar [Más información sobre cómo EKS Pod Identity concede a los pods acceso a los servicios de AWS](pod-identities.md), los contenedores de los pods deben utilizar una versión del AWS SDK que admita asumir un rol de IAM del agente de Pod Identity de EKS. Asegúrese de usar las siguientes versiones, o posteriores, para el SDK de AWS:
+ Java (Versión 2): [2.21.30](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.21.30)
+ Java: [1.12.746](https://github.com/aws/aws-sdk-java/releases/tag/1.12.746)
+ Go v1: [v1.47.11](https://github.com/aws/aws-sdk-go/releases/tag/v1.47.11)
+ Go v2: [lanzamiento-2023-11-14](https://github.com/aws/aws-sdk-go-v2/releases/tag/release-2023-11-14)
+ Python (Boto3): [1.34.41](https://github.com/boto/boto3/releases/tag/1.34.41)
+ Python (botocore): [1.34.41](https://github.com/boto/botocore/releases/tag/1.34.41)
+ AWS CLI: [1.30.0](https://github.com/aws/aws-cli/releases/tag/1.30.0)
AWS CLI: [2.15.0](https://github.com/aws/aws-cli/releases/tag/2.15.0)
+ JavaScript v2: [2.1550.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.1550.0)
+ JavaScript v3: [v3.458.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.458.0)
+ [Kotlin: v1.0.1](https://github.com/awslabs/aws-sdk-kotlin/releases/tag/v1.0.1)
+ Ruby: [3.188.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#31880-2023-11-22)
+ [Rust: lanzamiento-2024-03-13](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2024-03-13)
+ C\$1\$1: [1.11.263](https://github.com/aws/aws-sdk-cpp/releases/tag/1.11.263)
+ .NET: [3.7.734.0](https://github.com/aws/aws-sdk-net/releases/tag/3.7.734.0)
+ PowerShell: [4.1.502](https://www.powershellgallery.com/packages/AWS.Tools.Common/4.1.502)
+ PHP: [3.289.0](https://github.com/aws/aws-sdk-php/releases/tag/3.287.1)
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.
Para obtener una lista de los complementos compatibles con Pod Identity de EKS, consulte [Referencia de compatibilidad de Pod Identity](retreive-iam-info.md#pod-id-add-on-versions).
# Desactivar `IPv6` en el agente de Pod Identity de EKS
## Consola de administración de AWS
1. Para deshabilitar `IPv6` en el agente de Pod Identity de EKS, añada la siguiente configuración a los **ajustes de configuración opcionales** del complemento de EKS.
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. En el panel de navegación izquierdo, seleccione **Clusters** (Clústeres) y, a continuación, seleccione el nombre del clúster para el que desea configurar el complemento.
1. Elija la pestaña **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 **Editar**.
1. En la página de **configuración del agente de Pod Identity de EKS**, haga lo siguiente:
1. Seleccione la **Versión** que desea utilizar. Le recomendamos que mantenga la misma versión que en el paso anterior y que actualice la versión y la configuración en acciones separadas.
1. Seleccione **Ajustes de configuración opcionales**.
1. Introduzca la clave JSON `"agent":` y el valor de un objeto JSON anidado con una clave `"additionalArgs":` en **Valores de configuración**. El texto resultante debe ser un objeto JSON válido. Si esta clave y este valor son los únicos datos del cuadro de texto, rodee la clave y el valor entre corchetes `{ }`. En el siguiente ejemplo se muestra que la política de red está habilitada:
```
{
"agent": {
"additionalArgs": {
"-b": "169.254.170.23"
}
}
}
```
En esta configuración, se establece que la dirección `IPv4` sea la única dirección que utilice el agente.
1. Para aplicar la nueva configuración mediante la sustitución de los pods del agente de Pod Identity de EKS, seleccione **Guardar cambios**.
Amazon EKS aplica los cambios a los complementos de EKS mediante el *despliegue* del `DaemonSet` de Kubernetes para el agente de Pod Identity de EKS. Puede hacer un seguimiento del estado del lanzamiento en el **historial de actualizaciones** en la Consola de administración de AWS y con `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system`.
`kubectl rollout` tiene los siguientes comandos:
```
$ kubectl rollout
history -- View rollout history
pause -- Mark the provided resource as paused
restart -- Restart a resource
resume -- Resume a paused resource
status -- Show the status of the rollout
undo -- Undo a previous rollout
```
Si la implementación lleva demasiado tiempo, Amazon EKS la anulará y se agregará al **historial de actualizaciones** del **complemento un mensaje con el tipo de actualización del complemento** y el estado **Fallido**. Para investigar cualquier problema, comience por el historial de la implementación y ejecute `kubectl logs` en un pod del agente de Pod Identity de EKS para ver los registros del agente de Pod Identity de EKS.
1. Si la nueva entrada en el **historial de actualizaciones** tiene el estado **Correcto**, esto significa que la implementación se ha completado y que el complemento está utilizando la nueva configuración en todos los pods del agente de Pod Identity de EKS.
## AWS CLI
1. Para deshabilitar `IPv6` en el agente de Pod Identity de EKS, agregue la siguiente configuración a los **valores de configuración** del complemento de EKS.
Ejecute el siguiente comando de AWS CLI. Reemplace `my-cluster` por el nombre del clúster y el ARN del rol de IAM por el rol que va a usar.
```
aws eks update-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent \
--resolve-conflicts PRESERVE --configuration-values '{"agent":{"additionalArgs": { "-b": "169.254.170.23"}}}'
```
En esta configuración, se establece que la dirección `IPv4` sea la única dirección que utilice el agente.
Amazon EKS aplica los cambios a los complementos de EKS mediante el *despliegue* del DaemonSet de Kubernetes para el agente de Pod Identity de EKS. Puede hacer un seguimiento del estado del lanzamiento en el **historial de actualizaciones** en la Consola de administración de AWS y con `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system`.
`kubectl rollout` tiene los siguientes comandos:
```
kubectl rollout
history -- View rollout history
pause -- Mark the provided resource as paused
restart -- Restart a resource
resume -- Resume a paused resource
status -- Show the status of the rollout
undo -- Undo a previous rollout
```
Si la implementación lleva demasiado tiempo, Amazon EKS la anulará y se agregará al **historial de actualizaciones** del **complemento un mensaje con el tipo de actualización del complemento** y el estado **Fallido**. Para investigar cualquier problema, comience por el historial de la implementación y ejecute `kubectl logs` en un pod del agente de Pod Identity de EKS para ver los registros del agente de Pod Identity de EKS.
# Creación de un rol de IAM con la política de confianza requerida por Pod Identity de EKS
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
** `sts:AssumeRole` **
Pod Identity de EKS usa `AssumeRole` para asumir el rol de IAM antes de pasar las credenciales temporales a sus pods.
** `sts:TagSession` **
Pod Identity de EKS usa `TagSession` para incluir *etiquetas de sesión* en las solicitudes para AWS STS.
**Establecimiento de condiciones**
Puede utilizar estas etiquetas en las *claves de condición* de la política de confianza para restringir qué cuentas de servicio, espacios de nombres y clústeres pueden utilizar este rol. Para ver la lista de etiquetas de solicitud que agrega Pod Identity, consulte [Activación o desactivación de etiquetas de sesión](pod-id-abac.md#pod-id-abac-tags).
Por ejemplo, puede restringir los pods que pueden asumir el rol de IAM de Pod Identity a la `ServiceAccount` y el `Namespace` específicos con la siguiente política de confianza con la `Condition` agregada:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/kubernetes-namespace": [
"Namespace"
],
"aws:RequestTag/kubernetes-service-account": [
"ServiceAccount"
]
}
}
}
]
}
```
Para obtener una lista de las claves de condición de Amazon EKS, consulte [Condiciones de Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys) en la *Referencia de autorizaciones de servicio*. Para obtener más información sobre las acciones y los recursos con los que puede utilizar una clave de condición, consulte [Acciones definidas por Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).