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