**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.
# Seguridad en Amazon EKS
La seguridad en la nube de AWS es la mayor prioridad. Como cliente de AWS, se beneficia de una arquitectura de red y un centro de datos que se han diseñado para satisfacer los requisitos de seguridad de las organizaciones más exigentes.
La seguridad es una responsabilidad compartida entre AWS y el usuario. El [modelo de responsabilidad compartida](https://aws.amazon.com/compliance/shared-responsibility-model/) la describe como seguridad *de* la nube y seguridad *en* la nube:
+ **Seguridad en la nube**: AWS es responsable de proteger la infraestructura que ejecuta los servicios de AWS en la nube de AWS. En Amazon EKS, AWS es responsable del plano de control de Kubernetes, que incluye los nodos del plano de control y la base de datos `etcd`. Auditores externos prueban y verifican periódicamente la eficacia de nuestra seguridad en el marco de los [programas de conformidad de AWS](https://aws.amazon.com/compliance/programs/). Para obtener más información sobre los programas de conformidad que se aplican a Amazon EKS, consulte [Servicios de AWS en el ámbito del programa de conformidad](https://aws.amazon.com/compliance/services-in-scope/).
+ **Seguridad en la nube**: las siguientes áreas son su responsabilidad.
+ La configuración de seguridad del plano de datos, incluida la configuración de los grupos de seguridad que permiten que el tráfico pase del plano de control de Amazon EKS a la VPC del cliente
+ La configuración de los nodos y los contenedores
+ El sistema operativo de los nodos (incluidas las actualizaciones y los parches de seguridad)
+ Otros software de aplicaciones asociado:
+ Configuración y administración de controles de red, como las reglas del firewall
+ Administración de identidad y acceso de nivel de plataforma, con o además de IAM
+ La confidencialidad de los datos, los requisitos de la empresa y la legislación y los reglamentos aplicables.
Amazon EKS cuenta con certificaciones de programas de cumplimiento, adecuadas para aplicaciones reguladas y confidenciales. Amazon EKS cumple con las normas [SOC](https://aws.amazon.com/compliance/soc-faqs/), [PCI](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/), [ISO](https://aws.amazon.com/compliance/iso-certified/), [FedRAMP-Moderate](https://aws.amazon.com/compliance/fedramp/), [IRAP](https://aws.amazon.com/compliance/irap/), [C5](https://aws.amazon.com/compliance/bsi-c5/), [K-ISMS](https://aws.amazon.com/compliance/k-isms/), [ENS High](https://aws.amazon.com/compliance/esquema-nacional-de-seguridad/), [OSPAR](https://aws.amazon.com/compliance/OSPAR/) y [HITRUST CSF](https://aws.amazon.com/compliance/hitrust/). Además, es un servicio que cumple con los requisitos de la [HIPAA](https://aws.amazon.com/compliance/hipaa-compliance/). Para obtener más información, consulte [Información sobre el funcionamiento del control de acceso en Amazon EKS](cluster-auth.md).
Esta documentación lo ayuda a comprender cómo aplicar el modelo de responsabilidad compartida cuando se utiliza Amazon EKS. En los siguientes temas, se mostrará cómo configurar Amazon EKS para satisfacer sus objetivos de seguridad y conformidad. También puede aprender a utilizar otros servicios de AWS que ayudan a monitorear y proteger los recursos de Amazon EKS.
**nota**
Los contenedores de Linux se componen de grupos de control (cgroups) y espacios de nombres que ayudan a limitar el acceso de un contenedor, pero todos los contenedores comparten el mismo kernel de Linux que la instancia de Amazon EC2 anfitrión. No se recomienda ejecutar un contenedor como usuario raíz (UID 0) o conceder acceso a un contenedor a recursos o espacios de nombres de anfitrión como la red de anfitrión o el espacio de nombres PID de anfitrión, ya que al hacerlo se reduce la eficacia del aislamiento que proporcionan los contenedores.
**Topics**
+ [Protección de los clústeres de Amazon EKS con las prácticas recomendadas](security-best-practices.md)
+ [Análisis de vulnerabilidades en Amazon EKS](configuration-vulnerability-analysis.md)
+ [Validación de la conformidad para clústeres de Amazon EMR](compliance.md)
+ [Consideraciones de seguridad para Amazon Elastic Kubernetes Service](security-eks.md)
+ [Consideraciones de seguridad para Kubernetes](security-k8s.md)
+ [Consideraciones de seguridad para el modo automático de Amazon EKS](auto-security.md)
+ [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md)
+ [Administración de identidades y accesos para Amazon EKS](security-iam.md)
# Protección de los clústeres de Amazon EKS con las prácticas recomendadas
Las prácticas recomendadas de seguridad de Amazon EKS se encuentran en las [Prácticas recomendadas para la seguridad](https://docs.aws.amazon.com/eks/latest/best-practices/security.html) de la *Guía de prácticas recomendadas de Amazon EKS*.
# Análisis de vulnerabilidades en Amazon EKS
La seguridad es una consideración fundamental para configurar y mantener clústeres y aplicaciones de Kubernetes. A continuación, se enumeran los recursos disponibles para que pueda analizar la configuración de seguridad de sus clústeres de EKS y comprobar si hay vulnerabilidades, y las integraciones con servicios de AWS que pueden realizar ese análisis por usted.
## Referencia del Center for Internet Security (CIS, Centro para la seguridad de Internet) para Amazon EKS
El [Punto de referencia de Kubernetes del Centro para la seguridad de Internet (CIS)](https://www.cisecurity.org/benchmark/kubernetes/) proporciona orientación para las configuraciones de seguridad de nodos de Amazon EKS. El punto de referencia:
+ Es aplicable a los nodos de Amazon EC2 (administrados y autoadministrados) donde es responsable de las configuraciones de seguridad de los componentes de Kubernetes.
+ Proporciona una forma estándar y aprobada por la comunidad de garantizar que ha configurado de forma segura el clúster y los nodos de Kubernetes al utilizar Amazon EKS.
+ Consta de cuatro secciones: configuración de registro del plano de control, configuraciones de seguridad de nodos, políticas y servicios administrados.
+ Admite todas las versiones de Kubernetes actualmente disponibles en Amazon EKS y se puede ejecutar con [kube-bench](https://github.com/aquasecurity/kube-bench), una herramienta estándar de código abierto para verificar la configuración mediante el punto de referencia del CIS en clústeres de Kubernetes.
Para obtener más información, consulte [Presentación del punto de referencia de Amazon EKS del CIS](https://aws.amazon.com/blogs/containers/introducing-cis-amazon-eks-benchmark).
Para que una canalización de `aws-sample` automatizada actualice el grupo de nodos con una AMI de referencia de CIS, consulte [EKS-Optimized AMI Hardening Pipeline](https://github.com/aws-samples/pipeline-for-hardening-eks-nodes-and-automating-updates).
## Versiones de la plataforma de Amazon EKS
Las *versiones de la plataforma* de Amazon EKS representan las capacidades del plano de control del clúster, lo que incluye las marcas de servidor de la API de Kubernetes que se encuentran habilitadas y la versión de parche de Kubernetes actual. Los nuevos clústeres están implementados con la versión más reciente de la plataforma. Para obtener más información, consulte las [versiones de la plataforma de EKS](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html).
Puede [actualizar un clúster de Amazon EKS](update-cluster.md) con las versiones más recientes de Kubernetes. Cuando haya nuevas versiones de Kubernetes disponibles en Amazon EKS, le recomendamos que actualice proactivamente los clústeres para que utilicen la versión más reciente disponible. Para obtener más información sobre las versiones de Kubernetes en EKS, consulte las [versiones compatibles de Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
## Lista de vulnerabilidades del sistema operativo
### Lista de vulnerabilidades de AL2023
Realice un seguimiento de los eventos de seguridad o privacidad de Amazon Linux 2023 en el [Centro de seguridad de Amazon Linux](https://alas.aws.amazon.com/alas2023.html) o suscríbase a la [fuente RSS](https://alas.aws.amazon.com/AL2023/alas.rss) asociada. Los eventos de seguridad y privacidad incluyen una descripción general del problema, los paquetes afectados e instrucciones para actualizar las instancias y corregir el problema.
### Lista de vulnerabilidades Amazon Linux 2
Realice un seguimiento de los eventos de seguridad o privacidad de Amazon Linux 2 en el [Centro de seguridad de Amazon Linux](https://alas.aws.amazon.com/alas2.html) o suscríbase a la [fuente RSS](https://alas.aws.amazon.com/AL2/alas.rss) asociada. Los eventos de seguridad y privacidad incluyen una descripción general del problema, los paquetes afectados e instrucciones para actualizar las instancias y corregir el problema.
## Detección de nodos con Amazon Inspector
Puede utilizar [Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_introduction.html) para verificar la accesibilidad de la red no deseada de sus nodos y a fin de buscar vulnerabilidades en dichas instancias de Amazon EC2.
## Detección de clústeres y nodos con Amazon GuardDuty
Amazon GuardDuty es un servicio de detección de amenazas que ayuda a proteger las cuentas, los contenedores, las cargas de trabajo y los datos de su entorno de AWS. Entre otras características, GuardDuty ofrece las siguientes dos características que detectan posibles amenazas para sus clústeres de EKS: *Protección de EKS* y *Supervisión en tiempo de ejecución*.
Para obtener más información, consulte [Detección de amenazas con Amazon GuardDuty](integration-guardduty.md).
# Validación de la conformidad para clústeres de Amazon EMR
Para saber si un servicio de AWS está incluido en el ámbito de programas de conformidad específicos, consulte [Servicios de AWS en el ámbito del programa de conformidad](https://aws.amazon.com/compliance/services-in-scope/) y escoja el programa de conformidad que le interese. Para obtener información general, consulte [Programas de conformidad de AWS](https://aws.amazon.com/compliance/programs/).
Puede descargar los informes de auditoría de terceros mediante AWS Artifact. Para obtener más información, consulte [Descarga de informes en AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Su responsabilidad de cumplimiento al utilizar servicios de AWS está determinada por la sensibilidad de sus datos, los objetivos de cumplimiento de su empresa y las leyes y las regulaciones aplicables. AWS proporciona los siguientes recursos para ayudar con el cumplimiento:
+ [Cumplimiento de seguridad y gobernanza](https://aws.amazon.com/solutions/security/security-compliance-governance/): en estas guías se explican las consideraciones de arquitectura y se proporcionan pasos para implementar las características de seguridad y cumplimiento.
+ [Referencia de servicios válidos de HIPAA](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/): muestra una lista con los servicios válidos de HIPAA. No todos los servicios de AWS son aptos para HIPAA.
+ [AWSRecursos de conformidad](https://aws.amazon.com/compliance/resources/): este conjunto de manuales y guías podría aplicarse a su sector y ubicación.
+ [Guías de cumplimiento para clientes de AWS](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf): comprenda el modelo de responsabilidad compartida desde el punto de vista del cumplimiento. Las guías resumen las prácticas recomendadas para garantizar la seguridad de los servicios de AWS y orientan los controles de seguridad en varios marcos (incluidos el Instituto Nacional de Estándares y Tecnología [NIST], el Consejo de Estándares de Seguridad de la Industria de Tarjetas de Pago [PCI] y la Organización Internacional de Normalización [ISO]).
+ [Evaluación de recursos con reglas](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) en la *guía para desarrolladores de AWS Config*: el servicio AWS Config evalúa en qué medida las configuraciones de los recursos cumplen con las prácticas internas, las directrices del sector y las normativas.
+ [AWS Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html): este producto de AWS proporciona una visión completa de su estado de seguridad en AWS. Security Hub utiliza controles de seguridad para evaluar sus recursos de AWS y comprobar su cumplimiento con los estándares y las prácticas recomendadas del sector de la seguridad. Para obtener una lista de los servicios y controles compatibles, consulte la [Referencia de controles de Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html).
+ [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html): este servicio de AWS detecta posibles amenazas para sus cuentas, cargas de trabajo, contenedores y datos de AWS mediante el monitoreo de su entorno para detectar actividades sospechosas y maliciosas. GuardDuty puede ayudarlo a satisfacer varios requisitos de conformidad, como PCI DSS, cumpliendo los requisitos de detección de intrusos que exigen determinados marcos de conformidad.
+ [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html): este servicio de AWS le ayuda a auditar de manera continua su uso de AWS para simplificar la forma en que administra el riesgo y la conformidad con las regulaciones y los estándares del sector.
# Consideraciones de seguridad para Amazon Elastic Kubernetes Service
A continuación, se presentan consideraciones de seguridad en la nube que impactan en Amazon EKS.
**Topics**
+ [Seguridad de la infraestructura de Amazon EKS](infrastructure-security.md)
+ [Comprensión de la resiliencia de los clústeres de Amazon EKS](disaster-recovery-resiliency.md)
+ [Prevención de suplentes confusos entre servicios en Amazon EKS](cross-service-confused-deputy-prevention.md)
# Seguridad de la infraestructura de Amazon EKS
Como servicio administrado, Amazon Elastic Kubernetes Service está protegido por la seguridad de la red global AWS. Para obtener información sobre los servicios de seguridad de AWS y sobre cómo AWS protege la infraestructura, consulte [Seguridad en la nube de AWS](https://aws.amazon.com/security/). Para diseñar su entorno de AWS siguiendo las prácticas recomendadas de seguridad de infraestructura, consulte [Protección de la infraestructura](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) en *Portal de seguridad de AWS Well‐Architected Framework*.
Puede utilizar llamadas a la API publicadas en AWS para acceder a Amazon EKS a través de la red. Los clientes deben admitir lo siguiente:
+ Seguridad de la capa de transporte (TLS). Exigimos TLS 1.2 y recomendamos TLS 1.3.
+ Conjuntos de cifrado con confidencialidad directa total (PFS) como DHE (Ephemeral Diffie-Hellman) o ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). La mayoría de los sistemas modernos como Java 7 y posteriores son compatibles con estos modos.
Además, las solicitudes deben estar firmadas mediante un ID de clave de acceso y una clave de acceso secreta que esté asociada a una entidad principal de IAM. También puede utilizar el [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) (AWS STS) con el objeto de generar credenciales de seguridad temporales para firmar solicitudes.
Cuando se crea un clúster de Amazon EKS, se especifican las subredes de la VPC que utilizará el clúster. Amazon EKS requiere subredes en al menos dos zonas de disponibilidad. Recomendamos una VPC con subredes públicas y privadas para que Kubernetes pueda crear equilibradores de carga públicos en las subredes públicas que equilibren la carga de tráfico con los pods que se ejecutan en los nodos de las subredes privadas.
Para obtener información acerca de las consideraciones de VPC, consulte [Requisitos de red de Amazon EKS para VPC y subredes](network-reqs.md).
Si crea la VPC y los grupos de nodos con las plantillas de AWS CloudFormation incluidas en la explicación de [Introducción a Amazon EKS](getting-started.md), los grupos de seguridad del plano de control y de los nodos se ajustan con la configuración recomendada.
Para obtener más información acerca de las consideraciones del grupo de seguridad, consulte [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md).
Cuando se crea un clúster nuevo, Amazon EKS crea un punto de enlace para el servidor de la API de Kubernetes administrado que utiliza a fin de comunicarse con su clúster (mediante herramientas de administración de Kubernetes como, por ejemplo, `kubectl`). De forma predeterminada, este punto de conexión del servidor de API es público en Internet y el acceso al servidor de API está protegido mediante una combinación de AWS Identity and Access Management (IAM) y el [Control de acceso basado en rol](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) nativo de Kubernetes.
Puede habilitar el acceso privado al servidor de la API de Kubernetes para que toda la comunicación entre los nodos y el servidor de la API permanezcan dentro de su VPC. Puede limitar las direcciones IP que pueden acceder a su servidor de API desde Internet o desactivar por completo el acceso a Internet al servidor de API.
Para obtener más información acerca de la modificación del acceso al punto de conexión del clúster, consulte [Modificar el acceso al punto de conexión del clúster](cluster-endpoint.md#modify-endpoint-access).
Puede implementar *políticas de red* de Kubernetes con la CNI de Amazon VPC o con herramientas de terceros, como [Project Calico](https://docs.tigera.io/calico/latest/about/). Para obtener más información sobre el CNI de Amazon VPC para las políticas de red, consulte [Limitación del tráfico de un pod con políticas de red de Kubernetes](cni-network-policy.md). Project Calico es un proyecto abierto de terceros. Para obtener más información, consulte la [documentación de Project Calico](https://docs.tigera.io/calico/latest/getting-started/kubernetes/managed-public-cloud/eks/).
# Acceso a Amazon EKS con AWS PrivateLink
Puede usar un AWS PrivateLink para crear una conexión privada entre la VPC y Amazon Elastic Kubernetes Service. Puede acceder a Amazon EKS como si estuviera en su VPC, sin el uso de una puerta de enlace de Internet, un dispositivo NAT, una conexión VPN o una conexión AWS Direct Connect. Las instancias de la VPC no necesitan direcciones IP públicas para acceder a Amazon EKS.
Esta conexión privada se establece mediante la creación de un punto de conexión de interfaz alimentado por AWS PrivateLink. Creamos una interfaz de red de punto de conexión en cada subred habilitada para el punto de conexión de interfaz. Se trata de interfaces de red administradas por el solicitante que sirven como punto de entrada para el tráfico destinado a Amazon EKS.
Para obtener más información, consulte [Access AWS services through AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html) en la *Guía de AWS PrivateLink*.
## Antes de empezar
Antes de comenzar, asegúrese de haber realizado las siguientes tareas:
+ Revise [Acceda a un servicio de AWS mediante un punto de conexión de VPC de interfaz](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints) en la *Guía de AWS PrivateLink*
## Consideraciones
+ **Compatibilidad y limitaciones**: los puntos de conexión de la interfaz de Amazon EKS permiten el acceso seguro a todas las acciones de la API de Amazon EKS desde su VPC, pero tienen limitaciones específicas: no admiten el acceso a las API de Kubernetes, ya que estas tienen un punto de conexión privado independiente, no puede configurar Amazon EKS para que solo se pueda acceder a través del punto de conexión de la interfaz.
+ **Precios**: el uso de puntos de conexión de la interfaz para Amazon EKS conlleva cargos estándar de AWS PrivateLink: cargos por hora por cada punto de conexión aprovisionado en cada zona de disponibilidad, cargos por procesamiento de datos por el tráfico a través del punto de conexión. Para obtener más información, consulte [Precios de AWS PrivateLink](https://aws.amazon.com/privatelink/pricing/).
+ **Seguridad y control de acceso**: recomendamos mejorar la seguridad y controlar el acceso con estas configuraciones adicionales: utilice políticas de puntos de conexión de VPC para controlar el acceso a Amazon EKS a través del punto de conexión de la interfaz, asocie grupos de seguridad a las interfaces de red de los puntos de conexión para gestionar el tráfico, utilice registros de flujo de VPC para capturar y supervisar el tráfico IP hacia y desde los puntos de conexión de la interfaz, con registros que se puedan publicar en Amazon CloudWatch o Amazon S3. Para obtener más información, consulte [Uso de políticas de punto de conexión para controlar el acceso a puntos de conexión de VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) y [Registro del tráfico de IP con registros de flujo de la VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html).
+ **Opciones de conectividad**: los puntos de conexión de la interfaz ofrecen opciones de conectividad flexibles mediante el **acceso local** (conecte el centro de datos en las instalaciones a una VPC con el punto de conexión de la interfaz mediante AWS Direct Connect o AWS Site-to-Site VPN) o mediante la **conectividad entre VPC** (utilice AWS Transit Gateway o el emparejamiento de VPC para conectar otras VPC a la VPC con el punto de conexión de la interfaz y mantener el tráfico dentro de la red de AWS).
+ **Compatibilidad con la versión IP**: los puntos de conexión creados antes de agosto de 2024 solo admiten IPv4 con eks.region.amazonaws.com. Los nuevos puntos de conexión creados después de agosto de 2024 admiten IPv4 e IPv6 de doble pila (por ejemplo, eks.region.amazonaws.com, eks.region.api.aws).
+ **Disponibilidad regional**: AWS PrivateLink para la API de EKS no está disponible en las regiones de Asia-Pacífico (Malasia) (ap-southeast-5), Asia-Pacífico (Tailandia) (ap-southeast-7), México (centro) (mx-central-1) y Asia-Pacífico (Taipéi) (ap-east-2). AWS La compatibilidad de PrivateLink con eks-auth (EKS Pod Identity) se encuentra disponible en la región de Asia-Pacífico (Malasia) (ap-southeast-5).
## Crear de un punto de conexión de interfaz para Amazon EKS
Puede crear un punto de conexión de interfaz para Amazon EKS mediante la consola de Amazon VPC o la Interfaz de la línea de comandos de AWS (AWS CLI). Para obtener más información, consulte [Creación de un punto de conexión de VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) en la *Guía de AWS PrivateLink*.
Cree un punto de conexión de interfaz para Amazon EKS con los siguientes nombres de servicios:
### API de EKS
+ com.amazonaws.region-code.eks
+ com.amazonaws.region-code.eks-fips (para puntos de conexión compatibles con FIPS)
### API de autenticación de EKS (Pod Identity de EKS)
+ com.amazonaws.region-code.eks-auth
## Característica de DNS privado para los puntos de conexión de la interfaz de Amazon EKS
La característica de DNS privado, habilitada de forma predeterminada para los puntos de conexión de la interfaz de Amazon EKS y otros servicios de AWS, facilita las solicitudes de API seguras y privadas mediante nombres de DNS regionales predeterminados. Esta característica garantiza que las llamadas de API se enruten a través del punto de conexión de la interfaz a través de la red de AWS privada, lo que mejora la seguridad y el rendimiento.
La característica de DNS privado se activa automáticamente cuando crea un punto de conexión de la interfaz para Amazon EKS u otros servicios de AWS. Para habilitarla, debe configurar la VPC correctamente mediante el establecimiento de atributos específicos:
+ **enableDnsHostnames**: Permite que las instancias dentro de la VPC tengan nombres de host DNS.
+ **enableDnsSupport**: Habilita la resolución de DNS en toda la VPC.
Si desea obtener instrucciones paso a paso para comprobar o modificar estos ajustes, consulte [Ver y actualizar los atributos de DNS de su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating).
### Nombres de DNS y tipos de direcciones IP
Con la característica de DNS privado habilitada, puede usar nombres de DNS específicos para conectarse a Amazon EKS, y estas opciones evolucionan con el tiempo:
+ **eks.region.amazonaws.com**: El nombre de DNS tradicional, que solo se resuelve en direcciones IPv4 antes de agosto de 2024. Para los puntos de conexión existentes actualizados a doble pila, este nombre se resuelve en direcciones IPv4 e IPv6.
+ **eks.region.api.aws**: Disponible para los nuevos puntos de conexión creados después de agosto de 2024, este nombre de DNS de doble pila se resuelve en direcciones IPv4 e IPv6.
A partir de agosto de 2024, los nuevos puntos de conexión de la interfaz vienen con dos nombres de DNS y puede optar por el tipo de dirección IP de doble pila. Para los puntos de conexión existentes, la actualización a doble pila modifica **eks.region.amazonaws.com** para que sea compatible con IPv4 e IPv6.
### Uso de la característica de DNS privado
Una vez configurada, la característica de DNS privado se puede integrar en sus flujos de trabajo y ofrece las siguientes capacidades:
+ **Solicitudes de API**: Utilice los nombres de DNS regionales predeterminados, ya sea `eks.region.amazonaws.com` o `eks.region.api.aws`, según la configuración de su punto de conexión, para realizar solicitudes de API a Amazon EKS.
+ **Compatibilidad con aplicaciones**: Las aplicaciones existentes que utilizan las API de EKS no requieren cambios para aprovechar esta característica.
+ ** AWS CLI con doble pila**: Para usar los puntos de conexión de doble pila con AWS CLI, consulte la [configuración de los puntos de conexión de doble pila y FIPS](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html) en la *Guía de referencia de SDK y herramientas de AWS*.
+ **Enrutamiento automático**: Cualquier llamada al punto de conexión del servicio predeterminado de Amazon EKS se enruta automáticamente a través del punto de conexión de interfaz, lo que garantiza una conectividad privada y segura.
# Comprensión de la resiliencia de los clústeres de Amazon EKS
La infraestructura global de AWS se compone de regiones y zonas de disponibilidad de AWS. AWS Las regiones proporcionan varias zonas de disponibilidad físicamente independientes y aisladas que se encuentran conectadas mediante redes con un alto nivel de rendimiento y redundancia, además de baja latencia. Con las zonas de disponibilidad, puedes diseñar y utilizar aplicaciones y bases de datos que realizan una conmutación por error automática entre zonas de disponibilidad sin interrupciones. Las zonas de disponibilidad tienen una mayor disponibilidad, tolerancia a errores y escalabilidad que las infraestructuras tradicionales de centros de datos únicos o múltiples.
Amazon EKS ejecuta y escala el plano de control de Kubernetes en varias zonas de disponibilidad de AWS para garantizar una alta disponibilidad. Amazon EKS escala de forma automática las instancias del plano de control en función de la carga, detecta y reemplaza instancias del plano de control en mal estado y revisa el plano de control de forma automática. Después de iniciar una actualización de versión, Amazon EKS actualiza el plano de control en su nombre y mantiene una alta disponibilidad durante la actualización.
Este plano de control consta de al menos dos instancias de servidor de la API y tres instancias `etcd` que se ejecutan en tres zonas de disponibilidad de una región de AWS. Amazon EKS:
+ Monitorea de forma activa la carga en las instancias del plano de control y las escala de forma automática para garantizar un alto rendimiento.
+ Detecta y reemplaza de forma automática las instancias del plano de control en mal estado y las reinicia en las zonas de disponibilidad de la región de AWS, según sea necesario.
+ Aprovecha la arquitectura de las regiones de AWS con el fin de mantener una alta disponibilidad. Por este motivo, Amazon EKS puede ofrecer un [acuerdo de nivel de servicio (SLA) de disponibilidad del punto de enlace del servidor de la API](https://aws.amazon.com/eks/sla).
Para obtener más información sobre las zonas de disponibilidad y las regiones de AWS, consulte [Infraestructura global de AWS](https://aws.amazon.com/about-aws/global-infrastructure/).
# Prevención de suplentes confusos entre servicios en Amazon EKS
El problema del suplente confuso es un problema de seguridad en el que una entidad que no tiene permiso para realizar una acción puede obligar a una entidad con más privilegios a realizar la acción. En AWS, la suplantación entre servicios puede dar lugar al problema de la sustitución confusa. La suplantación entre servicios puede producirse cuando un servicio (el *servicio que lleva a cabo las llamadas*) llama a otro servicio (el *servicio al que se llama*). El servicio que lleva a cabo las llamadas se puede manipular para utilizar sus permisos a fin de actuar en función de los recursos de otro cliente de una manera en la que no debe tener permiso para acceder. Para evitarlo, AWS proporciona herramientas que le ayudan a proteger sus datos para todos los servicios con entidades principales de servicio a las que se les ha dado acceso a los recursos de su cuenta.
Se recomienda utilizar las claves de contexto de condición global [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) y [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) en las políticas de recursos para limitar los permisos que Amazon Elastic Kubernetes Service (Amazon EKS) concede a otro servicio para el recurso.
`aws:SourceArn`
Utilice `aws:SourceArn` para asociar solo un recurso al acceso entre servicios.
`aws:SourceAccount`
Utilice `aws:SourceAccount` para permitir que cualquier recurso de esa cuenta se asocie al uso entre servicios.
La forma más eficaz de protegerse contra el problema de la sustitución confusa es utilizar la clave de contexto de condición global de `aws:SourceArn` con el ARN completo del recurso. Si no conoce el ARN completo del recurso o si está especificando varios recursos, utilice la clave de condición de contexto global `aws:SourceArn` con caracteres comodín (\$1) para las partes desconocidas del ARN. Por ejemplo, ` arn:aws::*:<123456789012>:*`.
Si el valor de `aws:SourceArn` no contiene el ID de cuenta, como un ARN de bucket de Amazon S3, debe utilizar `aws:SourceAccount` y `aws:SourceArn` para limitar los permisos.
## Prevención de suplentes confusos entre servicios para el rol del clúster de Amazon EKS
Se requiere un rol de IAM de clúster de Amazon EKS para cada clúster. Los clústeres de Kubernetes administrados por Amazon EKS utilizan este rol para administrar los nodos, y el [proveedor de nube heredado](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) lo usa para crear equilibradores de carga con Elastic Load Balancing para los servicios. Estas acciones de clúster solo pueden afectar a la misma cuenta, por lo que recomendamos que limite cada rol del clúster a ese clúster y esa cuenta. Esta es una aplicación específica de la recomendación de AWS de seguir el *principio de privilegios mínimos* en su cuenta.
**Formato del ARN de origen**
El valor de `aws:SourceArn` debe ser el ARN de un clúster de EKS con el formato ` arn:aws:eks:region:account:cluster/cluster-name `. Por ejemplo, ., ` arn:aws:eks:us-west-2:123456789012:cluster/my-cluster` .
**Formato de la política de confianza para roles de clúster de EKS**
En el ejemplo siguiente se muestra cómo se pueden utilizar las claves de contexto de condición globales `aws:SourceArn` y `aws:SourceAccount` en Amazon EKS para evitar el problema de suplente confuso.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-west-2:123456789012:cluster/my-cluster"
},
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
]
}
```
# Consideraciones de seguridad para Kubernetes
A continuación, se presentan consideraciones de seguridad en la nube que afectan a Kubernetes en clústeres de Amazon EKS. Para obtener una revisión exhaustiva de los controles y prácticas de seguridad de Kubernetes, consulte [Cloud Native Security and Kubernetes](https://kubernetes.io/docs/concepts/security/cloud-native-security/) en la documentación de Kubernetes.
**Topics**
+ [Protección de las cargas de trabajo con certificados de Kubernetes](cert-signing.md)
+ [Comprensión de roles y usuarios de RBAC creados por Amazon EKS](default-roles-users.md)
+ [Cifrado de los secretos de Kubernetes con KMS en los clústeres existentes](enable-kms.md)
+ [Uso de secretos de AWS Secrets Manager con pods de Amazon EKS](manage-secrets.md)
+ [Cifrado de sobre predeterminado para todos los datos de la API de Kubernetes](envelope-encryption.md)
# Protección de las cargas de trabajo con certificados de Kubernetes
La API de certificados de Kubernetes automatiza el aprovisionamiento de credenciales [X.509](https://www.itu.int/rec/T-REC-X.509). La API cuenta con una interfaz de línea de comandos para que los clientes API de Kubernetes soliciten y obtengan [certificados X.509](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/) de una entidad de certificación (CA). Se puede usar un recurso `CertificateSigningRequest` (CSR) para solicitar que un firmante indicado firme el certificado. Las solicitudes se aprueban o se rechazan antes de que se firmen. Kubernetes admite firmantes integrados y personalizados con comportamientos bien definidos. De esta forma, los clientes pueden predecir qué sucede con sus CSR. Para obtener más información sobre la firma de certificados, consulte acerca de la [firma de solicitudes](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/).
Uno de los firmantes integrados es `kubernetes.io/legacy-unknown`. La API `v1beta1` del recurso de CSR honró a este firmante desconocido de legado. Sin embargo, la API estable `v1` de CSR no permite que el `signerName` se establezca en `kubernetes.io/legacy-unknown`.
Si desea utilizar la CA de Amazon EKS para generar certificados en sus clústers, debe usar un firmante personalizado. Para utilizar la versión de la API de CSR `v1` y generar un nuevo certificado, debe migrar cualquier manifiesto y cliente API existentes. Los certificados existentes creados con las API `v1beta1` anteriores son válidas y funcionan hasta que caduque el certificado. Esta incluye lo siguiente:
+ Distribución de confianza: ninguna. No hay confianza o distribución estándar para este firmante en un clúster de Kubernetes.
+ Temas permitidos: cualquiera
+ Extensiones x509 permitidas: honra las extensiones de uso de subjectAltName y clave y descarta otras extensiones
+ Usos de clave permitidos: no debe incluir usos más allá de [“cifrado de clave”, “firma digital”, “autenticación del servidor”]
**nota**
No se admite la firma de certificados de cliente.
+ Vida útil del certificado/caducidad: 1 año (predeterminado y máximo)
+ Bit CA permitido/no permitido: no permitido
## Generación de CSR de ejemplo con signerName
En estos pasos se muestra cómo generar un certificado de publicación para el nombre de DNS `myserver.default.svc` con `signerName: beta.eks.amazonaws.com/app-serving`. Úselo como guía para su propio entorno.
1. Ejecute el comando `openssl genrsa -out myserver.key 2048` para generar una clave privada RSA.
```
openssl genrsa -out myserver.key 2048
```
1. Utilice el siguiente comando para generar una solicitud de certificado.
```
openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc"
```
1. Genere un valor `base64` para la CSR y almacénelo en una variable para utilizarlo en un paso posterior.
```
base_64=$(cat myserver.csr | base64 -w 0 | tr -d "
")
```
1. Ejecute el siguiente comando para crear un archivo llamado `mycsr.yaml`. En el siguiente ejemplo, `beta.eks.amazonaws.com/app-serving` es el `signerName`.
```
cat >mycsr.yaml < myserver.crt
```
# Comprensión de roles y usuarios de RBAC creados por Amazon EKS
Al crear un clúster de Kubernetes, se crean varias identidades de Kubernetes predeterminadas en ese clúster para el correcto funcionamiento de Kubernetes. Amazon EKS crea identidades de Kubernetes para cada uno de sus componentes predeterminados. Las identidades proporcionan un control de autorización basado en roles (RBAC) de Kubernetes para los componentes del clúster. 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.
Al instalar [complementos](eks-add-ons.md) opcionales en el clúster, es posible que se agreguen identidades de Kubernetes adicionales al clúster. Para obtener más información sobre las identidades no abordadas en este tema, consulte la documentación del complemento.
Puede ver la lista de identidades de Kubernetes creadas por Amazon EKS en su clúster mediante la Consola de administración de AWS o la herramienta de línea de comandos de `kubectl`. Todas las identidades de usuario aparecen en los registros de auditoría de `kube` disponibles para los clientes a través de Amazon CloudWatch.
## Consola de administración de AWS
### Requisito previo
La [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que utilice debe tener los permisos que se describen en [Permisos necesarios](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
### Para ver las identidades creadas por Amazon EKS mediante la Consola de administración de AWS
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 las identidades que desea ver.
1. Elija la pestaña **Recursos**.
1. En **Resource types** (Tipos de recursos), elija **Authorization** (Autorización).
1. Elija **ClusterRoles**, **ClusterRoleBindings**, **Roles** o **RoleBindings**. Amazon EKS crea todos los recursos con el prefijo **eks**. Los recursos de identidad adicionales creados por Amazon EKS son los siguientes:
+ El **ClusterRole** y el **ClusterRoleBinding**, que se denominan **aws-node**. Los recursos de **aws-node** admiten el [complemento de la CNI de Amazon VPC para Kubernetes](managing-vpc-cni.md), que Amazon EKS instala en todos los clústeres.
+ Un **ClusterRole** llamado **vpc-resource-controller-role** y un **ClusterRoleBinding** llamado **vpc-resource-controller-rolebinding**. Estos recursos son compatibles con el [controlador de recursos de Amazon VPC](https://github.com/aws/amazon-vpc-resource-controller-k8s), que Amazon EKS instala en todos los clústeres.
Además de los recursos que ve en la consola, existen las siguientes identidades de usuario especiales en su clúster, aunque no están visibles en la configuración del clúster:
+ ** `eks:cluster-bootstrap` **: se utiliza para operaciones de `kubectl` durante el arranque del clúster.
+ ** `eks:support-engineer` ** – se utiliza para operaciones de administración de clústeres.
1. Elija un recurso específico para ver detalles sobre él. De forma predeterminada, se muestra la información en la **Vista estructurada**. En la esquina superior derecha de la página de detalles de la, elija la **vista de sin procesar** para ver toda la información del recurso.
## Kubectl
### Requisito previo
La entidad que utilice (AWS Identity and Access Management [IAM] u OpenID Connect [OIDC]) para enumerar los recursos de Kubernetes del clúster debe estar autenticada por IAM o por su proveedor de identidad de OIDC. Se deben conceder permisos a la entidad para usar los verbos de `get` y `list` de Kubernetes de los recursos del clúster `Role`, `ClusterRole`, `RoleBinding` y `ClusterRoleBinding` con los que desea que trabaje la entidad. Para obtener más información sobre cómo conceder acceso de entidades de IAM a su clúster, consulte [Concesión a los usuarios y roles de IAM de acceso a las API de Kubernetes](grant-k8s-access.md). Para obtener más información sobre cómo conceder acceso de entidades autenticadas mediante su propio proveedor de OIDC a su clúster, consulte [Concesión de acceso a Kubernetes con un proveedor de OIDC externo para los usuarios](authenticate-oidc-identity-provider.md).
### Para ver las identidades creadas por Amazon EKS mediante `kubectl`
Ejecute el comando para el tipo de recurso que desea ver. Todos los recursos devueltos que llevan el prefijo **eks** son creados por Amazon EKS. Además de los recursos devueltos en la salida de los comandos, existen las siguientes identidades de usuario especiales en su clúster, aunque no están visibles en la configuración del clúster:
+ ** `eks:cluster-bootstrap` **: se utiliza para operaciones de `kubectl` durante el arranque del clúster.
+ ** `eks:support-engineer` ** – se utiliza para operaciones de administración de clústeres.
**ClusterRoles**: `ClusterRoles` están dentro del ámbito de su clúster, por lo que cualquier permiso otorgado a un rol se aplica a los recursos de cualquier espacio de nombres de Kubernetes del clúster.
El siguiente comando devuelve todos los `ClusterRoles` de Kubernetes de Amazon EKS creados en su clúster.
```
kubectl get clusterroles | grep eks
```
Además de los `ClusterRoles` devueltos en la salida con el prefijo, existen los siguientes `ClusterRoles`.
+ ** `aws-node` **: este `ClusterRole` es compatible con el [complemento de la CNI de Amazon VPC para Kubernetes](managing-vpc-cni.md), que Amazon EKS instala en todos los clústeres.
+ ** `vpc-resource-controller-role` **: este `ClusterRole` es compatible con el [Controlador de recursos de Amazon VPC](https://github.com/aws/amazon-vpc-resource-controller-k8s), que Amazon EKS instala en todos los clústeres.
Para ver la especificación de un `ClusterRole`, sustituya *eks:k8s-metrics* en el siguiente comando por el `ClusterRole` devuelto en el resultado del comando anterior. El siguiente ejemplo devuelve la especificación de `ClusterRole` *eks:k8s-metrics*.
```
kubectl describe clusterrole eks:k8s-metrics
```
Un ejemplo de salida sería el siguiente.
```
Name: eks:k8s-metrics
Labels:
Annotations:
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
[/metrics] [] [get]
endpoints [] [] [list]
nodes [] [] [list]
pods [] [] [list]
deployments.apps [] [] [list]
```
**ClusterRoleBindings**: `ClusterRoleBindings` está dentro del ámbito de su clúster.
El siguiente comando devuelve todos los `ClusterRoleBindings` de Kubernetes de Amazon EKS creados en su clúster.
```
kubectl get clusterrolebindings | grep eks
```
Además de los `ClusterRoleBindings` devueltos en la salida, existen los siguientes `ClusterRoleBindings`.
+ ** `aws-node` **: este `ClusterRoleBinding` es compatible con el [complemento de la CNI de Amazon VPC para Kubernetes](managing-vpc-cni.md), que Amazon EKS instala en todos los clústeres.
+ ** `vpc-resource-controller-rolebinding` **: este `ClusterRoleBinding` es compatible con el [Controlador de recursos de Amazon VPC](https://github.com/aws/amazon-vpc-resource-controller-k8s), que Amazon EKS instala en todos los clústeres.
Para ver la especificación de un `ClusterRoleBinding`, sustituya *eks:k8s-metrics* en el siguiente comando por el `ClusterRoleBinding` devuelto en el resultado del comando anterior. El siguiente ejemplo devuelve la especificación de `ClusterRoleBinding` *eks:k8s-metrics*.
```
kubectl describe clusterrolebinding eks:k8s-metrics
```
Un ejemplo de salida sería el siguiente.
```
Name: eks:k8s-metrics
Labels:
Annotations:
Role:
Kind: ClusterRole
Name: eks:k8s-metrics
Subjects:
Kind Name Namespace
---- ---- ---------
User eks:k8s-metrics
```
**Roles**: `Roles` se limitan a un espacio de nombres de Kubernetes. Todos los `Roles` de Amazon EKS creados están incluidos en el espacio de nombres de `kube-system`.
El siguiente comando devuelve todos los `Roles` de Kubernetes de Amazon EKS creados en su clúster.
```
kubectl get roles -n kube-system | grep eks
```
Para ver la especificación de un `Role`, sustituya *eks:k8s-metrics* en el siguiente comando por el nombre del `Role` devuelto en el resultado del comando anterior. El siguiente ejemplo devuelve la especificación de `Role` *eks:k8s-metrics*.
```
kubectl describe role eks:k8s-metrics -n kube-system
```
Un ejemplo de salida sería el siguiente.
```
Name: eks:k8s-metrics
Labels:
Annotations:
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
daemonsets.apps [] [aws-node] [get]
deployments.apps [] [vpc-resource-controller] [get]
```
**RoleBindings**: `RoleBindings` se circunscriben a un espacio de nombres de Kubernetes. Todos los `RoleBindings` de Amazon EKS creados están incluidos en el espacio de nombres de `kube-system`.
El siguiente comando devuelve todos los `RoleBindings` de Kubernetes de Amazon EKS creados en su clúster.
```
kubectl get rolebindings -n kube-system | grep eks
```
Para ver la especificación de un `RoleBinding`, sustituya *eks:k8s-metrics* en el siguiente comando por el `RoleBinding` devuelto en el resultado del comando anterior. El siguiente ejemplo devuelve la especificación de `RoleBinding` *eks:k8s-metrics*.
```
kubectl describe rolebinding eks:k8s-metrics -n kube-system
```
Un ejemplo de salida sería el siguiente.
```
Name: eks:k8s-metrics
Labels:
Annotations:
Role:
Kind: Role
Name: eks:k8s-metrics
Subjects:
Kind Name Namespace
---- ---- ---------
User eks:k8s-metrics
```
# Cifrado de los secretos de Kubernetes con KMS en los clústeres existentes
**importante**
Este procedimiento se aplica únicamente a clústeres de EKS que ejecutan la versión 1.27 de Kubernetes o una inferior. Si se ejecuta Kubernetes versión 1.28 o superior, los secretos de Kubernetes están protegidos con cifrado de sobre de forma predeterminada. Para obtener más información, consulte [Cifrado de sobre predeterminado para todos los datos de la API de Kubernetes](envelope-encryption.md).
Si habilita el [cifrado de secretos](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/), los secretos de Kubernetes se cifran con la clave de AWS KMS que seleccione. La clave de KMS debe cumplir las siguientes condiciones:
+ Simétrica
+ Debe poder cifrar y descifrar datos
+ Creada en la misma región de AWS que el clúster
+ Si la clave de KMS se creó en una cuenta diferente, la [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) debe tener acceso a la clave de KMS.
Para obtener más información, consulte [Permitir que las entidades principales de IAM de otras cuentas utilicen una clave de KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html) en la *[Guía para desarrolladores de AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/)*.
**aviso**
No puede desactivar el cifrado de secretos después de habilitarlo. Esta acción es irreversible.
eksctl
Este procedimiento se aplica únicamente a clústeres de EKS que ejecutan la versión 1.27 de Kubernetes o una inferior. Para obtener más información, consulte [Cifrado de sobre predeterminado para todos los datos de la API de Kubernetes](envelope-encryption.md).
Puede habilitar el cifrado de dos formas:
+ Agregue cifrado a su clúster con un solo comando.
Para volver a cifrar los secretos de forma automática, ejecute el siguiente comando.
```
eksctl utils enable-secrets-encryption \
--cluster my-cluster \
--key-arn arn:aws:kms:region-code:account:key/key
```
Para optar por no volver a cifrar los secretos de forma automática, ejecute el siguiente comando.
```
eksctl utils enable-secrets-encryption
--cluster my-cluster \
--key-arn arn:aws:kms:region-code:account:key/key \
--encrypt-existing-secrets=false
```
+ Agregue cifrado al clúster con un archivo `kms-cluster.yaml`.
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: region-code
secretsEncryption:
keyARN: arn:aws:kms:region-code:account:key/key
```
Para que los secretos se vuelvan a cifrar automáticamente, ejecute el siguiente comando.
```
eksctl utils enable-secrets-encryption -f kms-cluster.yaml
```
Para optar por no volver a cifrar los secretos de forma automática, ejecute el siguiente comando.
```
eksctl utils enable-secrets-encryption -f kms-cluster.yaml --encrypt-existing-secrets=false
```
Consola de administración de AWS
1. Este procedimiento se aplica únicamente a clústeres de EKS que ejecutan la versión 1.27 de Kubernetes o una inferior. Para obtener más información, consulte [Cifrado de sobre predeterminado para todos los datos de la API de Kubernetes](envelope-encryption.md).
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Elija el clúster al que desea agregar el cifrado de KMS.
1. Elija la pestaña **Overview** (Resumen) (está seleccionada de manera predeterminada).
1. Desplácese hasta la sección **Secrets encryption** (Cifrado de secretos) y elija **Enable** (Habilitar).
1. Seleccione una clave en el menú desplegable y elija el botón **Enable** (Habilitar). Si no aparece ninguna clave, primero debe crear una. Para obtener más información, consulte [Creación de claves](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html).
1. Elija el botón **Confirm** (Confirmar) para utilizar la clave elegida.
AWS CLI
1. Este procedimiento se aplica únicamente a clústeres de EKS que ejecutan la versión 1.27 de Kubernetes o una inferior. Para obtener más información, consulte [Cifrado de sobre predeterminado para todos los datos de la API de Kubernetes](envelope-encryption.md).
1. Asocie la configuración del [cifrado de secretos](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) con el clúster mediante el siguiente comando de la AWS CLI. Sustituya los valores de ejemplo por sus propios valores.
```
aws eks associate-encryption-config \
--cluster-name my-cluster \
--encryption-config '[{"resources":["secrets"],"provider":{"keyArn":"arn:aws:kms:region-code:account:key/key"}}]'
```
Un ejemplo de salida sería el siguiente.
```
{
"update": {
"id": "3141b835-8103-423a-8e68-12c2521ffa4d",
"status": "InProgress",
"type": "AssociateEncryptionConfig",
"params": [
{
"type": "EncryptionConfig",
"value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws:kms:region-code:account:key/key\"}}]"
}
],
"createdAt": 1613754188.734,
"errors": []
}
}
```
1. Puede monitorear el estado de la actualización de cifrado con el siguiente comando. Utilice la especificación `cluster name` y `update ID` que se devolvió en la salida anterior. Cuando se muestra el estado `Successful`, la actualización se ha completado.
```
aws eks describe-update \
--region region-code \
--name my-cluster \
--update-id 3141b835-8103-423a-8e68-12c2521ffa4d
```
Un ejemplo de salida sería el siguiente.
```
{
"update": {
"id": "3141b835-8103-423a-8e68-12c2521ffa4d",
"status": "Successful",
"type": "AssociateEncryptionConfig",
"params": [
{
"type": "EncryptionConfig",
"value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws:kms:region-code:account:key/key\"}}]"
}
],
"createdAt": 1613754188.734>,
"errors": []
}
}
```
1. Para verificar que el cifrado se encuentra habilitado en el clúster, ejecute el comando `describe-cluster`. La respuesta contiene una cadena de `EncryptionConfig`.
```
aws eks describe-cluster --region region-code --name my-cluster
```
Después de habilitar el cifrado en el clúster, deberá cifrar todos los secretos existentes con la clave nueva:
**nota**
Si usa `eksctl`, solo es necesario ejecutar el siguiente comando si opta por no volver a cifrar sus secretos automáticamente.
```
kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - kms-encryption-timestamp="time value"
```
**aviso**
Si habilita el [cifrado de secretos](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) para un clúster existente y, en algún momento, se elimina la clave de KMS que utiliza, no habrá forma de recuperar el clúster. Si elimina la clave de KMS, coloca el clúster permanentemente en un estado degradado. Para obtener más información, consulte [Eliminación de claves de AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html).
**nota**
De forma predeterminada, el comando `create-key` crea una [clave KMS de cifrado simétrica](https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html) con una política de claves que da al administrador raíz de la cuenta acceso a las acciones y los recursos de AWS KMS. Si desea reducir los permisos, asegúrese de que las acciones `kms:DescribeKey` y `kms:CreateGrant` estén permitidas en la política para la entidad principal que llama a la API `create-cluster`.
Para clústeres que utilizan cifrado de sobres KMS, se requieren permisos `kms:CreateGrant`. La condición `kms:GrantIsForAWSResource` no es compatible con la acción CreateCluster y no debe utilizarse en las políticas de KMS para controlar permisos `kms:CreateGrant` para los usuarios que realizan CreateCluster.
# Uso de secretos de AWS Secrets Manager con pods de Amazon EKS
A fin de mostrar secretos de Secrets Manager y parámetros del Almacén de parámetros como archivos montados en pods de Amazon EKS, puede utilizar el proveedor de secretos y configuración de AWS (ASCP) para el [Controlador CSI del almacén de secretos de Kubernetes](https://secrets-store-csi-driver.sigs.k8s.io/).
Con el ASCP, puede almacenar y administrar sus secretos en Secrets Manager y recuperarlos a través de sus cargas de trabajo que se ejecutan en Amazon EKS. Puede utilizar roles y políticas de IAM para limitar el acceso a sus secretos a pods de Kubernetes específicos de un clúster. El ASCP recupera la identidad del pod e intercambia la identidad por un rol de IAM. El ASCP asume el rol de IAM del pod y, a continuación, puede recuperar secretos de Secrets Manager autorizados para ese rol.
Si utiliza la rotación automática de Secrets Manager para sus secretos, también puede utilizar la característica de conciliador de rotación del controlador de CSI del almacén de secretos a fin de asegurarse de que está recuperando el último secreto de Secrets Manager.
**nota**
No se admiten los grupos de nodos de AWS Fargate (Fargate).
Para obtener más información, consulte [Uso de secretos de Secrets Manager en Amazon EKS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html) en la Guía del usuario de AWS Secrets Manager.
# Cifrado de sobre predeterminado para todos los datos de la API de Kubernetes
Amazon Elastic Kubernetes Service (Amazon EKS) aplica cifrado de sobre de forma predeterminada a todos los datos de la API de Kubernetes en los clústeres que ejecutan la versión 1.28 o superior.
El cifrado de sobre protege los datos almacenados en el servidor de la API de Kubernetes. Por ejemplo, el cifrado de sobre se aplica a la configuración del clúster de Kubernetes, como `ConfigMaps`. El cifrado de sobre no se aplica a los datos almacenados en los nodos ni en los volúmenes de EBS. Anteriormente, EKS permitía cifrar los secretos de Kubernetes; ahora, este cifrado de sobre se extiende a la totalidad de los datos de la API de Kubernetes.
Esto proporciona una experiencia administrada y predeterminada que implementa un enfoque de defensa en profundidad para las aplicaciones de Kubernetes, sin requerir intervención adicional.
Amazon EKS utiliza AWS [Key Management Service (KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) junto con el [proveedor KMS v2 de Kubernetes](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#configuring-the-kms-provider-kms-v2) para ofrecer esta capa adicional de seguridad, mediante una [clave administrada por Amazon Web Services](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk), con la opción de emplear una [clave administrada por el cliente](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) (CMK) de AWS KMS.
## Comprensión del cifrado de sobre
El cifrado de sobre consiste en cifrar los datos en texto plano mediante una clave de cifrado de datos (DEK) antes de enviarlos al almacén de datos (etcd), y luego cifrar la DEK con una clave raíz de KMS, la cual se almacena en un sistema KMS remoto y administrado de forma centralizada (AWS KMS). Esta es una estrategia de defensa en profundidad, ya que protege los datos mediante una clave de cifrado (DEK) y agrega una capa adicional de seguridad al proteger dicha DEK con una clave de cifrado independiente y almacenada de forma segura, conocida como clave de cifrado de clave (KEK).
## Cómo Amazon EKS habilita el cifrado de sobre predeterminado con KMS v2 y AWS KMS
Amazon EKS utiliza [KMS v2](https://etcd.io/docs/v3.5/faq/) para aplicar cifrado de sobre predeterminado a todos los datos de la API en el plano de control administrado de Kubernetes, antes de que se almacenen de forma persistente en la base de datos [etcd](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#kms-v2). Al iniciar, el servidor de la API del clúster genera una clave de cifrado de datos (DEK) a partir de una semilla secreta combinada con datos generados aleatoriamente. Además, al inicio, el servidor de la API realiza una llamada al complemento de KMS para cifrar la semilla de la DEK mediante una clave de cifrado de clave (KEK) remota proporcionada por AWS KMS. Se trata de una llamada única que se ejecuta al inicio del servidor de la API y durante la rotación de la KEK. A continuación, el servidor de la API almacena en caché la semilla DEK cifrada. Después de esto, el servidor de la API utiliza la semilla de la DEK almacenada en caché para generar otras claves de cifrado de datos de un solo uso, basadas en una función de derivación de claves (KDF). Posteriormente, cada una de estas DEK generadas se utiliza una sola vez para cifrar un recurso individual de Kubernetes antes de que se almacene en etcd. El uso de una semilla de la DEK cifrada y almacenada en caché a través de KMS v2 permite que el cifrado de los recursos de Kubernetes en el servidor de la API sea más eficiente y rentable.
**De forma predeterminada, esta KEK es administrada por AWS; no obstante, es posible utilizar una propia de AWS KMS.**
El siguiente diagrama ilustra el proceso de generación y cifrado de una DEK durante el inicio del servidor de la API.
![\[El diagrama ilustra el proceso de generación y cifrado de una DEK durante el inicio del servidor de la API\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/security-generate-dek.png)
El siguiente diagrama de alto nivel ilustra el cifrado de un recurso de Kubernetes antes de su almacenamiento en etcd.
![\[El diagrama de alto nivel ilustra el cifrado de un recurso de Kubernetes antes de su almacenamiento en etcd.\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/security-encrypt-request.png)
## Preguntas frecuentes
### ¿Cómo el cifrado de sobre predeterminado mejora la postura de seguridad del clúster de EKS?
Esta característica reduce tanto la superficie de exposición como el tiempo durante el cual los metadatos y el contenido del cliente permanecen sin cifrado. Con el cifrado de sobre predeterminado, los metadatos y el contenido del cliente permanecen sin cifrado únicamente de forma temporal en la memoria del kube-apiserver, antes de almacenarse en etcd. La memoria del kube-apiserver está protegida mediante el [sistema Nitro](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/the-components-of-the-nitro-system.html). Amazon EKS solo utiliza [instancias de EC2 basadas en Nitro](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.html) para el plano de control administrado de Kubernetes. Estas instancias incorporan mecanismos de control de seguridad diseñados para impedir que cualquier sistema o persona acceda a su memoria.
### ¿Qué versión de Kubernetes debo ejecutar para disponer de esta característica?
Para habilitar el cifrado de sobre de forma predeterminada, el clúster de Amazon EKS debe ejecutar Kubernetes en la versión 1.28 o superior.
### ¿Los datos permanecen seguros si se ejecuta una versión del clúster de Kubernetes que no admite esta característica?
Sí. En AWS, [la seguridad es nuestra máxima prioridad](https://aws.amazon.com/security/). Fundamentamos nuestra transformación digital e innovación en las prácticas recomendadas operativas en términos de seguridad, con el firme compromiso de elevar ese estándar consistentemente.
Todos los datos almacenados en etcd están cifrados a nivel de disco para cada clúster de EKS, sin importar la versión de Kubernetes que se ejecuta. EKS utiliza claves raíz para generar claves de cifrado por volumen, las cuales son administradas por el servicio de EKS. Además, cada clúster de Amazon EKS se ejecuta dentro de una VPC aislada, mediante máquinas virtuales dedicadas al clúster. Gracias a esta arquitectura y a nuestras prácticas de seguridad operativa, Amazon EKS [cumple con múltiples estándares y marcos de conformidad](https://docs.aws.amazon.com/eks/latest/userguide/compliance.html), incluidos SOC 1, 2 y 3, PCI-DSS, ISO y los requisitos de HIPAA. Estos estándares y marcos de cumplimiento se garantizan para todos los clústeres de EKS, independientemente de si utilizan el cifrado de sobre predeterminado.
### ¿Cómo funciona el cifrado de sobre en Amazon EKS?
Al iniciar, el servidor de la API del clúster genera una clave de cifrado de datos (DEK) a partir de una semilla secreta combinada con datos generados aleatoriamente. Asimismo, al iniciar, el servidor de la API llama al complemento de KMS para cifrar la clave de cifrado de datos (DEK) con una clave de cifrado remota (KEK) de AWS KMS. Se trata de una llamada única que se ejecuta al inicio del servidor de la API y durante la rotación de la KEK. A continuación, el servidor de la API almacena en caché la semilla DEK cifrada. Después de esto, el servidor de la API utiliza la semilla de la DEK almacenada en caché para generar otras claves de cifrado de datos de un solo uso, basadas en una función de derivación de claves (KDF). Posteriormente, cada una de estas DEK generadas se utiliza una sola vez para cifrar un recurso individual de Kubernetes antes de que se almacene en etcd.
Es importante tener en cuenta que el servidor de la API realiza llamadas adicionales para verificar el estado y el correcto funcionamiento de la integración con AWS KMS. Estas comprobaciones de estado adicionales se pueden ver en AWS CloudTrail.
### ¿Debo realizar alguna acción o modificar permisos para que esta característica opere en el clúster de EKS?
No, no es necesario realizar ninguna acción. El cifrado de sobre en Amazon EKS es ahora una configuración predeterminada que se encuentra habilitada en todos los clústeres que ejecutan Kubernetes en la versión 1.28 o superior. La integración con AWS KMS se establece mediante el servidor de la API de Kubernetes administrado por AWS. Esto significa que no es necesario configurar permisos para comenzar a utilizar el cifrado con KMS en el clúster.
### ¿Cómo se puede saber si el cifrado de sobre predeterminado está habilitado en el clúster?
Si migra al uso de una CMK propia, podrá visualizar el ARN de la clave de KMS asociada al clúster. Además, puede consultar los registros de eventos de AWS CloudTrail relacionados con el uso de la CMK del clúster.
Si el clúster utiliza una clave propiedad de AWS, esta información se detalla en la consola de EKS (sin incluir el ARN de la clave).
### ¿Puede AWS acceder a la clave propiedad de AWS utilizada para el cifrado de sobre predeterminado en Amazon EKS?
No. AWS aplica controles de seguridad estrictos en Amazon EKS que impiden que cualquier persona acceda a claves de cifrado en texto plano utilizadas para proteger los datos en la base de datos de etcd. Estas medidas de seguridad también se aplican a la clave de KMS propiedad de AWS.
### ¿El cifrado de sobre predeterminado está habilitado en el clúster de EKS existente?
Si ejecuta un clúster de Amazon EKS con Kubernetes en la versión 1.28 o superior, el cifrado de sobre de todos los datos de la API de Kubernetes estará habilitado de forma predeterminada. Para los clústeres existentes, Amazon EKS utiliza el ClusterRole de RBAC denominado `eks:kms-storage-migrator` para migrar los datos que anteriormente no estaban cifrados mediante cifrado de sobre en etcd hacia este nuevo estado de cifrado.
### ¿Qué significa esto si ya habilité el cifrado de sobre para secretos en el clúster de EKS?
Si ya se cuenta con una clave administrada por el cliente (CMK) en KMS que se utilizó para cifrar mediante cifrado de sobre los secretos de Kubernetes, esa misma clave se usará como clave de cifrado (KEK) para el cifrado de sobre de todos los tipos de datos de la API de Kubernetes en el clúster.
### ¿Existe algún costo adicional por ejecutar un clúster de EKS con el cifrado de sobre predeterminado?
No hay ningún costo adicional asociado al plano de control administrado de Kubernetes si se utiliza una [clave propiedad de Amazon Web Services](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) para el cifrado de sobre predeterminado. De forma predeterminada, todo clúster de EKS que ejecute Kubernetes en la versión 1.28 o posterior utiliza una [clave propiedad de Amazon Web Services](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk). Sin embargo, si se utiliza una clave propia de AWS KMS, se aplicarán los [precios estándar de KMS](https://aws.amazon.com/kms/pricing/).
### ¿Cuánto cuesta utilizar una clave propia de AWS KMS para cifrar los datos de la API de Kubernetes en el clúster?
Se paga 1 USD al mes por almacenar cualquier clave personalizada que se cree o se importe a KMS. KMS cobra por las solicitudes de cifrado y descifrado. Existe un nivel gratuito de 20 000 solicitudes por mes y por cuenta, y se paga 0,03 USD por cada 10 000 solicitudes adicionales al mes que superen ese límite. Esto se aplica a todo el uso de KMS dentro de una cuenta, por lo que el costo de utilizar una clave propia de AWS KMS en el clúster se verá afectado por el uso de esa misma clave en otros clústeres o recursos de AWS dentro de la cuenta.
### ¿Aumentarán los cargos de KMS ahora que la clave administrada por el cliente (CMK) se utiliza para cifrar mediante cifrado de sobre todos los datos de la API de Kubernetes y no solo los secretos?
No. Nuestra implementación con KMS v2 reduce significativamente la cantidad de llamadas realizadas a AWS KMS. Esto, a su vez, reducirá los costos relacionados con la CMK, independientemente de los datos adicionales de Kubernetes que se cifren o descifren en el clúster de EKS.
Como se detalla arriba, la semilla de la DEK generada, utilizada para el cifrado de los recursos de Kubernetes, se almacena localmente en la caché del servidor de la API de Kubernetes después de haber sido cifrada con la KEK remota. Si la semilla de la DEK cifrada no se encuentra en la caché del servidor de la API, el servidor de la API realizará una llamada a AWS KMS para cifrar la semilla de DEK. El servidor de la API luego almacena en caché la semilla de la DEK cifrada para su uso futuro en el clúster sin realizar más llamadas a KMS. De manera similar, para las solicitudes de descifrado, el servidor de la API realizará una llamada a AWS KMS para la primera solicitud de descifrado, después de lo cual la semilla de la DEK descifrada se almacenará en caché y se utilizará para futuras operaciones de descifrado.
Para obtener más información, consulte [KEP-3299: KMS v2 Improvements](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/3299-kms-v2-improvements) en las Mejoras de Kubernetes en GitHub.
### ¿Puedo utilizar la misma clave de CMK para varios clústeres de Amazon EKS?
Sí. Para utilizar una clave nuevamente, puede vincularla a un clúster en la misma región al asociar el ARN con el clúster durante su creación. Sin embargo, si utiliza la misma clave de CMK para varios clústeres de EKS, debe tomar las medidas necesarias para evitar la desactivación arbitraria de la clave de CMK. De lo contrario, una clave de CMK desactivada asociada a varios clústeres de EKS tendrá un impacto más amplio en los clústeres que dependan de esa clave.
### ¿Qué ocurre con un clúster de EKS si la CMK queda inaccesible después de habilitar el cifrado de sobre predeterminado?
Si desactiva una clave KMS, no se podrá utilizar en ninguna [operación criptográfica](https://docs.aws.amazon.com/kms/latest/developerguide/kms-cryptography.html#cryptographic-operations). Sin acceso a una CMK existente, el servidor de la API no podrá cifrar ni almacenar de forma persistente objetos de Kubernetes recién creados, ni descifrar objetos de Kubernetes previamente cifrados almacenados en etcd. Si la CMK está desactivada, el clúster se colocará inmediatamente en mal estado o estado degradado, momento en el cual no podremos cumplir con nuestro [compromiso de servicio](https://aws.amazon.com/eks/sla/) hasta que reactivé la CMK asociada.
Cuando una CMK esté desactivada, recibirá notificaciones sobre el estado degradado del clúster de EKS y la necesidad de volver a habilitar la CMK dentro de los 30 días posteriores a su desactivación para garantizar la correcta restauración de los recursos del plano de control de Kubernetes.
### ¿Cómo puedo proteger un clúster de EKS del impacto de una CMK desactivada o eliminada?
Para proteger los clústeres de EKS de una situación como esta, los administradores de claves deben administrar el acceso a las operaciones de claves de KMS mediante políticas de IAM basadas en el principio de privilegio mínimo, con el fin de reducir el riesgo de desactivación o eliminación arbitraria de las claves asociadas con los clústeres de EKS. Además, puede configurar una [alarma de CloudWatch](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys-creating-cloudwatch-alarm.html) para recibir notificaciones sobre el estado de la CMK.
### ¿Se restaurará el clúster de EKS si vuelvo a habilitar la CMK?
Para garantizar la restauración correcta de un clúster de EKS, se recomienda encarecidamente volver a habilitar la CMK dentro de los primeros 30 días de su desactivación. Sin embargo, la restauración exitosa de un clúster de EKS también dependerá de si se producen cambios incompatibles en la API como resultado de una actualización automática de Kubernetes que pueda tener lugar mientras el clúster se encuentre en mal estado o en estado degradado.
### ¿Por qué un clúster de EKS queda en mal estado o en estado degradado después de desactivar la CMK?
El servidor de la API del plano de control de EKS utiliza una clave DEK cifrada y almacenada en caché en la memoria del servidor de la API para cifrar todos los objetos durante las operaciones de creación o actualización, antes de almacenarlos en etcd. Al recuperar un objeto existente desde etcd, el servidor de la API utiliza la misma clave DEK almacenada en caché y descifra el objeto del recurso de Kubernetes. Si se desactiva la CMK, el servidor de la API no experimentará un impacto inmediato debido a la clave DEK almacenada en caché en la memoria del servidor de la API. Sin embargo, al reiniciar la instancia del servidor de la API, no contará con una clave DEK almacenada en caché y deberá llamar a AWS KMS para realizar las operaciones de cifrado y descifrado. Sin una CMK, este proceso fallará con el código de error KMS\$1KEY\$1DISABLED, lo que impedirá que el servidor de la API inicie correctamente.
### ¿Qué ocurre con un clúster de EKS si se elimina la CMK?
Eliminar la clave de CMK asociada con un clúster de EKS degradará su estado de forma irreversible. Sin la CMK del clúster, el servidor de la API ya no podrá cifrar ni almacenar de forma persistente nuevos objetos de Kubernetes, ni descifrar los objetos previamente cifrados almacenados en la base de datos etcd. Debe proceder con la eliminación de una clave de CMK de un clúster de EKS solo cuando tenga la certeza de que ya no se necesita utilizar ese clúster.
Tenga en cuenta que, si no se encuentra la CMK (KMS\$1KEY\$1NOT\$1FOUND) o si se revocan las concesiones de la CMK asociada al clúster (KMS\$1GRANT\$1REVOKED), el clúster no se podrá recuperar. Para obtener más información sobre el estado del clúster y los códigos de error, consulte las [Preguntas frecuentes sobre el estado del clúster y los códigos de error con sus rutas de resolución](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html#cluster-health-status).
### ¿Aún se aplicarán cargos por un clúster de EKS en mal estado o degradado debido a la desactivación o eliminación de la CMK?
Sí. Aunque el plano de control de EKS no se podrá utilizar en caso de desactivación de la CMK, AWS seguirá ejecutando los recursos de infraestructura dedicados asignados al clúster de EKS hasta que el cliente lo elimine. Además, nuestro [compromiso de servicio](https://aws.amazon.com/eks/sla/) no se aplicará en tal circunstancia, ya que se tratará de una acción u omisión voluntaria del cliente la que afecta el estado y funcionamiento normal del clúster de EKS.
### ¿Se puede actualizar un clúster de EKS cuando se encuentra en mal estado o en un estado degradado debido a una CMK desactivada?
Sí. Sin embargo, si el clúster tiene una CMK desactivada, tendrá un periodo de 30 días para volver a activarla. Durante este período de 30 días, el clúster de Kubernetes no se actualizará automáticamente. No obstante, si transcurre el período sin que se vuelva a habilitar la CMK, el clúster se actualizará automáticamente a la siguiente versión (n\$11) con soporte estándar, de acuerdo con el ciclo de vida de versiones de Kubernetes en EKS.
Recomendamos encarecidamente volver a habilitar lo antes posible una CMK desactivada al identificar un clúster afectado. Es importante tener en cuenta que, aunque EKS actualizará automáticamente los clústeres afectados, no se garantiza que estos se recuperen correctamente, especialmente si atraviesan múltiples actualizaciones automáticas, ya que esto puede implicar cambios en la API de Kubernetes y generar comportamientos inesperados en el proceso de arranque del servidor de la API.
### ¿Se puede usar un alias de clave de KMS?
Sí. Amazon EKS [admite el uso de alias de claves de KMS](https://docs.aws.amazon.com/eks/latest/APIReference/API_EncryptionConfig.html#API_EncryptionConfig_Contents). Un alias es un nombre descriptivo asignado a una [clave de KMS de Amazon Web Services](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys). Por ejemplo, un alias permite hacer referencia a una clave de KMS como **my-key** en lugar de usar **`1234abcd-12ab-34cd-56ef-1234567890ab`**.
### ¿Es posible seguir con la copia de seguridad y restauración de los recursos del clúster mediante una solución propia de copia de seguridad para Kubernetes?
Sí. Se puede utilizar una solución de copia de seguridad para Kubernetes (como [Velero](https://velero.io/)) con fines de recuperación ante desastres, migración de datos y protección de datos. Si utiliza una solución de copia de seguridad para Kubernetes que accede a los recursos del clúster a través del servidor de la API, los datos que recupere la aplicación se descifrarán antes de llegar al cliente. Esto permite recuperar los recursos del clúster en otro clúster de Kubernetes.
# Consideraciones de seguridad para el modo automático de Amazon EKS
En este tema se describe la arquitectura de seguridad, los controles y las prácticas recomendadas para el modo automático de Amazon EKS. A medida que las organizaciones implementan aplicaciones en contenedores a escala, resulta cada vez más complejo mantener una postura de seguridad sólida. El modo automático de EKS implementa controles de seguridad automatizados y se integra con servicios de seguridad de AWS para ayudar a proteger la infraestructura del clúster, las cargas de trabajo y los datos. Gracias a las características de seguridad integradas, como la administración forzada del ciclo de vida de los nodos y la implementación automatizada de revisiones, el modo automático de EKS ayuda a seguir las prácticas recomendadas de seguridad a la vez que reduce la sobrecarga operativa.
Antes de continuar con este tema, asegúrese de que conoce los conceptos básicos del modo automático de EKS y de que ha revisado los requisitos previos para habilitar el modo automático de EKS en los clústeres. Para obtener información general sobre la seguridad de Amazon EKS, consulte [Seguridad en Amazon EKS](security.md).
El modo automático de Amazon EKS se basa en los fundamentos de seguridad existentes de Amazon EKS al tiempo que introduce controles de seguridad automatizados adicionales para las instancias administradas de EC2.
## Seguridad y autenticación de la API
El modo automático de Amazon EKS utiliza mecanismos de seguridad de la plataforma de AWS para proteger y autenticar las llamadas a la API de Amazon EKS.
+ El acceso a la API de Kubernetes está protegido mediante entradas de acceso de EKS, que se integran con las identidades de AWS IAM.
+ 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).
+ Los clientes pueden implementar un control de acceso detallado al punto de conexión de la API de Kubernetes mediante la configuración de entradas de acceso de EKS.
## Seguridad de la red
El modo automático de Amazon EKS admite varias capas de seguridad de red:
+ **Integración de la VPC**
+ Funciona dentro de la Amazon Virtual Private Cloud (VPC)
+ Admite configuraciones de VPC y diseños de subred personalizados
+ Habilita las redes privadas entre los componentes del clúster
+ Para obtener más información, consulte [Administración de las responsabilidades de seguridad para Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/security.html)
+ **Políticas de red**
+ Compatibilidad nativa con las políticas de red de Kubernetes
+ Capacidad para definir reglas detalladas de tráfico de red
+ Para obtener más información, consulte [Limitación del tráfico de un pod con políticas de red de Kubernetes](cni-network-policy.md)
## Seguridad de las instancias administradas por EC2
El modo automático de Amazon EKS opera instancias administradas de EC2 con los siguientes controles de seguridad:
### Seguridad de EC2
+ Las instancias administradas por EC2 mantienen las características de seguridad de Amazon EC2.
+ Para obtener más información sobre las instancias administradas por EC2, consulte [Seguridad en Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security.html).
### Administración del ciclo de vida de la instancia
Las instancias administradas de EC2 que funcionan con el modo automático de EKS tienen una vida útil máxima de 21 días. El modo automático de Amazon EKS termina automáticamente las instancias que sobrepasan esta vida útil. Este límite del ciclo de vida ayuda a evitar desviaciones en la configuración y mantiene la postura de seguridad.
### Protección de los datos
+ El almacenamiento de instancias de Amazon EC2 está cifrado. Se trata de almacenamiento directamente conectado a la instancia. Para obtener más información, consulte [Protección de datos en Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html).
+ El modo automático de EKS administra los volúmenes asociados a las instancias de EC2 en el momento de la creación, incluidos los volúmenes raíz y de datos. El modo automático de EKS no administra completamente los volúmenes de EBS creados mediante las características de almacenamiento persistente de Kubernetes.
### Administración de parches
+ El modo automático de Amazon EKS aplica revisiones automáticamente a las instancias administradas.
+ Dentro de las revisiones se incluyen:
+ Actualizaciones del sistema operativo
+ Parches de seguridad
+ Componentes del modo automático de Amazon EKS
**nota**
Los clientes mantienen la responsabilidad de proteger y actualizar las cargas de trabajo que se ejecutan en estas instancias.
### Controles de acceso
+ El acceso directo a la instancia está restringido:
+ El acceso SSH no está disponible.
+ El acceso al Administrador de sesiones de AWS Systems Manager (SSM) no está disponible.
+ Las operaciones de administración se realizan a través de la API de Amazon EKS y la API de Kubernetes.
## Administración automatizada de los recursos
El modo automático de Amazon EKS no administra completamente los volúmenes de Amazon Elastic Block Store (Amazon EBS) creados mediante las características de almacenamiento persistente de Kubernetes. El modo automático de EKS tampoco administra los equilibradores de carga elásticos (ELB). El modo automático de Amazon EKS automatiza las tareas rutinarias de estos recursos.
### Seguridad de almacenamiento
+ AWS recomienda habilitar el cifrado para los volúmenes de EBS aprovisionados por las características de almacenamiento persistente de Kubernetes. Para obtener más información, consulte [Creación de una clase de almacenamiento](create-storage-class.md).
+ Cifrado en reposo mediante AWS KMS
+ Puede configurar su cuenta de AWS para aplicar el cifrado de los nuevos volúmenes de EBS y copias de instantáneas que cree. Para obtener más información, consulte [Cómo habilitar el cifrado de Amazon EBS de forma predeterminada en la Guía del usuario de Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html).
+ Para obtener más información, consulte [Seguridad en Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/security.html).
### Seguridad del equilibrador de carga
+ Configuración automatizada de equilibradores de carga elásticos
+ Administración de certificados SSL/TLS mediante la integración de AWS Certificate Manager
+ Automatización de grupos de seguridad para el control de acceso al equilibrador de carga
+ Para obtener más información, consulte [Seguridad en Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/security.html).
## Prácticas recomendadas de seguridad
La siguiente sección describe las prácticas recomendadas de seguridad aplicables al modo automático de Amazon EKS.
+ Revise periódicamente las políticas de AWS IAM y las entradas de acceso de EKS.
+ Implemente patrones de acceso de privilegio mínimo para las cargas de trabajo.
+ Supervise la actividad del clúster a través de AWS CloudTrail y Amazon CloudWatch. Para obtener más información, consulte [Registrar llamadas a la API como eventos de AWS CloudTrail](logging-using-cloudtrail.md) y [Supervisión de datos de clústeres con Amazon CloudWatch](cloudwatch.md).
+ Utilice AWS Security Hub para evaluar la postura de seguridad.
+ Aplique los estándares de seguridad de pod apropiados para las cargas de trabajo.
# Consideraciones sobre la seguridad para las capacidades de EKS
En este tema, se tratan aspectos de seguridad importantes para las capacidades de EKS, como la configuración de roles de IAM, los permisos de Kubernetes y los patrones de arquitectura para las implementaciones de varios clústeres y la administración de recursos de AWS entre cuentas.
Las capacidades de EKS utilizan una combinación de roles de IAM, entradas de acceso de EKS y RBAC de Kubernetes para proporcionar un acceso seguro a los servicios de AWS, los recursos de Kubernetes en el clúster y las integraciones con AWS CodeConnections, AWS Secrets Manager y otros servicios de AWS.
## Rol de IAM de capacidad
Al crear una capacidad, proporcionará un rol de capacidad de IAM que EKS utiliza para llevar a cabo acciones en su nombre. Este rol debe cumplir con lo siguiente:
+ Debe estar en la misma cuenta de AWS que el clúster y el recurso de capacidad.
+ Debe tener una política de confianza que permita a la entidad principal del servicio de `capabilities.eks.amazonaws.com` asumir el rol.
+ Debe tener los permisos de IAM adecuados para el tipo de capacidad y el caso de uso, en función de sus requisitos. Para obtener información detallada sobre los permisos de IAM necesarios, consulte [Conexión a los repositorios de Git con AWS CodeConnections](integration-codeconnections.md), [Administración de secretos de aplicaciones con AWS Secrets Manager](integration-secrets-manager.md) y [Configuración de los permisos de ACK](ack-permissions.md).
Una práctica recomendada es tener en cuenta el ámbito de los privilegios necesarios para su caso de uso específico y otorgar solo los permisos necesarios para cumplir sus requisitos. Por ejemplo, al utilizar la capacidad de EKS para Kube Resource Orchestrator, es posible que no se requieran permisos de IAM, mientras que, si se utiliza la capacidad de EKS para Controladores de AWS para Kubernetes, puede otorgar acceso completo a uno o más servicios de AWS.
**importante**
Si bien algunos casos de uso pueden justificar el uso de amplios privilegios administrativos, siga el principio de privilegio mínimo y otorgue solo los permisos de IAM mínimos necesarios para su caso de uso específico y restrinja el acceso a recursos específicos mediante ARN y claves de condición en lugar de utilizar permisos comodín.
Para obtener más información sobre cómo crear y configurar roles de IAM de capacidad, consulte [Rol de IAM de capacidad de Amazon EKS](capability-role.md).
## Entradas de acceso de EKS
Al crear una capacidad con un rol de IAM, Amazon EKS crea automáticamente una entrada de acceso para ese rol en el clúster. Esta entrada de acceso otorga a la capacidad los permisos básicos de Kubernetes para funcionar.
**nota**
Las entradas de acceso se crean para el clúster en el que se crea la capacidad. Para las implementaciones de Argo CD en clústeres remotos, debe crear entradas de acceso en esos clústeres con los permisos adecuados para que Argo CD pueda implementar y administrar aplicaciones.
La entrada de acceso incluye lo siguiente:
+ El rol de IAM (ARN) como entidad principal
+ Políticas de entrada de acceso específicas por capacidad que otorgan permisos de línea de base de Kubernetes
+ Ámbito adecuado (en todo el clúster o en el ámbito del espacio de nombres) en función del tipo de capacidad
**nota**
En el caso de Argo CD, los permisos relacionados con el espacio de nombres se otorgan al espacio de nombres especificado en la configuración de la capacidad (el valor predeterminado es `argocd`).
**Políticas de entrada de acceso predeterminadas por capacidad**
Cada tipo de capacidad otorga al rol de capacidad los permisos necesarios y establece diferentes políticas de entrada de acceso predeterminadas, de la siguiente manera:
**kro**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSKROPolicy` (en el ámbito del clúster)
Otorga permisos para ver y administrar ResourceGraphDefinitions y crear instancias de recursos personalizados definidos por las RGD.
**ACK**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSACKPolicy` (en el ámbito del clúster)
Otorga permisos para crear, leer, actualizar y eliminar recursos personalizados de ACK en todos los espacios de nombres.
**Argo CD**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy` (en el ámbito del clúster)
Otorga permisos de clúster para que Argo CD pueda detectar recursos y administrar objetos del ámbito del clúster.
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy` (en el ámbito del espacio de nombres)
Otorga permisos de espacio de nombres para que Argo CD pueda implementar y administrar aplicaciones. Su ámbito es el espacio de nombres especificado en la configuración de la capacidad (el valor predeterminado es `argocd`).
Consulte [Revisión de los permisos de la política de acceso](access-policy-permissions.md) para obtener información más detallada.
## Permisos de Kubernetes adicionales
Algunas capacidades pueden requerir permisos de Kubernetes adicionales además de las políticas de acceso y entrada predeterminadas. Puede otorgar estos permisos de una de las siguientes maneras:
+ **Políticas de entrada de acceso**: asocie políticas administradas adicionales a la entrada de acceso.
+ **RBAC de Kubernetes**: cree enlaces de `Role` o `ClusterRole` para el usuario de Kubernetes de la capacidad.
**Permisos de lector de secretos de ACK**
Algunos controladores de ACK necesitan leer secretos de Kubernetes para recuperar información confidencial, como las contraseñas de las bases de datos. Los siguientes controladores de ACK requieren un acceso de lectura de secretos:
+ `acm`, `acmpca`, `documentdb`, `memorydb`, `mq`, `rds`, `secretsmanager`
Haga lo siguiente para conceder permisos de lectura de secretos:
1. Asocie la política de entrada de acceso `arn:aws:eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy` a la entrada de acceso de la capacidad
1. Limite la política a espacios de nombres específicos en los que los recursos de ACK hagan referencia a secretos u otorguen acceso a todo el clúster
**importante**
Los permisos de lectura de secretos se limitan a los espacios de nombres que especifique al asociar la política de entrada de acceso. Esto le permite limitar los secretos a los que puede acceder la capacidad.
**Permisos de recursos arbitrarios de kro**
kro necesita permisos para crear y administrar los recursos definidos en sus ResourceGraphDefinitions. De forma predeterminada, kro solo puede ver y administrar las RGD por sí mismo.
Puede hacer lo siguiente para otorgar permisos de creación de recursos a kro:
**Opción 1: políticas de entrada de acceso**
Asocie políticas de entrada de acceso predefinidas, como `AmazonEKSAdminPolicy` o `AmazonEKSEditPolicy`, a la entrada de acceso de la capacidad.
**Opción 2: RBAC de Kubernetes**
Cree un `ClusterRoleBinding` que otorgue los permisos necesarios al usuario de Kubernetes de la capacidad:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kro-cluster-admin
subjects:
- kind: User
name: arn:aws:sts::111122223333:assumed-role/my-kro-role/KRO
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
```
**nota**
El nombre de usuario de Kubernetes para kro sigue este patrón: .: `arn:aws:sts::ACCOUNT_ID:assumed-role/ROLE_NAME/KRO`
El nombre de la sesión `/KRO` (en mayúsculas) se establece automáticamente mediante la capacidad kro de EKS.
## Permisos de IAM que necesita la capacidad
**kro (Kube Resource Orchestrator)**
No se necesita ningún permiso de IAM. Puede crear un rol de capacidad sin políticas adjuntas. kro solo necesita los permisos de RBAC de Kubernetes.
**ACK (Controladores de AWS para Kubernetes)**
Necesita permisos para administrar los recursos de AWS que ACK creará y administrará. Debe limitar los permisos a servicios, acciones y recursos específicos en función de sus requisitos. Para obtener información detallada sobre la configuración de los permisos de ACK, lo que incluye las prácticas recomendadas de producción con selectores de roles de IAM, consulte [Configuración de los permisos de ACK](ack-permissions.md).
**Argo CD**
No se necesita ningún permiso de IAM de forma predeterminada. Es posible que se necesiten permisos opcionales para:
+ AWS Secrets Manager: si se almacenan las credenciales del repositorio de Git en Secrets Manager
+ AWS CodeConnections: si utiliza CodeConnections para la autenticación del repositorio de Git
+ Amazon ECR: si utiliza gráficos de Helm almacenados en formato OCI en Amazon ECR
## Prácticas recomendadas de seguridad
### Privilegio mínimo de IAM
Otorgue a sus recursos de capacidad solo los permisos necesarios para su caso de uso. Esto no significa que no pueda conceder amplios permisos administrativos a las capacidades si es necesario. En esos casos, debe gobernar el acceso a esos recursos de manera adecuada.
**Roles de capacidad**:
+ **ACK**: siempre que sea posible, limite los permisos de IAM a recursos y servicios de AWS específicos que necesiten sus equipos, según el caso de uso y los requisitos.
+ **Argo CD**: restrinja el acceso a repositorios de Git y espacios de nombres de Kubernetes específicos.
+ **kro**: necesita un rol de capacidad para la política de confianza, pero no se necesitan permisos de IAM (solo usa RBAC del clúster).
**Ejemplo**: en lugar de `"Resource": "*"`, especifique patrones para recursos o grupos de recursos específicos.
```
"Resource": [
"arn:aws:s3:::my-app-*",
"arn:aws:rds:us-west-2:111122223333:db:prod-*"
]
```
Utilice claves de condición de IAM para restringir aún más el acceso:
```
"Condition": {
"StringEquals": {
"aws:ResourceTag/Environment": "production"
}
}
```
Para obtener información adicional sobre la configuración de IAM, consulte la sección de consideraciones de cada capacidad.
### Aislamiento de espacios de nombres para los secretos de Argo CD
La capacidad de Argo CD administrada tiene acceso a todos los secretos de Kubernetes dentro del espacio de nombres configurado (el valor predeterminado es `argocd`). Para mantener una posición de seguridad óptima, siga estas prácticas de aislamiento de espacios de nombres:
+ Guarde solo los secretos pertinentes para Argo CD en el espacio de nombres de Argo CD.
+ Evite almacenar secretos de aplicaciones no relacionados en el mismo espacio de nombres que Argo CD.
+ Utilice espacios de nombres separados para los secretos de aplicaciones que no sean necesarios para las operaciones de Argo CD.
Este aislamiento garantiza que el acceso a los secretos de Argo CD se limite solo a las credenciales que necesita para la autenticación del repositorio de Git y otras operaciones específicas de Argo CD.
### RBAC de Kubernetes
Controle qué usuarios y cuentas de servicio pueden crear y administrar recursos de capacidad. Una práctica recomendada consiste en implementar recursos de capacidad en espacios de nombres dedicados con políticas de RBAC adecuadas.
Ejemplo: el rol de RBAC funciona con ACK, lo que permite administrar los recursos del bucket de S3 en el espacio de nombres `app-team`:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: ack-s3-manager
namespace: app-team
rules:
- apiGroups: ["s3.services.k8s.aws"]
resources: ["buckets"]
verbs: ["get", "list", "create", "update", "delete"]
```
### Registro de auditoría
**CloudTrail**: todas las operaciones de la API de la capacidad de EKS (crear, actualizar, eliminar) se registran en AWS CloudTrail.
Active el registro de CloudTrail para hacer un seguimiento de lo siguiente:
+ Quién creó o modificó las capacidades
+ Cuándo se cambiaron las configuraciones de las capacidades
+ Qué roles de capacidad se utilizan
### Acceso a la red y puntos de conexión de VPC
#### Acceso privado a la API de Argo CD
Para restringir el acceso al servidor de la API de Argo CD, puede asociar uno o más puntos de conexión de VPC con el punto de conexión de Argo CD alojado. Esto permite la conectividad privada desde dentro de la VPC sin atravesar la Internet pública. El punto de conexión de VPC proporciona acceso tanto a la interfaz web de Argo CD como a la API de Argo CD (incluido el acceso mediante la CLI).
**nota**
Los puntos de conexión de VPC conectados a los puntos de conexión de la API de Argo CD alojados eks-capabilities.*region*.amazonaws.com) no admiten políticas de puntos de conexión de VPC.
#### Implementación en clústeres privados
La capacidad de Argo CD permite implementar aplicaciones en clústeres de EKS completamente privados, lo que proporciona una ventaja operativa significativa al eliminar la necesidad de emparejamiento de VPC o configuraciones de red complejas. Sin embargo, al diseñar esta arquitectura, tenga en cuenta que Argo CD extraerá la configuración de los repositorios de Git (que pueden ser públicos) y la aplicará en clústeres privados.
Asegúrese de lo siguiente:
+ Utilice repositorios de Git privados para cargas de trabajo confidenciales.
+ Implemente los controles de acceso y la autenticación adecuados al repositorio de Git.
+ Revise y apruebe los cambios mediante solicitudes de extracción antes de fusionarlos.
+ Considere la posibilidad de usar los plazos de sincronización de Argo CD para controlar cuándo se pueden producir las implementaciones.
+ Supervise los registros de auditoría de Argo CD para detectar cambios no autorizados en la configuración.
### Conformidad
Las capacidades de EKS están completamente administradas y cuentan con las certificaciones de cumplimiento de Amazon EKS.
Para obtener información actualizada sobre el cumplimiento, consulte [Servicios de AWS en el ámbito del programa de conformidad](https://aws.amazon.com/compliance/services-in-scope/).
## Siguientes pasos
+ [Configuración de los permisos de ACK](ack-permissions.md): configuración de los permisos de IAM para ACK
+ [Configuración de permisos de kro](kro-permissions.md): configuración del RBAC de Kubernetes para kro
+ [Configuración de los permisos de Argo CD](argocd-permissions.md): configuración de la integración de Identity Center para Argo CD
+ [Solución de problemas de capacidades de EKS](capabilities-troubleshooting.md): solución de problemas de seguridad y permisos
# Administración de identidades y accesos para Amazon EKS
AWS Identity and Access Management (IAM) es un servicio de AWS que ayuda a los administradores a controlar de forma segura el acceso a los recursos de AWS. Los administradores de IAM controlan quién está *autenticado* (ha iniciado sesión) y *autorizado* (tiene permisos) para utilizar recursos de Amazon EKS. IAM es un servicio de AWS que puede utilizar sin cargo adicional.
## Público
El modo de utilizar AWS Identity and Access Management (IAM) varía en función del trabajo que se realice en Amazon EKS.
**Usuario de servicio**: si utiliza el servicio Amazon EKS para realizar su trabajo, su administrador proporciona las credenciales y los permisos que necesita. A medida que utilice más características de Amazon EKS para realizar su trabajo, es posible que necesite permisos adicionales. Entender cómo se administra el acceso puede ayudarle a solicitar los permisos correctos al administrador. Si no puede acceder a una característica de Amazon EKS, consulte [Solución de problemas de IAM](security-iam-troubleshoot.md).
**Administrador de servicio**: si está a cargo de los recursos de Amazon EKS de su empresa, probablemente tenga acceso completo a Amazon EKS. Su trabajo consiste en determinar a qué características y recursos de Amazon EKS deben acceder los usuarios del servicio. Luego, debe enviar solicitudes a su administrador de IAM para cambiar los permisos de los usuarios de su servicio. Revise la información de esta página para conocer los conceptos básicos de IAM. Para obtener más información sobre cómo la empresa puede utilizar IAM con Amazon EKS, consulte [Cómo funciona Amazon EKS con IAM](security-iam-service-with-iam.md).
**Administrador de IAM**: si es un administrador de IAM, es posible que desee obtener información sobre cómo escribir políticas para administrar el acceso a Amazon EKS. Para consultar ejemplos de políticas de Amazon EKS basadas en identidades que puede utilizar en IAM, consulte [Ejemplos de políticas de Amazon EKS basadas en identidades](security-iam-id-based-policy-examples.md).
## Autenticación con identidades
La autenticación es la manera de iniciar sesión en AWS mediante credenciales de identidad. Debe estar *autenticado* (haber iniciado sesión en AWS) como usuario raíz de la cuenta de AWS, como un usuario de IAM o asumiendo un rol de IAM.
Puede iniciar sesión en AWS como una identidad federada mediante las credenciales proporcionadas a través de una fuente de identidad. AWS Los usuarios del Centro de identidades de IAM, la autenticación de inicio de sesión único de su empresa y sus credenciales de Google o Facebook son ejemplos de identidades federadas. Al iniciar sesión como una identidad federada, su administrador habrá configurado previamente la federación de identidades mediante roles de IAM. Cuando accede a AWS mediante la federación, está asumiendo un rol de forma indirecta.
Según el tipo de usuario que sea, puede iniciar sesión en Consola de administración de AWS o en el portal de acceso AWS. Para obtener más información sobre el inicio de sesión en AWS, consulte [Cómo iniciar sesión en su cuenta de AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) en la *Guía del usuario de inicio de sesión de AWS*.
Si accede a AWS mediante programación, AWS proporciona un kit de desarrollo de software (SDK) y una interfaz de la línea de comandos (CLI) para firmar criptográficamente las solicitudes mediante el uso de las credenciales. Si no usa las herramientas de AWS, debe firmar las solicitudes. Para obtener más información sobre la firma de solicitudes, consulte [Firma de solicitudes API de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) en la *Guía del usuario de IAM*.
Independientemente del método de autenticación que use, es posible que deba proporcionar información de seguridad adicional. Por ejemplo, AWS le recomienda el uso de la autenticación multifactor (MFA) para aumentar la seguridad de su cuenta. Para obtener más información, consulte [Autenticación multifactor](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html) en la *Guía del usuario de AWS IAM Identity Center* y [Uso de la autenticación multifactor (MFA) en AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) en la *Guía del usuario de IAM*.
### Usuario raíz de la cuenta de AWS
Cuando se crea una cuenta de AWS, se comienza con una identidad de inicio de sesión que tiene acceso completo a todos los servicios y recursos de AWS de la cuenta. Esta identidad recibe el nombre de *usuario raíz* de la cuenta de AWS y se accede a ella iniciando sesión con la dirección de email y la contraseña que utilizó para crear la cuenta. Recomendamos encarecidamente que no utilice el usuario raíz para sus tareas diarias. Proteja las credenciales del Usuario raíz y utilícelas solo para las tareas que solo el Usuario raíz pueda realizar. Para ver la lista completa de las tareas que requieren que inicie sesión como usuario raíz, consulte [Tareas que requieren credenciales de usuario raíz](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) en la *Guía del usuario de IAM*.
### Usuarios y grupos de IAM
Un [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) es una identidad dentro de su cuenta de AWS que dispone de permisos específicos para una sola persona o aplicación. Siempre que sea posible, recomendamos emplear credenciales temporales, en lugar de crear usuarios de IAM que tengan credenciales de larga duración como contraseñas y claves de acceso. No obstante, si tiene casos de uso específicos que requieran credenciales de larga duración con usuarios de IAM, recomendamos rotar las claves de acceso. Para más información, consulte [Rotar las claves de acceso periódicamente para casos de uso que requieran credenciales de larga duración](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials) en la *Guía del usuario de IAM*.
Un [grupo de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) es una identidad que especifica un conjunto de usuarios de IAM. No puede iniciar sesión como grupo. Puede usar grupos para especificar permisos para varios usuarios a la vez. Los grupos facilitan la administración de los permisos de grandes conjuntos de usuarios. Por ejemplo, podría tener un grupo cuyo nombre fuese *IAMAdmins* y conceder permisos a dicho grupo para administrar los recursos de IAM.
Los usuarios son diferentes de los roles. Un usuario se asocia exclusivamente a una persona o aplicación, pero la intención es que cualquier usuario pueda asumir un rol que necesite. Los usuarios tienen credenciales permanentes a largo plazo y los roles proporcionan credenciales temporales. Para más información, consulte [Cuándo crear un usuario de IAM (en lugar de un rol)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose) en la *Guía del usuario de IAM*.
### IAM roles
Un [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) es una identidad dentro de su cuenta de AWS que dispone de permisos específicos. Es similar a un usuario de IAM, pero no está asociado a una determinada persona. Puede asumir temporalmente un rol de IAM en la Consola de administración de AWS [cambiando de roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html). Puede asumir un rol realizando una llamada a una operación de la CLI de AWS o de la API de AWS, o bien utilizando una URL personalizada. Para más información sobre los métodos para el uso de roles, consulte [Uso de roles de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) en la *Guía del usuario de IAM*.
Los roles de IAM con credenciales temporales son útiles en las siguientes situaciones:
+ **Acceso de usuario federado**: para asignar permisos a una identidad federada, puede crear un rol y definir sus permisos. Cuando se autentica una identidad federada, se asocia la identidad al rol y se le conceden los permisos define el rol. Para obtener información acerca de roles para federación, consulte [Creación de un rol para un proveedor de identidades de terceros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) en la *Guía del usuario de IAM*. Si utiliza el IAM Identity Center, debe configurar un conjunto de permisos. IAM Identity Center correlaciona el conjunto de permisos con un rol en IAM para controlar a qué puede acceder las identidades después de autenticarse. Para obtener más información sobre los conjuntos de permisos, consulte [Conjuntos de permisos](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) en la *Guía del usuario de AWS IAM Identity Center*.
+ **Permisos de usuario de IAM temporales**: un usuario de IAM puede asumir un rol de IAM para recibir temporalmente permisos distintos que le permitan realizar una tarea concreta.
+ **Acceso entre cuentas**: puede utilizar un rol de IAM para permitir que alguien (una entidad principal de confianza) de otra cuenta acceda a los recursos de la cuenta. Los roles son la forma principal de conceder acceso entre cuentas. Sin embargo, con algunos servicios de AWS, puede asociar una política directamente a un recurso (en lugar de utilizar un rol como proxy). Para obtener información acerca de la diferencia entre los roles y las políticas basadas en recursos para el acceso entre cuentas, consulta [Acceso a recursos entre cuentas en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) en la *Guía del usuario de IAM*.
+ **Acceso entre servicios**: algunos servicios de AWS utilizan características de otros servicios de AWS. Por ejemplo, cuando realiza una llamada en un servicio, es común que ese servicio ejecute aplicaciones en Amazon EC2 o almacene objetos en Amazon S3. Es posible que un servicio haga esto usando los permisos de la entidad principal, usando un rol de servicio o usando un rol vinculado a un servicio.
+ **Reenviar sesiones de acceso (FAS)**: cuando utiliza un rol o un usuario de IAM para llevar a cabo las acciones en AWS, se le considera una entidad principal. Cuando utiliza algunos servicios, es posible que realice una acción que desencadene otra acción en un servicio diferente. FAS utiliza los permisos de la entidad principal para llamar a un servicio deAWS, combinados con el servicio de AWS solicitante para realizar solicitudes a servicios posteriores. Las solicitudes de FAS solo se realizan cuando un servicio recibe una solicitud que requiere interacciones con otros servicios o recursos de AWS para completarse. En este caso, debe tener permisos para realizar ambas acciones. Para obtener información sobre las políticas a la hora de realizar solicitudes de FAS, consulte [Reenviar sesiones de acceso](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
+ **Rol de servicio**: un rol de servicio es un [rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que adopta un servicio para realizar acciones en su nombre. Un administrador de IAM puede crear, modificar y eliminar un rol de servicio desde IAM. Para obtener más información, consulte [Creación de un rol para delegar permisos a un servicio de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) en la *Guía del usuario de IAM*.
+ **Rol vinculado a un servicio**: un rol vinculado a un servicio es un tipo de función del servicio que está vinculado a un servicio de AWS. El servicio puede asumir el rol para realizar una acción en su nombre. Los roles vinculados a servicios aparecen en la cuenta de AWS y son propiedad del servicio. Un administrador de IAM puede ver, pero no editar, los permisos de los roles vinculados a servicios.
+ **Aplicaciones que se ejecutan en Amazon EC2**: puede utilizar un rol de IAM para administrar credenciales temporales para las aplicaciones que se ejecutan en una instancia de EC2 y realizan solicitudes a la CLI de AWS o a la API de AWS. Es preferible hacerlo de este modo a almacenar claves de acceso en la instancia de EC2. Para asignar un rol de AWS a una instancia de EC2 y ponerla a disposición de todas las aplicaciones, cree un perfil de instancia adjuntado a la instancia. Un perfil de instancia contiene el rol y permite a los programas que se ejecutan en la instancia de EC2 obtener credenciales temporales. Para más información, consulte [Uso de un rol de IAM para conceder permisos a aplicaciones que se ejecutan en instancias Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) en la *Guía del usuario de IAM*.
Para obtener información sobre el uso de los roles de IAM, consulte [Cuándo crear un rol de IAM (en lugar de un usuario)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role) en la *Guía del usuario de IAM*.
## Administración del acceso con políticas
Para controlar el acceso en AWS, se crean políticas y se adjuntan a identidades o recursos de AWS. Una política es un objeto de AWS que, cuando se asocia a una identidad o un recurso, define sus permisos. AWS evalúa estas políticas cuando una entidad principal (sesión de rol, usuario o usuario raíz) realiza una solicitud. Los permisos en las políticas determinan si la solicitud se permite o se deniega. La mayoría de las políticas se almacenan en AWS como documentos JSON. Para obtener más información sobre la estructura y el contenido de los documentos de política JSON, consulte [Información general de políticas JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) en la *Guía del usuario de IAM*.
Los administradores pueden utilizar las políticas JSON de AWS para especificar quién tiene acceso a qué. Es decir, qué **entidad principal** puede realizar **acciones** en qué **recursos** y en qué **condiciones**.
De forma predeterminada, los usuarios y los roles no tienen permisos. Un administrador de IAM puede crear políticas de IAM para conceder permisos a los usuarios para realizar acciones en los recursos que necesitan. A continuación, el administrador puede añadir las políticas de IAM a roles y los usuarios pueden asumirlos.
Las políticas de IAM definen permisos para una acción independientemente del método que se utiliza para realizar la operación. Por ejemplo, suponga que dispone de una política que permite la acción `iam:GetRole`. Un usuario con esa política puede obtener información sobre roles de la Consola de administración de AWS, la AWS CLI o la API de AWS.
### Políticas basadas en identidades
Las políticas basadas en identidad son documentos de políticas de permisos JSON que puede asociar a una identidad, como un usuario de IAM, un grupo de usuarios o un rol. Estas políticas controlan qué acciones pueden realizar los usuarios y los roles, en qué recursos y en qué condiciones. Para obtener más información sobre cómo crear una política basada en identidad, 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*.
Las políticas basadas en identidades pueden clasificarse además como *políticas insertadas* o *políticas administradas*. Las políticas insertadas se integran directamente en un único usuario, grupo o rol. Las políticas administradas son políticas independientes que puede asociar a varios usuarios, grupos y roles de su cuenta de AWS. Las políticas administradas incluyen las políticas administradas por AWS y las políticas administradas por el cliente. Para más información sobre cómo elegir una política administrada o una política insertada, consulte [Elegir entre políticas administradas y políticas insertadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline) en la *Guía del usuario de IAM*.
### Políticas basadas en recursos
Las políticas basadas en recursos son documentos de política JSON que se asocian a un recurso. Los ejemplos de políticas basadas en recursos son las *políticas de confianza de roles* de IAM y las *políticas de bucket* de Amazon S3. En los servicios que admiten políticas basadas en recursos, los administradores de servicios pueden utilizarlos para controlar el acceso a un recurso específico. Para el recurso al que se asocia la política, la política define qué acciones puede realizar una entidad principal especificada en ese recurso y en qué condiciones. Debe [especificar una entidad principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) en una política basada en recursos. Las entidades principales pueden incluir cuentas, usuarios, roles, usuarios federados o servicios de AWS.
Las políticas basadas en recursos son políticas insertadas que se encuentran en ese servicio. No se puede utilizar políticas de IAM administradas por AWS en una política basada en recursos.
### Listas de control de acceso (ACL)
Las listas de control de acceso (ACL) controlan qué entidades principales (miembros de cuentas, usuarios o roles) tienen permisos para acceder a un recurso. Las ACL son similares a las políticas basadas en recursos, aunque no utilizan el formato de documento de políticas JSON.
Amazon S3, AWS WAF y Amazon VPC son ejemplos de servicios que admiten las ACL. Para obtener más información sobre las ACL, consulte [Información general de Lista de control de acceso (ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) en la *Guía para desarrolladores de Amazon Simple Storage Service*.
### Otros tipos de políticas
AWS admite otros tipos de políticas adicionales menos frecuentes. Estos tipos de políticas pueden establecer el máximo de permisos que los tipos de políticas más frecuentes le conceden.
+ **Límites de permisos**: un límite de permisos es una característica avanzada que le permite establecer los permisos máximos que una política basada en identidad puede conceder a una entidad de IAM (usuario o rol de IAM). Puede establecer un límite de permisos para una entidad. Los permisos resultantes son la intersección de las políticas basadas en la identidad de la entidad y los límites de permisos. Las políticas basadas en recursos que especifiquen el usuario o rol en el campo `Principal` no estarán restringidas por el límite de permisos. Una denegación explícita en cualquiera de estas políticas anulará el permiso. Para obtener más información sobre los límites de los permisos, consulte [Límites de permisos para las entidades de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) en la *Guía del usuario de IAM*.
+ **Políticas de control de servicios (SCP)**: las SCP son políticas JSON que especifican los permisos máximos para una organización o unidad organizativa (OU) en AWS Organizations. AWS Organizations es un servicio que le permite agrupar y administrar de forma centralizada varias cuentas de AWS que posee su negocio. Si habilita todas las características en una organización, entonces podrá aplicar políticas de control de servicio (SCP) a una o a todas sus cuentas. Las SCP limitan los permisos de las entidades de las cuentas miembro, incluido cada usuario raíz de la cuenta de AWS. Para obtener más información acerca de SCP y Organizations, consulte [Políticas de control de servicios](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) en la *Guía del usuario de AWS*.
+ **Políticas de sesión**: las políticas de sesión son políticas avanzadas que se pasan como parámetro cuando se crea una sesión temporal mediante programación para un rol o un usuario federado. Los permisos de la sesión resultantes son la intersección de las políticas basadas en identidad del rol y las políticas de la sesión. Los permisos también pueden proceder de una política basada en recursos. Una denegación explícita en cualquiera de estas políticas anulará el permiso. Para más información, consulte [Políticas de sesión](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) en la *Guía del usuario de IAM*.
### Varios tipos de políticas
Cuando se aplican varios tipos de políticas a una solicitud, los permisos resultantes son más complicados de entender. Para obtener información acerca de cómo AWS decide si permitir o no una solicitud cuando hay varios tipos de políticas implicados, consulte [Lógica de evaluación de políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) en la *Guía del usuario de IAM*.
# Cómo funciona Amazon EKS con IAM
Antes de utilizar IAM para administrar el acceso a Amazon EKS, debe conocer qué características de IAM se encuentran disponibles con Amazon EKS. Para obtener una perspectiva general sobre cómo funcionan Amazon EKS y otros servicios de AWS con IAM, consulte [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) en la *Guía del usuario de IAM*.
**Topics**
+ [Políticas de Amazon EKS basadas en identidades](#security-iam-service-with-iam-id-based-policies)
+ [Políticas basadas en recursos de Amazon EKS](#security-iam-service-with-iam-resource-based-policies)
+ [Autorización basada en etiquetas de Amazon EKS](#security-iam-service-with-iam-tags)
+ [Roles de IAM de Amazon EKS](#security-iam-service-with-iam-roles)
## Políticas de Amazon EKS basadas en identidades
Con las políticas basadas en identidades de IAM, puede especificar las acciones y los recursos permitidos o denegados, así como las condiciones en las que se permiten o deniegan las acciones. Amazon EKS admite acciones, claves de condiciones y recursos específicos. Para obtener más información acerca de los elementos que utiliza en una política de JSON, consulte [Referencia de los elementos de las políticas de JSON de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) en la *Guía del usuario de IAM*.
### Acciones
Los administradores pueden utilizar las políticas JSON de AWS para especificar quién tiene acceso a qué. Es decir, qué **entidad principal** puede realizar **acciones** en qué **recursos** y en qué **condiciones**.
El elemento `Action` de una política JSON describe las acciones que puede utilizar para conceder o denegar el acceso en una política. Las acciones de la política generalmente tienen el mismo nombre que la operación de API de AWS asociada. Hay algunas excepciones, como *acciones de solo permiso* que no tienen una operación de API coincidente. También hay algunas operaciones que requieren varias acciones en una política. Estas acciones adicionales se denominan *acciones dependientes*.
Incluya acciones en una política para conceder permisos y así llevar a cabo la operación asociada.
Las acciones de políticas de Amazon EKS utilizan el siguiente prefijo antes de la acción: `eks:`. Por ejemplo, para conceder permiso a alguien para conseguir información descriptiva sobre un clúster de Amazon EKS, incluya la acción `DescribeCluster` en su política. Las instrucciones de la política deben incluir un elemento `Action` o un elemento `NotAction`.
Para especificar varias acciones en una única instrucción, sepárelas con comas del siguiente modo:
```
"Action": ["eks:action1", "eks:action2"]
```
Puede utilizar caracteres comodín para especificar varias acciones (\$1). Por ejemplo, para especificar todas las acciones que comiencen con la palabra `Describe`, incluya la siguiente acción:
```
"Action": "eks:Describe*"
```
Para ver una lista de las acciones de Amazon EKS, 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 de servicio*.
### Recursos
Los administradores pueden utilizar las políticas JSON de AWS para especificar quién tiene acceso a qué. Es decir, qué **entidad principal** puede realizar **acciones** en qué **recursos** y en qué **condiciones**.
El elemento `Resource` de la política JSON especifica el objeto u objetos a los que se aplica la acción. Las instrucciones deben contener un elemento `Resource` o `NotResource`. Como práctica recomendada, especifique un recurso utilizando el [Nombre de recurso de Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Puede hacerlo para acciones que admitan un tipo de recurso específico, conocido como *permisos de nivel de recurso*.
Para las acciones que no admiten permisos de nivel de recurso, como las operaciones de descripción, utilice un carácter asterisco (\$1) para indicar que la instrucción se aplica a todos los recursos.
```
"Resource": "*"
```
El recurso del clúster de Amazon EKS tiene el siguiente ARN.
```
arn:aws:eks:region-code:account-id:cluster/cluster-name
```
Para obtener más información acerca del formato de los ARN, consulte [Nombres de recursos de Amazon (ARN) y espacios de nombres de servicios de AWS](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
Por ejemplo, para especificar el clúster de con el nombre *my-cluster* en su instrucción, utilice el siguiente ARN:
```
"Resource": "arn:aws:eks:region-code:111122223333:cluster/my-cluster"
```
Para especificar todos los clústeres que pertenecen a una cuenta y una región de AWS específicas, utilice el carácter comodín (\$1):
```
"Resource": "arn:aws:eks:region-code:111122223333:cluster/*"
```
Algunas acciones de Amazon EKS, como las que se utilizan para crear recursos, no se pueden llevar a cabo en un recurso específico. En dichos casos, debe utilizar el carácter comodín (\$1).
```
"Resource": "*"
```
Para ver una lista de los tipos de recursos de Amazon EKS y sus ARN, consulte [Recursos definidos por Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-resources-for-iam-policies) en la *Referencia de autorizaciones de servicio*. Para obtener información sobre las acciones con las que puede especificar el ARN de cada recurso, consulte [Acciones definidas por Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).
### Claves de condición
Amazon EKS define su propio conjunto de claves de condición y también admite el uso de algunas claves de condición globales. Para ver todas las claves de condición globales de AWS, consulte [Claves de contexto de condición globales de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) en la *Guía del usuario de IAM*.
Puede establecer claves de condición al asociar un proveedor de OpenID Connect al clúster. Para obtener más información, consulte [Política de IAM de ejemplo](authenticate-oidc-identity-provider.md#oidc-identity-provider-iam-policy).
Todas las acciones de Amazon EC2 admiten las claves de condición `aws:RequestedRegion` y `ec2:Region`. Para obtener más información, consulte [Ejemplo: restricción del acceso a una región de AWS específica](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region).
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).
### Ejemplos
Para ver ejemplos de políticas de Amazon EKS basadas en identidades, consulte [Ejemplos de políticas de Amazon EKS basadas en identidades](security-iam-id-based-policy-examples.md).
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 role-based access control (RBAC, control de acceso basado en roles) 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`.
Para obtener más información sobre cómo trabajar con el ConfigMap, consulte [Concesión a los usuarios y roles de IAM de acceso a las API de Kubernetes](grant-k8s-access.md).
## Políticas basadas en recursos de Amazon EKS
Amazon EKS no admite las políticas basadas en recursos.
## Autorización basada en etiquetas de Amazon EKS
Puede asociar etiquetas a los recursos de Amazon EKS o transferirlas en una solicitud a Amazon EKS. Para controlar el acceso en función de etiquetas, debe proporcionar información de las etiquetas en el [elemento de condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) de una política utilizando las claves de condición `aws:ResourceTag/key-name `, `aws:RequestTag/key-name ` o `aws:TagKeys`. Para obtener más información sobre el etiquetado de recursos de Amazon EKS, consulte [Organización de los recursos de Amazon EKS con etiquetas](eks-using-tags.md). Para obtener más información sobre qué acciones puede usar las etiquetas en las claves de condición de, consulte [Acciones definidas por Amazon EKS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) en la [Referencia de autorizaciones de servicio](https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html).
## Roles de IAM de Amazon EKS
Un [rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) es una entidad de la cuenta de AWS que dispone de permisos específicos.
### Uso de credenciales temporales con Amazon EKS
Puede utilizar credenciales temporales para iniciar sesión con federación, asumir un rol de IAM o asumir un rol de acceso entre cuentas. Puede obtener credenciales de seguridad temporales al llamar a operaciones de la API de STS de AWS, como [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) o [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html).
Amazon EKS admite el uso de credenciales temporales.
### Roles vinculados a servicios
Los [roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) permiten a los servicios de AWS obtener acceso a los recursos de otros servicios para completar una acción en su nombre. Los roles vinculados a servicios aparecen en la cuenta de IAM y son propiedad del servicio. Un administrador puede ver, pero no editar, los permisos de los roles vinculados a servicios.
Amazon EKS admite roles vinculados a servicios. Para obtener más información sobre cómo crear o administrar roles vinculados a servicios de Amazon EKS, consulte [Utilizar roles vinculados a servicios para Amazon EKS](using-service-linked-roles.md).
### Roles de servicio
Esta característica permite que un servicio asuma un [rol de servicio](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-role) en su nombre. Este rol permite que el servicio obtenga acceso a los recursos de otros servicios para completar una acción en su nombre. Los roles de servicio aparecen en su cuenta de IAM y son propiedad de la cuenta. Esto significa que un administrador de IAM puede cambiar los permisos de este rol. Sin embargo, hacerlo podría deteriorar la funcionalidad del servicio.
Amazon EKS admite roles de servicio. Para obtener más información, consulte [Rol de IAM del clúster de Amazon EKS](cluster-iam-role.md) y [Rol de IAM de nodo de Amazon EKS](create-node-role.md).
### Elegir un rol de IAM en Amazon EKS
Cuando se crea un recurso de clúster en Amazon EKS, debe elegir un rol para permitir a Amazon EKS acceder a otros recursos de AWS en su nombre. Si ya ha creado una función del servicio, Amazon EKS proporciona una lista de roles para elegir. Es importante que elija un rol que cuente con políticas administradas de Amazon EKS asociadas a él. Para obtener más información, consulte [Comprobar si existe un rol de clúster existente](cluster-iam-role.md#check-service-role) y [Verificar un rol de nodo existente](create-node-role.md#check-worker-node-role).
# Ejemplos de políticas de Amazon EKS basadas en identidades
De forma predeterminada, los usuarios y roles de IAM no tienen permiso para crear ni modificar recursos de Amazon EKS. Tampoco pueden realizar tareas mediante Consola de administración de AWS, AWS CLI o la API de AWS. Un administrador de IAM debe crear políticas de IAM que concedan permisos a los usuarios y a los roles para realizar operaciones de la API concretas en los recursos especificados que necesiten. El administrador debe adjuntar esas políticas a los usuarios o grupos de IAM que necesiten esos permisos.
Para obtener más información acerca de cómo crear una política basada en identidad de IAM con estos documentos de políticas de JSON de ejemplo, consulte [Creación de políticas en la pestaña JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) en la *Guía del usuario de IAM*.
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 role-based access control (RBAC, control de acceso basado en roles) 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`.
Para obtener más información sobre cómo trabajar con el ConfigMap, consulte [Concesión a los usuarios y roles de IAM de acceso a las API de Kubernetes](grant-k8s-access.md).
**Topics**
+ [Prácticas recomendadas sobre las políticas](#security-iam-service-with-iam-policy-best-practices)
+ [Utilizar la consola de Amazon EKS](#security-iam-id-based-policy-examples-console)
+ [Permitir a los usuarios de IAM ver sus propios permisos](#security-iam-id-based-policy-examples-view-own-permissions)
+ [Creación de un clúster de Kubernetes en la nube de AWS](#policy-create-cluster)
+ [Creación de un clúster local de Kubernetes en un Outpost](#policy-create-local-cluster)
+ [Actualización de un clúster de Kubernetes](#policy-example1)
+ [Enumeración o descripción de todos los clústeres](#policy-example2)
## Prácticas recomendadas sobre las políticas
Las políticas basadas en identidades determinan si alguien puede crear, eliminar o acceder a los recursos de Amazon EKS de su cuenta. Estas acciones pueden generar costos adicionales para su cuenta de AWS. Siga estas directrices y recomendaciones al crear o editar políticas basadas en identidades:
+ **Comience con las políticas administradas por AWS y continúe con los permisos de privilegio mínimo**: a fin de comenzar a conceder permisos a los usuarios y las cargas de trabajo, utilice* las políticas administradas por AWS*, que conceden permisos para muchos casos de uso comunes. Están disponibles en su cuenta de AWS. Se recomienda definir políticas administradas por el cliente de AWS específicas para sus casos de uso a fin de reducir aún más los permisos. Con el fin de obtener más información, consulte las [políticas administradas por AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) o las [políticas administradas por AWS para funciones de tarea](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) en la *Guía de usuario de IAM*.
+ **Aplique permisos de privilegio mínimo**: cuando establezca permisos con políticas de IAM, conceda solo los permisos necesarios para realizar una tarea. Para ello, debe definir las acciones que se pueden llevar a cabo en determinados recursos en condiciones específicas, también conocidos como *permisos de privilegios mínimos*. Con el fin de obtener más información sobre el uso de IAM para aplicar permisos, consulte [Políticas y permisos en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) en la *Guía del usuario de IAM*.
+ **Utilice condiciones en las políticas de IAM para restringir aún más el acceso**: puede agregar una condición a sus políticas para limitar el acceso a las acciones y los recursos. Por ejemplo, puede escribir una condición de políticas para especificar que todas las solicitudes deben enviarse utilizando SSL. También puede usar condiciones para conceder acceso a acciones de servicios si se emplean a través de un servicio determinado de AWS como, por ejemplo, AWS CloudFormation. Para obtener más información, consulte [Elementos de la política de JSON de IAM: Condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) en la *Guía del usuario de IAM*.
+ **Utiliza el analizador de acceso de IAM para validar las políticas de IAM con el fin de garantizar la seguridad y funcionalidad de los permisos**: el analizador de acceso de IAM valida políticas nuevas y existentes para que respeten el lenguaje (JSON) de las políticas de IAM y las prácticas recomendadas de IAM. El analizador de acceso de IAM proporciona más de 100 verificaciones de políticas y recomendaciones procesables para ayudar a crear políticas seguras y funcionales. Para más información, consulte [Política de validación de Analizador de acceso de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) en la *Guía de usuario de IAM*.
+ **Solicite la autenticación multifactor (MFA)**: si se encuentra en una situación en la que necesita un usuario raíz o usuarios de IAM en su cuenta de AWS, active la MFA para mayor seguridad. Para solicitar la MFA cuando se invocan las operaciones de la API, agregue las condiciones de la MFA a sus políticas. Para más información, consulte [Configuración del acceso a una API protegido por MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) en la *Guía de usuario de IAM*.
Para obtener más información sobre las prácticas recomendadas de IAM, consulte las [Prácticas recomendadas de seguridad en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) en la *Guía del usuario de IAM*.
## Utilizar la consola de Amazon EKS
Para acceder a la consola de Amazon EKS, una [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) debe tener un conjunto mínimo de permisos. Estos permisos permiten que la entidad principal enumere y vea detalles sobre los recursos de Amazon EKS en su cuenta de AWS. Si crea una política basada en identidad que sea más restrictiva que el mínimo de permisos necesarios, la consola no funcionará del modo esperado para las entidades principales que tengan esa política adjunta.
Para asegurarse de que las entidades principales de IAM puedan seguir utilizando la consola de Amazon EKS, cree una política con su propio nombre, como `AmazonEKSAdminPolicy`. Adjunte la política a las entidades principales. Para obtener más información, consulte [Adición y eliminación de permisos de identidad de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) en la *Guía del usuario de IAM*.
**importante**
La siguiente política de ejemplo permite que una entidad principal vea información en la pestaña **Configuración** en la consola. Para ver información en las pestañas **Resumen** y **Recursos** en la Consola de administración de AWS, la entidad principal también necesita permisos de Kubernetes. Para obtener más información, consulte [Permisos necesarios](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "eks.amazonaws.com"
}
}
}
]
}
```
No es necesario conceder permisos mínimos para la consola a las entidades principales que solo realizan llamadas a la AWS CLI o a la API de AWS. En su lugar, permite acceso únicamente a las acciones que coincidan con la operación de API que intenta realizar.
## Permitir a los usuarios de IAM ver sus propios permisos
En este ejemplo, se muestra cómo podría crear una política que permita a los usuarios de IAM ver las políticas administradas e insertadas que se asocian a la identidad de sus usuarios. Esta política incluye permisos para completar esta acción en la consola o mediante programación con la CLI de AWS o la API de AWS.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## Creación de un clúster de Kubernetes en la nube de AWS
En esta política de ejemplo se incluyen los permisos mínimos necesarios para crear un clúster de Amazon EKS denominado *my-cluster* en la región de AWS *us-west-2*. Puede reemplazar la región de AWS por la región de AWS en la que desea implementar un clúster. Si ve una advertencia que diga **Las acciones de su política no admiten permisos de nivel de recursos y requieren que elija `All resources` ** en la Consola de administración de AWS, puede omitirla con toda tranquilidad. Si su cuenta ya tiene el rol *AWSServiceRoleForAmazonEKS*, puede quitar la acción `iam:CreateServiceLinkedRole` de la política. Si alguna vez creó un clúster de Amazon EKS en su cuenta, este rol ya existe, a menos que lo haya eliminado.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:CreateCluster",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/eks.amazonaws.com/AWSServiceRoleForAmazonEKS",
"Condition": {
"ForAnyValue:StringEquals": {
"iam:AWSServiceName": "eks"
}
}
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/cluster-role-name"
}
]
}
```
## Creación de un clúster local de Kubernetes en un Outpost
En esta política de ejemplo se incluyen los permisos mínimos necesarios para crear un clúster local de Amazon EKS denominado *my-cluster* en un Outpost en la región de AWS *us-west-2*. Puede reemplazar la región de AWS por la región de AWS en la que desea implementar un clúster. Si ve una advertencia que diga **Las acciones de su política no admiten permisos de nivel de recursos y requieren que elija `All resources` ** en la Consola de administración de AWS, puede omitirla con toda tranquilidad. Si su cuenta ya tiene el rol `AWSServiceRoleForAmazonEKSLocalOutpost`, puede quitar la acción `iam:CreateServiceLinkedRole` de la política. Si alguna vez creó un clúster local de Amazon EKS en un Outpost en su cuenta, este rol ya existe, a menos que lo haya eliminado.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:CreateCluster",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
},
{
"Action": [
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"iam:GetRole"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/outposts.eks-local.amazonaws.com/AWSServiceRoleForAmazonEKSLocalOutpost"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole",
"iam:ListAttachedRolePolicies"
],
"Resource": "arn:aws:iam::111122223333:role/cluster-role-name"
},
{
"Action": [
"iam:CreateInstanceProfile",
"iam:TagInstanceProfile",
"iam:AddRoleToInstanceProfile",
"iam:GetInstanceProfile",
"iam:DeleteInstanceProfile",
"iam:RemoveRoleFromInstanceProfile"
],
"Resource": "arn:aws:iam::*:instance-profile/eks-local-*",
"Effect": "Allow"
}
]
}
```
## Actualización de un clúster de Kubernetes
En esta política de ejemplo se incluyen los permisos mínimos necesarios para actualizar un clúster de Amazon EKS denominado *my-cluster* en la región de AWS us-west-2.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:UpdateClusterVersion",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
}
]
}
```
## Enumeración o descripción de todos los clústeres
En esta política de ejemplo se incluyen los permisos mínimos necesarios para enumerar y describir todos los clústeres de su cuenta. Una [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) tiene que ser capaz de enumerar y describir clústeres para usar el comando de `update-kubeconfig` de AWS CLI.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:DescribeCluster",
"eks:ListClusters"
],
"Resource": "*"
}
]
}
```
# Utilizar roles vinculados a servicios para Amazon EKS
Amazon Elastic Kubernetes Service utiliza [roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) de AWS Identity and Access Management (IAM). Un rol vinculado a servicios es un tipo único de rol de IAM que se encuentra vinculado directamente a Amazon EKS. Los roles vinculados a servicios se encuentran predefinidos por Amazon EKS e incluyen todos los permisos que el servicio requiere para llamar a otros servicios de AWS en su nombre.
**Topics**
+ [Utilizar roles para clústeres de Amazon EKS](using-service-linked-roles-eks.md)
+ [Utilizar roles para grupos de nodos de Amazon EKS](using-service-linked-roles-eks-nodegroups.md)
+ [Utilizar roles para perfiles de Fargate de Amazon EKS](using-service-linked-roles-eks-fargate.md)
+ [Uso de roles para conectar un clúster de Kubernetes a Amazon EKS](using-service-linked-roles-eks-connector.md)
+ [Uso de roles para clústeres locales de Amazon EKS en Outpost](using-service-linked-roles-eks-outpost.md)
+ [Uso de roles para el panel de Amazon EKS](using-service-linked-roles-eks-dashboard.md)
# Utilizar roles para clústeres de Amazon EKS
Amazon Elastic Kubernetes Service utiliza [roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) de AWS Identity and Access Management (IAM). Un rol vinculado a servicios es un tipo único de rol de IAM que se encuentra vinculado directamente a Amazon EKS. Los roles vinculados a servicios se encuentran predefinidos por Amazon EKS e incluyen todos los permisos que el servicio requiere para llamar a otros servicios de AWS en su nombre.
Un rol vinculado a servicios simplifica la configuración de Amazon EKS porque ya no tendrá que agregar de forma manual los permisos necesarios. Amazon EKS define los permisos de sus roles vinculados a servicios y, a menos que esté definido de otra manera, solo Amazon EKS puede asumir sus roles. Los permisos definidos incluyen las políticas de confianza y de permisos, y que la política de permisos no se pueda adjuntar a ninguna otra entidad de IAM.
Solo es posible eliminar un rol vinculado a un servicio después de eliminar sus recursos relacionados. De esta forma, se protegen los recursos de Amazon EKS, ya que se evita que se puedan eliminar accidentalmente permisos de acceso a los recursos.
Para obtener información sobre otros servicios que admiten roles vinculados al servicio, consulte [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) y busque los servicios que muestran **Yes** (Sí) en la columna **Service-linked role** (Rol vinculado al servicio). Seleccione una opción **Sí** con un enlace para ver la documentación acerca del rol vinculado al servicio en cuestión.
## Permisos de roles vinculados a servicios para Amazon EKS
Amazon MSK usa el rol vinculado al servicio denominado `AWSServiceRoleForAmazonEKS`. El rol permite a Amazon EKS administrar clústeres de la cuenta. Las políticas adjuntas permiten que el rol administre los siguientes recursos: interfaces de red, grupos de seguridad, registros y VPC.
**nota**
El rol vinculado al servicio `AWSServiceRoleForAmazonEKS` es distinto del rol requerido para la creación de clústeres. Para obtener más información, consulte [Rol de IAM del clúster de Amazon EKS](cluster-iam-role.md).
El rol vinculado al servicio `AWSServiceRoleForAmazonEKS` confía en los siguientes servicios para asumir el rol:
+ `eks.amazonaws.com`
La política de permisos del rol permite que Amazon EKS realice las siguientes acciones en los recursos especificados:
+ [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html)
Debe configurar permisos para permitir a una entidad de IAM (como un usuario, grupo o rol) crear, editar o eliminar un rol vinculado a servicios. Para obtener más información, consulte [Permisos de roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) en la *Guía del usuario de IAM*.
## Crear un rol vinculado a servicios para Amazon EKS
No necesita crear un rol vinculado a servicios de manera manual. Cuando crea un clúster en la Consola de administración de AWS, la AWS CLI, o la API de AWS, Amazon EKS crea el rol vinculado a servicios en su nombre.
Si elimina este rol vinculado a servicios y necesita crearlo de nuevo, puede utilizar el mismo proceso para volver a crear el rol en su cuenta. Al crear un clúster, Amazon EKS se encarga de crear de nuevo el rol vinculado a servicios en su nombre.
## Editar un rol vinculado a servicios para Amazon EKS
Amazon EKS no permite editar el rol vinculado a servicios de `AWSServiceRoleForAmazonEKS`. Después de crear un rol vinculado al servicio, no podrá cambiar el nombre del rol, ya que varias entidades podrían hacer referencia al rol. Sin embargo, sí puede editar la descripción del rol con IAM. Para obtener más información, consulte [Editing a service-linked role (Editar un rol vinculado a servicios)](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) en la *Guía del usuario de IAM*.
## Eliminar un rol vinculado a servicios para Amazon EKS
Si ya no necesita usar una característica o servicio que requieran un rol vinculado a un servicio, le recomendamos que elimine dicho rol. De esta forma, no tiene una entidad no utilizada que no se monitoree ni mantenga de forma activa. Sin embargo, debe limpiar el rol vinculado a servicios antes de eliminarlo manualmente.
### Limpiar un rol vinculado a servicios
Antes de que pueda utilizar IAM para eliminar un rol vinculado a servicios, primero debe eliminar los recursos que utiliza el rol.
**nota**
Si el servicio de Amazon EKS utiliza el rol cuando intenta eliminar los recursos, la eliminación podría producir un error. En tal caso, espere unos minutos e intente de nuevo la operación.
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. En el panel de navegación izquierdo, elija **Clusters (Clústeres)**.
1. Si el clúster tiene grupos de nodos o perfiles de Fargate, debe eliminarlos para poder eliminar el clúster. Para obtener más información, consulte [Eliminación de un grupo de nodos administrado de un clúster](delete-managed-node-group.md) y [Eliminación de un perfil de Fargate](delete-fargate-profile.md).
1. En la página **Clusters (Clústeres)**, elija el clúster que desea eliminar y elija **Delete (Eliminar)**.
1. Escriba el nombre del clúster en la ventana de confirmación de eliminación y, a continuación, elija **Delete (Eliminar)**.
1. Repita este procedimiento para el resto de los clústeres de la cuenta. Espere a que finalicen todas las operaciones de eliminación.
### Eliminación manual de un rol vinculado a servicios
Utilice la consola de IAM, la CLI de AWS o la API de AWS para eliminar el rol vinculado al servicio de `AWSServiceRoleForAmazonEKS`. Para obtener más información, consulte [Eliminar un rol vinculado a un servicio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) en la *Guía del usuario de IAM*.
## Regiones admitidas para los roles vinculados a servicios de Amazon EKS
Amazon EKS admite el uso de roles vinculados a servicios en todas las regiones en las que se encuentra disponible el servicio. Para obtener más información, consulte [Cuotas y puntos de conexión de Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# Utilizar roles para grupos de nodos de Amazon EKS
Amazon EKS utiliza [roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) de AWS Identity and Access Management (IAM). Un rol vinculado a servicios es un tipo único de rol de IAM que se encuentra vinculado directamente a Amazon EKS. Los roles vinculados a servicios se encuentran predefinidos por Amazon EKS e incluyen todos los permisos que el servicio requiere para llamar a otros servicios de AWS en su nombre.
Un rol vinculado a servicios simplifica la configuración de Amazon EKS porque ya no tendrá que agregar de forma manual los permisos necesarios. Amazon EKS define los permisos de sus roles vinculados a servicios y, a menos que esté definido de otra manera, solo Amazon EKS puede asumir sus roles. Los permisos definidos incluyen las políticas de confianza y de permisos, y que la política de permisos no se pueda adjuntar a ninguna otra entidad de IAM.
Solo es posible eliminar un rol vinculado a un servicio después de eliminar sus recursos relacionados. De esta forma, se protegen los recursos de Amazon EKS, ya que se evita que se puedan eliminar accidentalmente permisos de acceso a los recursos.
Para obtener información sobre otros servicios que admiten roles vinculados al servicio, consulte [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) y busque los servicios que muestran **Yes** (Sí) en la columna **Service-linked role** (Rol vinculado al servicio). Seleccione una opción **Sí** con un enlace para ver la documentación acerca del rol vinculado al servicio en cuestión.
## Permisos de roles vinculados a servicios para Amazon EKS
Amazon MSK usa el rol vinculado al servicio denominado `AWSServiceRoleForAmazonEKSNodegroup`. El rol permite a Amazon EKS administrar grupos de nodos de la cuenta. La política asociada de `AWSServiceRoleForAmazonEKSNodegroup` permite al rol administrar los siguientes recursos: grupos de escalado automático, grupos de seguridad, plantillas de lanzamiento y perfiles de instancia de IAM. Para obtener más información, consulte [Política administrada de AWS: AWSServiceRoleForAmazonEKSNodegroup](security-iam-awsmanpol.md#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup).
El rol vinculado al servicio `AWSServiceRoleForAmazonEKSNodegroup` confía en los siguientes servicios para asumir el rol:
+ `eks-nodegroup.amazonaws.com`
La política de permisos del rol permite que Amazon EKS realice las siguientes acciones en los recursos especificados:
+ [AWSServiceRoleForAmazonEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html)
Debe configurar permisos para permitir a una entidad de IAM (como un usuario, grupo o rol) crear, editar o eliminar un rol vinculado a servicios. Para obtener más información, consulte [Permisos de roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) en la *Guía del usuario de IAM*.
## Crear un rol vinculado a servicios para Amazon EKS
No necesita crear un rol vinculado a servicios de manera manual. Cuando ejecuta CreateNodegroup en la Consola de administración de AWS, la AWS CLI, o la API de AWS, Amazon EKS crea el rol vinculado a servicios en su nombre.
**importante**
Este rol vinculado a servicios puede aparecer en su cuenta si se ha completado una acción en otro servicio que utilice las características compatibles con este rol. Si utilizaba el servicio de Amazon EKS antes del 1 de enero de 2017, fecha en que comenzó a admitir los roles vinculados a servicios, Amazon EKS creó el rol AWSServiceRoleForAmazonEKSNodegroup en su cuenta. Para obtener más información, consulte [Un nuevo rol ha aparecido en mi cuenta de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
### Crear un rol vinculado a servicios en Amazon EKS (API de AWS)
No necesita crear un rol vinculado a servicios de manera manual. Cuando crea un grupo de nodos administrados en la Consola de administración de AWS, la AWS CLI o la API de AWS, Amazon EKS crea el rol vinculado a servicios en su nombre.
Si elimina este rol vinculado a servicios y necesita crearlo de nuevo, puede utilizar el mismo proceso para volver a crear el rol en su cuenta. Cuando crea otro grupo de nodos administrado, Amazon EKS vuelve a crear el rol vinculado a servicios.
## Editar un rol vinculado a servicios para Amazon EKS
Amazon EKS no permite editar el rol vinculado a servicios de `AWSServiceRoleForAmazonEKSNodegroup`. Después de crear un rol vinculado al servicio, no podrá cambiar el nombre del rol, ya que varias entidades podrían hacer referencia al rol. Sin embargo, sí puede editar la descripción del rol con IAM. Para obtener más información, consulte [Editing a service-linked role (Editar un rol vinculado a servicios)](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) en la *Guía del usuario de IAM*.
## Eliminar un rol vinculado a servicios para Amazon EKS
Si ya no necesita usar una característica o servicio que requieran un rol vinculado a un servicio, le recomendamos que elimine dicho rol. De esta forma, no tiene una entidad no utilizada que no se monitoree ni mantenga de forma activa. Sin embargo, debe limpiar el rol vinculado a servicios antes de eliminarlo manualmente.
### Limpiar un rol vinculado a servicios
Antes de que pueda utilizar IAM para eliminar un rol vinculado a servicios, primero debe eliminar los recursos que utiliza el rol.
**nota**
Si el servicio de Amazon EKS utiliza el rol cuando intenta eliminar los recursos, la eliminación podría producir un error. En tal caso, espere unos minutos e intente de nuevo la operación.
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. En el panel de navegación izquierdo, elija **Clusters (Clústeres)**.
1. Seleccione la pestaña **Compute** (Informática).
1. En la sección de **Node Groups** (Grupos de nodos), elija el grupo de nodos que desea eliminar.
1. Escriba el nombre del grupo de nodos en la ventana de confirmación de eliminación y, a continuación, elija **Delete (Eliminar)**.
1. Repita este procedimiento para los demás grupos de nodos del clúster. Espere a que finalicen todas las operaciones de eliminación.
### Eliminación manual de un rol vinculado a servicios
Utilice la consola de IAM, la CLI de AWS o la API de AWS para eliminar el rol vinculado al servicio de `AWSServiceRoleForAmazonEKSNodegroup`. Para obtener más información, consulte [Eliminar un rol vinculado a un servicio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) en la *Guía del usuario de IAM*.
## Regiones admitidas para los roles vinculados a servicios de Amazon EKS
Amazon EKS admite el uso de roles vinculados a servicios en todas las regiones en las que se encuentra disponible el servicio. Para obtener más información, consulte [Cuotas y puntos de conexión de Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# Utilizar roles para perfiles de Fargate de Amazon EKS
Amazon EKS utiliza [roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) de AWS Identity and Access Management (IAM). Un rol vinculado a servicios es un tipo único de rol de IAM que se encuentra vinculado directamente a Amazon EKS. Los roles vinculados a servicios se encuentran predefinidos por Amazon EKS e incluyen todos los permisos que el servicio requiere para llamar a otros servicios de AWS en su nombre.
Un rol vinculado a servicios simplifica la configuración de Amazon EKS porque ya no tendrá que agregar de forma manual los permisos necesarios. Amazon EKS define los permisos de sus roles vinculados a servicios y, a menos que esté definido de otra manera, solo Amazon EKS puede asumir sus roles. Los permisos definidos incluyen las políticas de confianza y de permisos, y que la política de permisos no se pueda adjuntar a ninguna otra entidad de IAM.
Solo es posible eliminar un rol vinculado a un servicio después de eliminar sus recursos relacionados. De esta forma, se protegen los recursos de Amazon EKS, ya que se evita que se puedan eliminar accidentalmente permisos de acceso a los recursos.
Para obtener información sobre otros servicios que admiten roles vinculados al servicio, consulte [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) y busque los servicios que muestran **Yes** (Sí) en la columna **Service-linked role** (Rol vinculado al servicio). Seleccione una opción **Sí** con un enlace para ver la documentación acerca del rol vinculado al servicio en cuestión.
## Permisos de roles vinculados a servicios para Amazon EKS
Amazon MSK usa el rol vinculado al servicio denominado `AWSServiceRoleForAmazonEKSForFargate`. El rol permite a Fargate de Amazon EKS configurar la red de VPC que los pods de Fargate necesitan. Las políticas asociadas permiten que el rol cree y elimine interfaces de red elásticas y describa los recursos y las interfaces de red elásticas.
El rol vinculado al servicio `AWSServiceRoleForAmazonEKSForFargate` depende de los siguientes servicios para asumir el rol:
+ `eks-fargate.amazonaws.com`
La política de permisos del rol permite que Amazon EKS realice las siguientes acciones en los recursos especificados:
+ [AmazonEKSForFargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html)
Debe configurar permisos para permitir a una entidad de IAM (como un usuario, grupo o rol) crear, editar o eliminar un rol vinculado a servicios. Para obtener más información, consulte [Permisos de roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) en la *Guía del usuario de IAM*.
## Crear un rol vinculado a servicios para Amazon EKS
No necesita crear un rol vinculado a servicios de manera manual. Cuando crea un perfil de Fargate en la Consola de administración de AWS, la AWS CLI, o la API de AWS, Amazon EKS crea el rol vinculado a servicios en su nombre.
**importante**
Este rol vinculado a servicios puede aparecer en su cuenta si se ha completado una acción en otro servicio que utilice las características compatibles con este rol. Si utilizaba el servicio de Amazon EKS antes del 13 de diciembre de 2019, fecha en que comenzó a admitir los roles vinculados a servicios, Amazon EKS creó el rol AWSServiceRoleForAmazonEKSForFargate en su cuenta. Para obtener más información, consulte [Un nuevo rol ha aparecido en mi cuenta de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
### Crear un rol vinculado a servicios en Amazon EKS (API de AWS)
No necesita crear un rol vinculado a servicios de manera manual. Cuando crea un perfil de Fargate en la Consola de administración de AWS, la AWS CLI, o la API de AWS, Amazon EKS crea el rol vinculado a servicios en su nombre.
Si elimina este rol vinculado a servicios y necesita crearlo de nuevo, puede utilizar el mismo proceso para volver a crear el rol en su cuenta. Cuando crea otro grupo de nodos administrado, Amazon EKS vuelve a crear el rol vinculado a servicios.
## Editar un rol vinculado a servicios para Amazon EKS
Amazon EKS no permite editar el rol vinculado a servicios de `AWSServiceRoleForAmazonEKSForFargate`. Después de crear un rol vinculado al servicio, no podrá cambiar el nombre del rol, ya que varias entidades podrían hacer referencia al rol. Sin embargo, sí puede editar la descripción del rol con IAM. Para obtener más información, consulte [Editing a service-linked role (Editar un rol vinculado a servicios)](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) en la *Guía del usuario de IAM*.
## Eliminar un rol vinculado a servicios para Amazon EKS
Si ya no necesita usar una característica o servicio que requieran un rol vinculado a un servicio, le recomendamos que elimine dicho rol. De esta forma, no tiene una entidad no utilizada que no se monitoree ni mantenga de forma activa. Sin embargo, debe limpiar el rol vinculado a servicios antes de eliminarlo manualmente.
### Limpiar un rol vinculado a servicios
Antes de que pueda utilizar IAM para eliminar un rol vinculado a servicios, primero debe eliminar los recursos que utiliza el rol.
**nota**
Si el servicio de Amazon EKS utiliza el rol cuando intenta eliminar los recursos, la eliminación podría producir un error. En tal caso, espere unos minutos e intente de nuevo la operación.
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. En el panel de navegación izquierdo, elija **Clusters (Clústeres)**.
1. En la página **Clusters (Clústeres)**, seleccione el clúster.
1. Seleccione la pestaña **Compute** (Informática).
1. Si hay algún perfil de Fargate en la sección de **Fargate Profiles** (Perfiles de Fargate), seleccione cada uno de forma individual y, a continuación, elija **Delete** (Eliminar).
1. Escriba el nombre del perfil en la ventana de confirmación de eliminación y, a continuación, elija **Delete (Eliminar)**.
1. Repita este procedimiento para cualquier otro perfil de Fargate del clúster y cualquier otro clúster de su cuenta.
### Eliminación manual de un rol vinculado a servicios
Utilice la consola de IAM, la AWS CLI o la API de AWS para eliminar el rol vinculado a servicios AWSServiceRoleForAmazonEKSForFargate. Para obtener más información, consulte [Eliminar un rol vinculado a un servicio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) en la *Guía del usuario de IAM*.
## Regiones admitidas para los roles vinculados a servicios de Amazon EKS
Amazon EKS admite el uso de roles vinculados a servicios en todas las regiones en las que se encuentra disponible el servicio. Para obtener más información, consulte [Cuotas y puntos de conexión de Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# Uso de roles para conectar un clúster de Kubernetes a Amazon EKS
Amazon EKS utiliza [roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) de AWS Identity and Access Management (IAM). Un rol vinculado a servicios es un tipo único de rol de IAM que se encuentra vinculado directamente a Amazon EKS. Los roles vinculados a servicios se encuentran predefinidos por Amazon EKS e incluyen todos los permisos que el servicio requiere para llamar a otros servicios de AWS en su nombre.
Un rol vinculado a servicios simplifica la configuración de Amazon EKS porque ya no tendrá que agregar de forma manual los permisos necesarios. Amazon EKS define los permisos de sus roles vinculados a servicios y, a menos que esté definido de otra manera, solo Amazon EKS puede asumir sus roles. Los permisos definidos incluyen las políticas de confianza y de permisos, y que la política de permisos no se pueda adjuntar a ninguna otra entidad de IAM.
Solo es posible eliminar un rol vinculado a un servicio después de eliminar sus recursos relacionados. De esta forma, se protegen los recursos de Amazon EKS, ya que se evita que se puedan eliminar accidentalmente permisos de acceso a los recursos.
Para obtener información sobre otros servicios que admiten roles vinculados a servicios, consulte [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) y busque los servicios que muestran **Sí** en la columna **Rol vinculado a servicios**. Seleccione una opción **Sí** con un enlace para ver la documentación acerca del rol vinculado al servicio en cuestión.
## Permisos de roles vinculados a servicios para Amazon EKS
Amazon MSK usa el rol vinculado al servicio denominado `AWSServiceRoleForAmazonEKSConnector`. El rol permite a Amazon EKS conectar clústeres de Kubernetes. Las políticas adjuntas permiten que el rol administre los recursos necesarios para conectarse al clúster de Kubernetes registrado.
El rol vinculado al servicio `AWSServiceRoleForAmazonEKSConnector` depende de los siguientes servicios para asumir el rol:
+ `eks-connector.amazonaws.com`
La política de permisos del rol permite que Amazon EKS realice las siguientes acciones en los recursos especificados:
+ [AmazonEKSConnectorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html)
Debe configurar permisos para permitir a una entidad de IAM (como un usuario, grupo o rol) crear, editar o eliminar un rol vinculado a servicios. Para obtener más información, consulte [Permisos de roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) en la *Guía del usuario de IAM*.
Este rol usa permisos de SSM (Systems Manager) para establecer conexiones seguras y administrar los clústeres de Kubernetes conectados.
## Crear un rol vinculado a servicios para Amazon EKS
No necesita crear un rol vinculado a servicios de forma manual para conectar un clúster. Cuando conecta un clúster en la Consola de administración de AWS, la AWS CLI, `eksctl` o la API de AWS, Amazon EKS crea el rol vinculado a servicios en su nombre.
Si elimina este rol vinculado a servicios y necesita crearlo de nuevo, puede utilizar el mismo proceso para volver a crear el rol en su cuenta. Al conectar un clúster, Amazon EKS crea de nuevo el rol vinculado a servicios en su nombre.
## Editar un rol vinculado a servicios para Amazon EKS
Amazon EKS no permite editar el rol vinculado a servicios de `AWSServiceRoleForAmazonEKSConnector`. Después de crear un rol vinculado al servicio, no podrá cambiar el nombre del rol, ya que varias entidades podrían hacer referencia al rol. Sin embargo, sí puede editar la descripción del rol con IAM. Para obtener más información, consulte [Editing a service-linked role (Editar un rol vinculado a servicios)](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) en la *Guía del usuario de IAM*.
## Eliminar un rol vinculado a servicios para Amazon EKS
Si ya no necesita usar una característica o servicio que requieran un rol vinculado a un servicio, le recomendamos que elimine dicho rol. De esta forma, no tiene una entidad no utilizada que no se monitoree ni mantenga de forma activa. Sin embargo, debe limpiar el rol vinculado a servicios antes de eliminarlo manualmente.
### Limpiar un rol vinculado a servicios
Antes de que pueda utilizar IAM para eliminar un rol vinculado a servicios, primero debe eliminar los recursos que utiliza el rol.
**nota**
Si el servicio de Amazon EKS utiliza el rol cuando intenta eliminar los recursos, la eliminación podría producir un error. En tal caso, espere unos minutos e intente de nuevo la operación.
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. En el panel de navegación izquierdo, elija **Clusters (Clústeres)**.
1. En la página **Clusters (Clústeres)**, seleccione el clúster.
1. Seleccione la pestaña **Deregister (Anular registro)** y, a continuación, la pestaña **OK (Aceptar)**.
### Eliminación manual de un rol vinculado a servicios
Utilice la consola de IAM, la AWS CLI o la API de AWS para eliminar el rol vinculado a servicios AWSServiceRoleForAmazonEKSConnector. Para obtener más información, consulte [Eliminación de un rol vinculado a un servicio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) en la *Guía del usuario de IAM*.
# Uso de roles para clústeres locales de Amazon EKS en Outpost
Amazon Elastic Kubernetes Service utiliza [roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) de AWS Identity and Access Management (IAM). Un rol vinculado a servicios es un tipo único de rol de IAM que se encuentra vinculado directamente a Amazon EKS. Los roles vinculados a servicios se encuentran predefinidos por Amazon EKS e incluyen todos los permisos que el servicio requiere para llamar a otros servicios de AWS en su nombre.
Un rol vinculado a servicios simplifica la configuración de Amazon EKS porque ya no tendrá que agregar de forma manual los permisos necesarios. Amazon EKS define los permisos de sus roles vinculados a servicios y, a menos que esté definido de otra manera, solo Amazon EKS puede asumir sus roles. Los permisos definidos incluyen las políticas de confianza y de permisos, y que la política de permisos no se pueda adjuntar a ninguna otra entidad de IAM.
Solo es posible eliminar un rol vinculado a un servicio después de eliminar sus recursos relacionados. De esta forma, se protegen los recursos de Amazon EKS, ya que se evita que se puedan eliminar accidentalmente permisos de acceso a los recursos.
Para obtener información sobre otros servicios que admiten roles vinculados al servicio, consulte [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) y busque los servicios que muestran **Yes** (Sí) en la columna **Service-linked role** (Rol vinculado al servicio). Seleccione una opción **Sí** con un enlace para ver la documentación acerca del rol vinculado al servicio en cuestión.
## Permisos de roles vinculados a servicios para Amazon EKS
Amazon MSK usa el rol vinculado al servicio denominado `AWSServiceRoleForAmazonEKSLocalOutpost`. El rol de IAM permite a Amazon EKS administrar clústeres locales en la cuenta. Las políticas asociadas permiten que el rol administre los siguientes recursos: interfaces de red, grupos de seguridad, registros e instancias de Amazon EC2.
**nota**
El rol vinculado al servicio `AWSServiceRoleForAmazonEKSLocalOutpost` es distinto del rol requerido para la creación de clústeres. Para obtener más información, consulte [Rol de IAM del clúster de Amazon EKS](cluster-iam-role.md).
El rol vinculado al servicio `AWSServiceRoleForAmazonEKSLocalOutpost` confía en los siguientes servicios para asumir el rol:
+ `outposts.eks-local.amazonaws.com`
La política de permisos del rol permite que Amazon EKS realice las siguientes acciones en los recursos especificados:
+ [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html)
Debe configurar permisos para permitir a una entidad de IAM (como un usuario, grupo o rol) crear, editar o eliminar un rol vinculado a servicios. Para obtener más información, consulte [Permisos de roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) en la *Guía del usuario de IAM*.
## Crear un rol vinculado a servicios para Amazon EKS
No necesita crear un rol vinculado a servicios de manera manual. Cuando crea un clúster en la Consola de administración de AWS, la AWS CLI, o la API de AWS, Amazon EKS crea el rol vinculado a servicios en su nombre.
Si elimina este rol vinculado a servicios y necesita crearlo de nuevo, puede utilizar el mismo proceso para volver a crear el rol en su cuenta. Al crear un clúster, Amazon EKS se encarga de crear de nuevo el rol vinculado a servicios en su nombre.
## Editar un rol vinculado a servicios para Amazon EKS
Amazon EKS no permite editar el rol vinculado a servicios de `AWSServiceRoleForAmazonEKSLocalOutpost`. Después de crear un rol vinculado a servicios, no puede cambiarle el nombre, ya que varias entidades pueden hacer referencia a él. Sin embargo, puede editar la descripción del rol mediante IAM. Para obtener más información, consulte [Editing a service-linked role (Editar un rol vinculado a servicios)](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) en la *Guía del usuario de IAM*.
## Eliminar un rol vinculado a servicios para Amazon EKS
Si ya no necesita usar una característica o servicio que requieran un rol vinculado a un servicio, le recomendamos que elimine dicho rol. De esta forma, no tiene una entidad no utilizada que no se monitoree ni mantenga de forma activa. Sin embargo, debe limpiar el rol vinculado a servicios antes de eliminarlo manualmente.
### Limpiar un rol vinculado a servicios
Antes de que pueda utilizar IAM para eliminar un rol vinculado a servicios, primero debe eliminar los recursos que utiliza el rol.
**nota**
Si el servicio de Amazon EKS utiliza el rol cuando intenta eliminar los recursos, la eliminación podría producir un error. En tal caso, espere unos minutos e intente de nuevo la operación.
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. En el panel de navegación izquierdo, elija **Amazon EKS Clusters** (Clústeres de Amazon EKS).
1. Si el clúster tiene grupos de nodos o perfiles de Fargate, debe eliminarlos para poder eliminar el clúster. Para obtener más información, consulte [Eliminación de un grupo de nodos administrado de un clúster](delete-managed-node-group.md) y [Eliminación de un perfil de Fargate](delete-fargate-profile.md).
1. En la página **Clusters (Clústeres)**, elija el clúster que desea eliminar y elija **Delete (Eliminar)**.
1. Escriba el nombre del clúster en la ventana de confirmación de eliminación y, a continuación, elija **Delete (Eliminar)**.
1. Repita este procedimiento para el resto de los clústeres de la cuenta. Espere a que finalicen todas las operaciones de eliminación.
### Eliminación manual de un rol vinculado a servicios
Utilice la consola de IAM, la CLI de AWS o la API de AWS para eliminar el rol vinculado al servicio de `AWSServiceRoleForAmazonEKSLocalOutpost`. Para obtener más información, consulte [Eliminar un rol vinculado a un servicio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) en la *Guía del usuario de IAM*.
## Regiones admitidas para los roles vinculados a servicios de Amazon EKS
Amazon EKS admite el uso de roles vinculados a servicios en todas las regiones en las que se encuentra disponible el servicio. Para obtener más información, consulte [Cuotas y puntos de conexión de Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# Uso de roles para el panel de Amazon EKS
El panel de Amazon EKS utiliza este rol vinculado al servicio para agregar información sobre los recursos del clúster de varias regiones y cuentas. El panel se integra con AWS Organizations para leer de forma segura la información sobre varias cuentas de su organización.
Para obtener más información sobre el panel de Amazon EKS, consulte [Consulta de los datos agregados sobre los recursos del clúster con el panel de EKS](cluster-dashboard.md).
## Introducción
Amazon EKS utiliza [roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role) de AWS Identity and Access Management (IAM). Un rol vinculado a servicios es un tipo único de rol de IAM que se encuentra vinculado directamente a Amazon EKS. Los roles vinculados a servicios se encuentran predefinidos por Amazon EKS e incluyen todos los permisos que el servicio requiere para llamar a otros servicios de AWS en su nombre.
Un rol vinculado a servicios simplifica la configuración de Amazon EKS porque ya no tendrá que agregar de forma manual los permisos necesarios. Amazon EKS define los permisos de sus roles vinculados a servicios y, a menos que esté definido de otra manera, solo Amazon EKS puede asumir sus roles. Los permisos definidos incluyen las políticas de confianza y de permisos, y que la política de permisos no se pueda adjuntar a ninguna otra entidad de IAM.
Solo es posible eliminar un rol vinculado a un servicio después de eliminar sus recursos relacionados. De esta forma, se protegen los recursos de Amazon EKS, ya que se evita que se puedan eliminar accidentalmente permisos de acceso a los recursos.
Para obtener información sobre otros servicios que admiten roles vinculados a servicios, consulte [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) y busque los servicios que muestran **Sí** en la columna **Rol vinculado a servicios**. Seleccione una opción **Sí** con un enlace para ver la documentación acerca del rol vinculado al servicio en cuestión.
## Permisos de roles vinculados a servicios para Amazon EKS
Amazon MSK usa el rol vinculado al servicio denominado `AWSServiceRoleForAmazonEKSDashboard`. El rol permite a Amazon EKS generar y mostrar el panel de EKS, incluida la información agregada sobre los recursos del clúster. La política asociada de `AmazonEKSDashboardServiceRolePolicy` permite al rol administrar los siguientes recursos: grupos de escalado automático, grupos de seguridad, plantillas de lanzamiento y perfiles de instancia de IAM. Para obtener más información, consulte [Política administrada de AWS: AmazonEKSDashboardServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy).
El rol vinculado al servicio `AWSServiceRoleForAmazonEKSDashboard` confía en los siguientes servicios para asumir el rol:
+ `dashboard.eks.amazonaws.com`
Para consultar la versión más reciente del documento de política de JSON, consulte [AmazonEKSDashboardServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json) en la Guía de referencia de políticas administradas de AWS.
Debe configurar permisos para permitir a una entidad de IAM (como un usuario, grupo o rol) crear, editar o eliminar un rol vinculado a servicios. Para obtener más información, consulte [Permisos de roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) en la *Guía del usuario de IAM*.
## Crear un rol vinculado a servicios para Amazon EKS
No necesita crear un rol vinculado a servicios de manera manual. Cuando activa el panel en la consola de AWS, Amazon EKS crea el rol vinculado al servicio.
Para obtener más información sobre cómo activar el panel de EKS, consulte [Configuración de la integración del panel de EKS con AWS Organizations](cluster-dashboard-orgs.md).
**importante**
Este rol vinculado a servicios puede aparecer en su cuenta si se ha completado una acción en otro servicio que utilice las características compatibles con este rol.
## Editar un rol vinculado a servicios para Amazon EKS
Amazon EKS no permite editar el rol vinculado a servicios de `AWSServiceRoleForAmazonEKSDashboard`. Después de crear un rol vinculado al servicio, no podrá cambiar el nombre del rol, ya que varias entidades podrían hacer referencia al rol. Sin embargo, sí puede editar la descripción del rol con IAM. Para obtener más información, consulte [Editing a service-linked role (Editar un rol vinculado a servicios)](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) en la *Guía del usuario de IAM*.
## Eliminar un rol vinculado a servicios para Amazon EKS
Si ya no necesita usar una característica o servicio que requieran un rol vinculado a un servicio, le recomendamos que elimine dicho rol. De esta forma, no tiene una entidad no utilizada que no se monitoree ni mantenga de forma activa. Sin embargo, debe limpiar el rol vinculado a servicios antes de eliminarlo manualmente.
### Limpiar un rol vinculado a servicios
Antes de que pueda utilizar IAM para eliminar un rol vinculado a servicios, primero debe eliminar los recursos que utiliza el rol.
**nota**
Si el servicio de Amazon EKS utiliza el rol cuando intenta eliminar los recursos, la eliminación podría producir un error. En tal caso, espere unos minutos e intente de nuevo la operación.
Para obtener más información sobre cómo desactivar el panel de EKS, consulte [Configuración de la integración del panel de EKS con AWS Organizations](cluster-dashboard-orgs.md).
### Eliminación manual de un rol vinculado a servicios
Utilice la consola de IAM, la CLI de AWS o la API de AWS para eliminar el rol vinculado al servicio de `AWSServiceRoleForAmazonEKSDashboard`. Para obtener más información, consulte [Eliminar un rol vinculado a un servicio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) en la *Guía del usuario de IAM*.
## Regiones admitidas para los roles vinculados a servicios de Amazon EKS
Amazon EKS admite el uso de roles vinculados a servicios en todas las regiones en las que se encuentra disponible el servicio. Para obtener más información, consulte [Cuotas y puntos de conexión de Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html).
# Rol de IAM de ejecución de pods de Amazon EKS
Se requiere el rol de ejecución de pods de Amazon EKS para ejecutar pods en la infraestructura de AWS Fargate.
Cuando su clúster crea pods en la infraestructura de AWS Fargate, los componentes que se ejecutan en la infraestructura de Fargate deben hacer llamadas a las API de AWS en su nombre. Es así para que puedan realizar acciones, como extraer imágenes de contenedores de Amazon ECR o enrutar registros a otros servicios de AWS. El rol de ejecución de pods de Amazon EKS proporciona los permisos de IAM para esta tarea.
Al crear un perfil de Fargate, debe especificar un rol de ejecución de pods para los componentes de Amazon EKS que se ejecutan en la infraestructura de Fargate con el perfil. Este rol se agrega al [control de acceso basado en roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) de Kubernetes del clúster para su autorización. Esto permite al `kubelet` que se está ejecutando en la infraestructura de Fargate registrarse en el clúster de Amazon EKS para que pueda aparecer en el clúster como un nodo.
**nota**
El perfil de Fargate debe tener un rol de IAM diferente a los grupos de nodos de Amazon EC2.
**importante**
Los contenedores que se ejecutan en el pod de Fargate no pueden asumir los permisos de IAM asociados a un rol de ejecución de pods. Para conceder permisos a los contenedores de su pod de Fargate a fin de acceder a otros servicios de AWS, debe utilizar [Roles de IAM para cuentas de servicio](iam-roles-for-service-accounts.md).
Antes de crear un perfil de Fargate, debe crear un rol de IAM con la política [AmazonEKSFargatePodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html).
## Comprobación de la existencia de un rol de ejecución de pods configurado correctamente
Puede utilizar el siguiente procedimiento para verificar y ver si su cuenta ya dispone del rol de ejecución de pods de Amazon EKS correctamente configurado. Para evitar un problema de seguridad adjunto confuso, es importante que la función restrinja el acceso basándose en `SourceArn`. Puede modificar el rol de ejecución según sea necesario para incluir compatibilidad con perfiles Fargate en otros clústeres.
1. Abra la consola de IAM en https://console.aws.amazon.com/iam/.
1. En el panel de navegación izquierdo, elija **Roles**.
1. En la página **Roles**, busque la lista de roles para **AmazonEKSFargatePodExecutionRole**. Si el rol no existe, consulte [Creación del rol de ejecución de pods de Amazon EKS](#create-pod-execution-role) para crear el rol. Si el rol existe, elija el rol.
1. En la página **AmazonEKSFargatePodExecutionRole**, haga lo siguiente:
1. Elija **Permissions**.
1. Asegúrese de que la política **AmazonEKSFargatePodExecutionRolePolicy** administrada por Amazon esté asociada al rol.
1. Seleccione **Trust Relationships**.
1. Elija **Edit trust policy** (Editar la política de confianza).
1. En la página **Editar la política de confianza**, verifique que la relación de confianza contiene la siguiente política y que tenga una línea para los perfiles de Fargate en su clúster. Si es así, elija **Cancel** (Cancelar).
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
Si la política coincide pero no tiene una línea que especifique los perfiles de Fargate en su clúster, puede agregar la siguiente línea en la parte superior del objeto `ArnLike`. Reemplace *region-code* por la región de AWS en la que se encuentra el clúster, *111122223333* por el ID de la cuenta y *my-cluster* por el nombre del clúster.
```
"aws:SourceArn": "arn:aws:eks:region-code:111122223333:fargateprofile/my-cluster/*",
```
Si la política no coincide, copie la política anterior completa en el formulario y elija **Actualizar política**. Reemplace *region-code* por la región de AWS en la que se encuentra el clúster. Si desea utilizar la misma función en todas las regiones de AWS en su cuenta, reemplace *region-code* con `*`. Reemplace *111122223333* con su ID de cuenta y *my-cluster* con el nombre de su clúster. Si quiere utilizar el mismo rol para todos los clústeres de su cuenta, reemplace *my-cluster* con `*`.
## Creación del rol de ejecución de pods de Amazon EKS
Si aún no tiene el rol de ejecución de pods de Amazon EKS para su clúster, puede utilizar la Consola de administración de AWS o la AWS CLI para crearlo.
Consola de administración de AWS
1. Abra la consola de IAM en https://console.aws.amazon.com/iam/.
1. En el panel de navegación izquierdo, elija **Roles**.
1. En la página **Roles**, elija **Crear rol**.
1. En la página **Seleccionar entidad de confianza**, haga lo siguiente:
1. En la sección **Tipo de entidad de confianza**, elija **Servicio de AWS**.
1. En la lista desplegable **Casos de uso para otros servicios de AWS**, elija **EKS**.
1. Elija **EKS - Pod de Fargate**.
1. Elija **Siguiente**.
1. Elija **Next** (Siguiente) en la página **Add permissions** (Agregar permisos).
1. En la página **Name, review, and create** (Nombre, revisar y crear), haga lo siguiente:
1. En **Nombre del rol**, ingrese un nombre único para su rol, por ejemplo, `AmazonEKSFargatePodExecutionRole`.
1. En **Agregar etiquetas (Opcional)**, de manera opcional, agregue metadatos al rol asociando etiquetas como pares de clave-valor. Para obtener más información sobre el uso de etiquetas en IAM, consulte [Etiquetado de recursos de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) en la *Guía de usuario de IAM*.
1. Elija **Creación de rol**.
1. En la página **Roles**, busque la lista de roles para **AmazonEKSFargatePodExecutionRole**. Elija el rol.
1. En la página **AmazonEKSFargatePodExecutionRole**, haga lo siguiente:
1. Seleccione **Trust Relationships**.
1. Elija **Edit trust policy** (Editar la política de confianza).
1. En la página **Edit trust policy** (Editar política de confianza), lleve a cabo las siguientes operaciones:
1. Copie y pegue los siguientes contenidos en el formulario **Edit trust policy** (Editar política de confianza). Reemplace *region-code* por la región de AWS en la que se encuentra el clúster. Si desea utilizar la misma función en todas las regiones de AWS en su cuenta, reemplace *region-code* con `*`. Reemplace *111122223333* con su ID de cuenta y *my-cluster* con el nombre de su clúster. Si quiere utilizar el mismo rol para todos los clústeres de su cuenta, reemplace *my-cluster* con `*`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Elija **Actualizar política**.
AWS CLI
1. Copie y pegue los siguientes contenidos en un archivo denominado `pod-execution-role-trust-policy.json`. Reemplace *region-code* por la región de AWS en la que se encuentra el clúster. Si desea utilizar la misma función en todas las regiones de AWS en su cuenta, reemplace *region-code* con `*`. Reemplace *111122223333* con su ID de cuenta y *my-cluster* con el nombre de su clúster. Si quiere utilizar el mismo rol para todos los clústeres de su cuenta, reemplace *my-cluster* con `*`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Cree un rol de IAM de ejecución de pods.
```
aws iam create-role \
--role-name AmazonEKSFargatePodExecutionRole \
--assume-role-policy-document file://"pod-execution-role-trust-policy.json"
```
1. Adjunte la política administrada de IAM por Amazon EKS requerida al rol.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy \
--role-name AmazonEKSFargatePodExecutionRole
```
# Rol de IAM conector de Amazon EKS
Puede conectar clústeres de Kubernetes para verlos en la Consola de administración de AWS. Para conectarse a un clúster de Kubernetes, cree un rol de IAM.
## Verificar si hay un rol de EKS Conector existente
Puede utilizar el siguiente procedimiento para verificar y ver si la cuenta ya dispone del rol conector de Amazon EKS.
1. Abra la consola de IAM en https://console.aws.amazon.com/iam/.
1. En el panel de navegación izquierdo, elija **Roles**.
1. En la lista de roles, busque `AmazonEKSConnectorAgentRole`. Si no existe un rol que incluya `AmazonEKSConnectorAgentRole`, consulte [Creación del rol de agente conector de Amazon EKS](#create-connector-role) para crearlo. Si existe un rol que incluye `AmazonEKSConnectorAgentRole`, seleccione el rol para ver las políticas asociadas.
1. Elija **Permissions**.
1. Asegúrese de que la política administrada **AmazonEKSConnectorAgentPolicy** se haya adjuntado al rol. Si la política se ha adjuntado, entonces el rol de Amazon EKS Connector se ha configurado correctamente.
1. Elija **Relaciones de confianza** y, a continuación, **Editar política de confianza**.
1. Verifique que la relación de confianza contiene la siguiente política. Si la relación de confianza coincide con la política a continuación, seleccione **Cancelar**. Si la relación de confianza no coincide, copie la política en la ventana **Editar política de confianza** y elija **Actualizar política**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
## Creación del rol de agente conector de Amazon EKS
Puede utilizar la Consola de administración de AWS o AWS CloudFormation para crear un rol de agente conector.
AWS CLI
1. Cree un archivo con el nombre `eks-connector-agent-trust-policy.json`, que contenga el siguiente JSON que se va a utilizar para el rol de IAM.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Cree un archivo con el nombre `eks-connector-agent-policy.json` que contenga el siguiente JSON que se va a utilizar para el rol de IAM.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SsmControlChannel",
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel"
],
"Resource": "arn:aws:eks:*:*:cluster/*"
},
{
"Sid": "ssmDataplaneOperations",
"Effect": "Allow",
"Action": [
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenDataChannel",
"ssmmessages:OpenControlChannel"
],
"Resource": "*"
}
]
}
```
1. Cree el rol de agente de Amazon EKS Connector con la política de confianza y la política que creó en la lista de elementos anterior.
```
aws iam create-role \
--role-name AmazonEKSConnectorAgentRole \
--assume-role-policy-document file://eks-connector-agent-trust-policy.json
```
1. Adjunte la política a su rol de agente de Amazon EKS Connector.
```
aws iam put-role-policy \
--role-name AmazonEKSConnectorAgentRole \
--policy-name AmazonEKSConnectorAgentPolicy \
--policy-document file://eks-connector-agent-policy.json
```
AWS CloudFormation
1. Guarde la siguiente plantilla de AWS CloudFormation en un archivo de texto en su sistema local.
**nota**
Esta plantilla también crea el rol vinculado al servicio que de otro modo se crearía cuando se llama a la API `registerCluster`. Para obtener más información, consulte [Uso de roles para conectar un clúster de Kubernetes a Amazon EKS](using-service-linked-roles-eks-connector.md).
```
---
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Provisions necessary resources needed to register clusters in EKS'
Parameters: {}
Resources:
EKSConnectorSLR:
Type: AWS::IAM::ServiceLinkedRole
Properties:
AWSServiceName: eks-connector.amazonaws.com
EKSConnectorAgentRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action: [ 'sts:AssumeRole' ]
Principal:
Service: 'ssm.amazonaws.com'
EKSConnectorAgentPolicy:
Type: AWS::IAM::Policy
Properties:
PolicyName: EKSConnectorAgentPolicy
Roles:
- {Ref: 'EKSConnectorAgentRole'}
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: 'Allow'
Action: [ 'ssmmessages:CreateControlChannel' ]
Resource:
- Fn::Sub: 'arn:${AWS::Partition}:eks:*:*:cluster/*'
- Effect: 'Allow'
Action: [ 'ssmmessages:CreateDataChannel', 'ssmmessages:OpenDataChannel', 'ssmmessages:OpenControlChannel' ]
Resource: "*"
Outputs:
EKSConnectorAgentRoleArn:
Description: The agent role that EKS connector uses to communicate with AWS services.
Value: !GetAtt EKSConnectorAgentRole.Arn
```
1. Abra la [Consola de AWS CloudFormation](https://console.aws.amazon.com/cloudformation/).
1. Elija **Crear pila** con nuevos recursos (estándar).
1. Para **Specify template (Especificar plantilla)**, seleccione **Upload a template file (Actualizar un archivo de plantilla)** y, a continuación, elija **Choose file (Elegir archivo)**.
1. Elija el archivo que creó anteriormente y, a continuación, elija **Next (Siguiente)**.
1. En **Stack name (Nombre de pila)**, escriba un nombre para el rol, por ejemplo `eksConnectorAgentRole` y, a continuación, elija **Next (Siguiente)**.
1. En la página **Configurar opciones de pila**, elija **Siguiente**.
1. En la página **Review (Revisar)**, revise la información, confirme que la pila puede crear recursos de IAM y elija **Create stack (Crear pila)**.
# Políticas administradas de AWS para Amazon Elastic Kubernetes Service
Una política administrada de AWS es una política independiente que AWS crea y administra. Las políticas administradas de AWS se diseñan para ofrecer permisos para muchos casos de uso comunes, por lo que puede empezar a asignar permisos a los usuarios, grupos y roles.
Tenga en cuenta que es posible que las políticas administradas de AWS no concedan permisos de privilegio mínimo para los casos de uso concretos, ya que están disponibles para que las utilicen todos los clientes de AWS. Se recomienda reducir los permisos al definir [políticas administradas por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) que sean específicas para sus casos de uso.
No puede cambiar los permisos definidos en las políticas administradas AWS. Si AWS actualiza los permisos definidos en un política administrada de AWS, la actualización afecta a todas las identidades principales (usuarios, grupos y roles) a las que está adjunta la política. Lo más probable es que AWS actualice una política administrada de AWS cuando se lance un nuevo servicio AWS o las operaciones de la API nuevas estén disponibles para los servicios existentes.
Para obtener más información, consulte [Políticas administradas de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) en la *Guía del usuario de IAM*.
## Política administrada de AWS: AmazonEKS\$1CNI\$1Policy
No puede adjuntar la `AmazonEKS_CNI_Policy` a sus entidades de IAM. Antes de crear un grupo de nodos de Amazon EC2, esta política debe estar asociada al [rol de IAM del nodo](create-node-role.md) o a un rol de IAM utilizado de forma específica por el complemento CNI de Amazon VPC para Kubernetes. Esto es para que pueda realizar acciones en su nombre. Recomendamos que adjunte la política a un rol que solo utilice el complemento. Para obtener más información, consulte [Asignación de direcciones IP a pods con CNI de Amazon VPC](managing-vpc-cni.md) y [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md).
**Detalles sobre los permisos**
Esta política incluye los siguientes permisos que permiten a Amazon EKS completar las siguientes tareas:
+ **`ec2:*NetworkInterface` y `ec2:*PrivateIpAddresses`:** permite que el complemento CNI de Amazon VPC lleve a cabo acciones como el aprovisionamiento de interfaces de red elásticas y direcciones IP de los pods a fin de proporcionar redes para aplicaciones que se ejecutan en Amazon EKS.
+ **Acciones de lectura `ec2`**: permite que el complemento CNI de Amazon VPC realice acciones como describir instancias y subredes para ver la cantidad de direcciones IP libres en las subredes de Amazon VPC. La CNI de la VPC puede usar las direcciones IP libres de cada subred para seleccionar las subredes con la mayor cantidad de direcciones IP libres y utilizarlas al crear una interfaz de red elástica.
Para ver la versión más reciente del documento de política JSON, consulte [AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html#AmazonEKS_CNI_Policy-json) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AmazonEKSClusterPolicy
Puede adjuntar la `AmazonEKSClusterPolicy` a sus entidades de IAM. Antes de crear un clúster, debe tener un [rol de IAM de clúster](cluster-iam-role.md) con esta política adjunta. Los clústeres de Kubernetes administrados por Amazon EKS realizan llamadas a otros servicios de AWS en su nombre. Lo hacen para administrar los recursos que utiliza con el servicio.
Esta política incluye los siguientes permisos que permiten a Amazon EKS completar las siguientes tareas:
+ ** `autoscaling` **: leer y actualizar la configuración de un grupo de escalado automático. Amazon EKS no utiliza estos permisos, pero permanecen en la política de compatibilidad con versiones anteriores.
+ ** `ec2` **: trabajar con volúmenes y recursos de red asociados a nodos de Amazon EC2. Esto es necesario para que el plano de control de Kubernetes pueda unir instancias a un clúster y aprovisionar y administrar de forma dinámica los volúmenes de Amazon EBS solicitados por los volúmenes persistentes de Kubernetes.
+ ** `ec2` **: eliminar las interfaces de red elásticas creadas por la CNI de la VPC. Esto es necesario para que EKS pueda limpiar las interfaces de red elásticas que se excluyen si la CNI de la VPC se cierra inesperadamente.
+ ** `elasticloadbalancing` ** – trabaja con los Elastic Load Balancer y les agrega nodos como destinos. Esto es necesario para que el plano de control de Kubernetes pueda aprovisionar de forma dinámica los Elastic Load Balancer solicitados por los servicios de Kubernetes.
+ ** `iam` ** – crea un rol vinculado a servicios. Esto es necesario para que el plano de control de Kubernetes pueda aprovisionar de forma dinámica los equilibradores de carga elásticos solicitados por los servicios de Kubernetes.
+ ** `kms` **: leer una clave de AWS KMS. Esto es necesario para que el plano de control de Kubernetes admita el [cifrado de secretos](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) de Kubernetes almacenados en `etcd`.
Para ver la versión más reciente del documento de política JSON, consulte [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AmazonEKSDashboardConsoleReadOnly
Puede adjuntar `AmazonEKSDashboardConsoleReadOnly` a sus entidades de IAM.
Esta política incluye los siguientes permisos que permiten a Amazon EKS completar las siguientes tareas:
+ **`eks`**: acceso de solo lectura a los datos, recursos e información sobre las versiones de los clústeres del panel de control de EKS. Esto permite ver las métricas relacionadas con EKS y los detalles de configuración del clúster.
+ **`organizations`**: acceso de solo lectura a la información de AWS Organizations, que incluye:
+ Ver detalles de la organización y acceso a servicios
+ Enumerar las raíces organizativas, las cuentas y las unidades organizativas
+ Ver la estructura de la organización
Para consultar la versión más reciente del documento de la política de JSON, consulte [AmazonEKSDashboardServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardConsoleReadOnly.html#AmazonEKSDashboardConsoleReadOnly-json) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AmazonEKSFargatePodExecutionRolePolicy
Puede adjuntar la `AmazonEKSFargatePodExecutionRolePolicy` a sus entidades de IAM. Antes de crear un perfil de Fargate, debe crear un rol de ejecución de pod de Fargate y adjuntarle esta política. Para obtener más información, consulte [Paso 2: creación de un rol de ejecución de pods de Fargate](fargate-getting-started.md#fargate-sg-pod-execution-role) y [Cómo definir los pods que deben lanzarse en AWS Fargate](fargate-profile.md).
Esta política concede al rol los permisos que proporcionan acceso a otros recursos de servicios de AWS necesarios para ejecutar pods de Amazon EKS en Fargate.
**Detalles sobre los permisos**
Esta política incluye los siguientes permisos que permiten a Amazon EKS completar las siguientes tareas:
+ ** `ecr` ** – permite que los pods que se ejecutan en Fargate extraigan imágenes del contenedor almacenadas en Amazon ECR.
Para ver la versión más reciente del documento de política JSON, consulte [AmazonEKSFargatePodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html#AmazonEKSFargatePodExecutionRolePolicy-json) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AmazonEKSConnectorServiceRolePolicy
No puede asociar `AmazonEKSConnectorServiceRolePolicy` a sus entidades IAM. Esta política se encuentra adjunta a un rol vinculado a servicios que permite a Amazon EKS realizar acciones en su nombre. Para obtener más información, consulte [Uso de roles para conectar un clúster de Kubernetes a Amazon EKS](using-service-linked-roles-eks-connector.md).
El rol permite a Amazon EKS conectar clústeres de Kubernetes. Las políticas adjuntas permiten que el rol administre los recursos necesarios para conectarse al clúster de Kubernetes registrado.
**Detalles de los permisos**
Esta política incluye los siguientes permisos que permiten a Amazon EKS completar las siguientes tareas.
+ **`SSM Management`**: cree, describa y elimine activaciones de SSM y anule el registro de las instancias administradas. Esto permite las operaciones básicas de Systems Manager.
+ **`Session Management`**: inicie sesiones de SSM específicamente para clústeres de EKS y ejecute comandos no interactivos mediante el documento AmazonEKS.
+ **`IAM Role Passing`**: transfiera roles de IAM específicamente al servicio de SSM, controlado por una condición que restringe los roles transferidos a `ssm.amazonaws.com`.
+ **`EventBridge Rules`**: cree reglas y destinos de EventBridge, pero solo cuando los administre `eks-connector.amazonaws.com`. Las reglas están limitadas específicamente para que AWS SSM sea el origen del evento.
Para consultar la versión más reciente del documento de política de JSON, consulte [AmazonEKSConnectorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AmazonEKSForFargateServiceRolePolicy
No puede asociar `AmazonEKSForFargateServiceRolePolicy` a sus entidades IAM. Esta política se encuentra adjunta a un rol vinculado a servicios que permite a Amazon EKS realizar acciones en su nombre. Para obtener más información, consulte `AWSServiceRoleforAmazonEKSForFargate`.
Esta política concede los permisos necesarios a Amazon EKS para ejecutar tareas de Fargate. Solo se utiliza la política si cuenta con nodos de Fargate.
**Detalles de los permisos**
Esta política incluye los siguientes permisos que permiten a Amazon EKS completar las siguientes tareas.
+ ** `ec2` ** – crea y elimina interfaces de red elásticas y describe los recursos y las interfaces de red elásticas. Esto es necesario a fin de que el servicio Fargate de Amazon EKS pueda configurar las redes VPC necesarias para los pods de Fargate.
Para ver la versión más reciente del documento de política JSON, consulte [AmazonEKSForFargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html#AmazonEKSForFargateServiceRolePolicy-json) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AmazonEKSComputePolicy
Puede adjuntar `AmazonEKSComputePolicy` a sus entidades de IAM. Puede adjuntar esta política al [rol de IAM de su clúster](cluster-iam-role.md) para ampliar los recursos que Amazon EKS puede administrar en su cuenta.
Esta política concede los permisos necesarios para que Amazon EKS cree y administre instancias de EC2 para el clúster de EKS, y los permisos de IAM necesarios para configurar EC2. Además, esta política otorga permisos para que Amazon EKS cree el rol vinculado al servicio EC2 Spot en su nombre.
### Detalles sobre los permisos
Esta política incluye los siguientes permisos que permiten a Amazon EKS completar las siguientes tareas:
+ ** `ec2` Permisos de**:
+ `ec2:CreateFleet` y `ec2:RunInstances`: permite crear instancias de EC2 y utilizar recursos específicos de EC2 (imágenes, grupos de seguridad, subredes) para nodos de clúster de EKS.
+ `ec2:CreateLaunchTemplate`: permite crear plantillas de lanzamiento de EC2 para los nodos de clústeres de EKS.
+ La política también incluye condiciones para limitar el uso de estos permisos EC2 únicamente para los recursos etiquetados con el nombre del clúster de EKS y otras etiquetas relevantes.
+ `ec2:CreateTags`: permite agregar etiquetas a los recursos de EC2 creados por las acciones `CreateFleet`, `RunInstances` y `CreateLaunchTemplate`.
+ ** `iam` Permisos de**:
+ `iam:AddRoleToInstanceProfile`: permite agregar un rol de IAM al perfil de instancia de computación de EKS.
+ `iam:PassRole`: permite transmitir los roles de IAM necesarios al servicio de EC2.
Para ver la versión más reciente del documento de política de JSON, consulte [AmazonEKSComputePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSComputePolicy.html#AmazonEKSComputePolicy-json) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AmazonEKSNetworkingPolicy
Puede adjuntar `AmazonEKSNetworkingPolicy` a sus entidades de IAM. Puede adjuntar esta política al [rol de IAM de su clúster](cluster-iam-role.md) para ampliar los recursos que Amazon EKS puede administrar en su cuenta.
Esta política está diseñada para conceder los permisos necesarios para que Amazon EKS cree y administre las interfaces de red para el clúster de Amazon EKS, lo que permite que el plano de control y los nodos de trabajo se comuniquen y funcionen correctamente.
### Detalles sobre los permisos
Esta política concede los siguientes permisos para permitir que Amazon EKS administre las interfaces de red del clúster:
+ ** `ec2` Permisos de interfaces de red de**:
+ `ec2:CreateNetworkInterface`: permite crear interfaces de red de EC2.
+ La política incluye condiciones para restringir el uso de este permiso a las interfaces de red etiquetadas con el nombre del clúster de EKS y el nombre del nodo de CNI de Kubernetes.
+ `ec2:CreateTags`: permite añadir etiquetas a las interfaces de red creadas por la acción `CreateNetworkInterface`.
+ ** `ec2` Permisos de administración de la interfaz de red de**:
+ `ec2:AttachNetworkInterface`,`ec2:ModifyNetworkInterfaceAttribute`, `ec2:DetachNetworkInterface`: permite asociar y modificar atributos de interfaz de red y desconectar interfaces de red en instancias de EC2.
+ `ec2:UnassignPrivateIpAddresses`, `ec2:UnassignIpv6Addresses`, `ec2:AssignPrivateIpAddresses`, `ec2:AssignIpv6Addresses`: permiten administrar las asignaciones de dirección IP de las interfaces de red.
+ Estos permisos están restringidos a las interfaces de red etiquetadas con el nombre del clúster de EKS.
Para ver la versión más reciente del documento de política JSON, consulte [AmazonEKSNetworkingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSNetworkingPolicy.html#AmazonEKSNetworkingPolicy-json) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AmazonEKSBlockStoragePolicy
Puede adjuntar `AmazonEKSBlockStoragePolicy` a sus entidades de IAM. Puede adjuntar esta política al [rol de IAM de su clúster](cluster-iam-role.md) para ampliar los recursos que Amazon EKS puede administrar en su cuenta.
Esta política concede los permisos necesarios para que Amazon EKS cree, administre y mantenga volúmenes de EC2 e instantáneas para el clúster de EKS, lo que permite que el plano de control y los nodos de trabajo aprovisionen y utilicen almacenamiento persistente según lo requieran las cargas de trabajo de Kubernetes.
### Detalles sobre los permisos
Esta política de IAM concede los siguientes permisos para permitir que Amazon EKS administre volúmenes e instantáneas de EC2:
+ ** `ec2` Permisos de administración de volúmenes**:
+ `ec2:AttachVolume`, `ec2:DetachVolume`, `ec2:ModifyVolume`, `ec2:EnableFastSnapshotRestores`: permite asociar, desasociar, modificar y habilitar restauraciones rápidas de instantáneas para volúmenes de EC2.
+ Estos permisos están restringidos a los volúmenes etiquetados con el nombre del clúster de EKS.
+ `ec2:CreateTags`: permite agregar etiquetas a los volúmenes de EC2 y a las instantáneas creadas por las acciones `CreateSnapshot` y `CreateVolume`.
+ ** `ec2` Permisos de creación de volúmenes**:
+ `ec2:CreateVolume`: permite crear nuevos volúmenes de EC2.
+ La política incluye condiciones para restringir el uso de este permiso a volúmenes etiquetados con el nombre del clúster de EKS y otras etiquetas relevantes.
+ `ec2:CreateSnapshot`: permite crear nuevas instantáneas de volúmenes de EC2.
+ La política incluye condiciones para restringir el uso de este permiso a las instantáneas etiquetadas con el nombre del clúster de EKS y otras etiquetas relevantes.
Para consultar la versión más reciente del documento de política de JSON, consulte [AmazonEKSBlockStoragePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSBlockStoragePolicy.html#AmazonEKSBlockStoragePolicy-json) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AmazonEKSLoadBalancingPolicy
Puede adjuntar `AmazonEKSLoadBalancingPolicy` a sus entidades de IAM. Puede adjuntar esta política al [rol de IAM de su clúster](cluster-iam-role.md) para ampliar los recursos que Amazon EKS puede administrar en su cuenta.
Esta política de IAM concede los permisos necesarios para que Amazon EKS trabaje con varios servicios de AWS para administrar los equilibradores de carga elásticos (ELB) y los recursos relacionados.
### Detalles sobre los permisos
Los permisos clave concedidos por esta política son:
+ ** `elasticloadbalancing` **: permite crear, modificar y administrar equilibradores de carga elásticos y grupos de destino. Esto incluye permisos para crear, actualizar y eliminar equilibradores de carga, grupos de destino, agentes de escucha y reglas.
+ ** `ec2` **: permite crear y administrar grupos de seguridad necesarios para que el plano de control de Kubernetes pueda unir instancias a un clúster y administrar los volúmenes de Amazon EBS. Además, permite describir y enumerar los recursos de EC2, como instancias, VPC, subredes, grupos de seguridad y otros recursos de red.
+ ** `iam` **: permite crear un rol vinculado al servicio para Elastic Load Balancing, que es necesario para que el plano de control de Kubernetes aprovisione los equilibradores de carga elásticos de forma dinámica.
+ **`kms`**: permite leer una clave de AWS KMS, que es necesaria para que el plano de control de Kubernetes admita el cifrado de los secretos de Kubernetes almacenados en etcd.
+ ** `wafv2` ** y ** `shield` **: permite asociar y desasociar ACL web y crear/eliminar protecciones de AWS Shield para los equilibradores de carga elásticos.
+ ** `cognito-idp` **, ** `acm` **, y ** `elasticloadbalancing` **: concede permisos para describir clientes de grupos de usuarios, enumerar y describir certificados y describir grupos de destino, que son necesarios para que el plano de control de Kubernetes administre los equilibradores de carga elásticos.
La política también incluye varias comprobaciones de condiciones para garantizar que los permisos se circunscriben al clúster de EKS específico que se administra, mediante la etiqueta `eks:eks-cluster-name`.
Para consultar la versión más reciente del documento de política JSON, consulte [AmazonEKSLoadBalancingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLoadBalancingPolicy.html#AmazonEKSLoadBalancingPolicy-json) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AmazonEKSMCPReadOnlyAccess
Puede adjuntar `AmazonEKSMCPReadOnlyAccess` a sus entidades de IAM. Esta política proporciona acceso de solo lectura a los recursos de Amazon EKS y los servicios de AWS relacionados, lo que permite al servidor Protocolo de contexto para modelos (MCP) de Amazon EKS llevar a cabo operaciones de observabilidad y solución de problemas sin hacer ninguna modificación en la infraestructura.
**Detalles de los permisos**
Esta política incluye los siguientes permisos que permiten a las entidades principales completar las siguientes tareas:
+ **`eks`** permite a las entidades principales describir y enumerar los clústeres, los grupos de nodos, los complementos, las entradas de acceso y la información de EKS, así como acceder a la API de Kubernetes para operaciones de solo lectura.
+ **`iam`** permite a las entidades principales recuperar información sobre las políticas y los roles de IAM y sus archivos adjuntos para comprender los permisos asociados a los recursos de EKS.
+ **`ec2`** permite a las entidades principales describir las VPC, las subredes y las tablas de enrutamiento para comprender la configuración de red de los clústeres de EKS.
+ **`sts`** permite a las entidades principales recuperar la información de identidad del autor de la llamada con fines de autenticación y autorización.
+ **`logs`** permite a las entidades principales iniciar consultas y recuperar resultados de las consultas de Registros de CloudWatch para la solución de problemas y la supervisión.
+ **`cloudwatch`** permite a las entidades principales recuperar datos de métricas para supervisar el rendimiento de los clústeres y las cargas de trabajo.
+ **`eks-mcp`** permite a las entidades principales invocar operaciones de MCP y llamar a herramientas de solo lectura dentro del servidor MCP de Amazon EKS.
Para consultar la versión más reciente del documento de la política de JSON, consulte [AmazonEKSMCPReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSMCPReadOnlyAccess.html) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AmazonEKSServicePolicy
Puede adjuntar `AmazonEKSServicePolicy` a sus entidades de IAM. Los clústeres creados antes del 16 de abril de 2020 requerían que creara un rol de IAM y le adjuntara esta política. Los clústeres creados a partir del 16 de abril de 2020 no requieren que cree un rol ni que asigne esta política. Cuando crea un clúster mediante una entidad principal de IAM que tiene el permiso `iam:CreateServiceLinkedRole`, el rol vinculado a servicios [AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) se crea de forma automática. El rol vinculado a servicios trae adjunta la [política administrada AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy).
Esta política permite a Amazon EKS crear y administrar los recursos necesarios para operar clústeres de Amazon EKS.
**Detalles de los permisos**
Esta política incluye los siguientes permisos que permiten a Amazon EKS completar las siguientes tareas.
+ ** `eks` ** – actualiza la versión de Kubernetes de su clúster después de iniciar una actualización. Amazon EKS no utiliza este permiso, pero permanece en la política de compatibilidad con versiones anteriores.
+ ** `ec2` ** – trabaja con interfaces de red elásticas y otros recursos y etiquetas de red. Amazon EKS lo requiere para configurar redes que faciliten la comunicación entre nodos y el plano de control de Kubernetes. Obtenga información sobre los grupos de seguridad. Actualice las etiquetas de los grupos de seguridad.
+ ** `route53` ** – asocia una VPC con una zona alojada. Amazon EKS lo requiere a fin de habilitar las redes privadas de punto de conexión para su servidor de API de clúster de Kubernetes.
+ ** `logs` ** – registra eventos. Esto es necesario para que Amazon EKS pueda enviar registros de planos de control de Kubernetes a CloudWatch.
+ ** `iam` ** – crea un rol vinculado a servicios. Esto es necesario para que Amazon EKS can cree el rol vinculado al servicio [Permisos de roles vinculados a servicios para Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) en su nombre.
Para ver la versión más reciente del documento de política JSON, consulte [AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html#AmazonEKSServicePolicy-json) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AmazonEKSServiceRolePolicy
No puede asociar `AmazonEKSServiceRolePolicy` a sus entidades IAM. Esta política se encuentra adjunta a un rol vinculado a servicios que permite a Amazon EKS realizar acciones en su nombre. Para obtener más información, consulte [Permisos de roles vinculados a servicios para Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks). Al crear un clúster mediante una entidad principal de IAM que tiene el permiso `iam:CreateServiceLinkedRole`, el rol vinculado a servicios [AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) se crea de forma automática en su nombre y se le asocia esta política.
Esta política permite al rol vinculado a servicios llamar a servicios de AWS en su nombre.
**Detalles de los permisos**
Esta política incluye los siguientes permisos que permiten a Amazon EKS completar las siguientes tareas.
+ ** `ec2` ** – crea y describe las interfaces de red elásticas y las instancias de Amazon EC2, el grupo de seguridad de clúster y la VPC necesarios para la creación de clústeres. Para obtener más información, consulte [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md). Obtenga información sobre los grupos de seguridad. Actualice las etiquetas de los grupos de seguridad. Lea información sobre las reservas de capacidad bajo demanda. Lea la configuración de la VPC, que incluye las tablas de enrutamiento y las ACL de red, para detectar problemas de configuración como parte de la información sobre el clúster.
+ **Modo automático de `ec2`**: termine las instancias de EC2 creadas por el 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).
+ ** `iam` ** – enumera todas las políticas administradas que se asocian a un rol de IAM. Esto es necesario para que Amazon EKS pueda enumerar y validar todos los permisos y políticas administrados necesarios para crear un clúster.
+ **Asocie un VPC con una zona alojada**: Amazon EKS lo requiere a fin de habilitar las redes privadas de punto de conexión para su servidor de API de clúster de Kubernetes.
+ **Evento de registro**: esto es necesario para que Amazon EKS pueda enviar registros de planos de control de Kubernetes a CloudWatch.
+ **Métrica Put:** se necesita para que Amazon EKS pueda enviar registros del plano de control de Kubernetes a CloudWatch.
+ ** `eks` ** - administre las entradas y políticas de acceso al clúster, que permiten ejercer un control detallado sobre quién puede acceder a los recursos del EKS y las acciones pueden realizar. Esto incluye la asociación de políticas de acceso estándar para operaciones de computación, redes, equilibrio de carga y almacenamiento.
+ ** `elasticloadbalancing` ** - cree, administre y elimine los equilibradores de carga y sus componentes (agentes de escucha, grupos de destino, certificados) asociados a los clústeres de EKS. Consulte los atributos y el estado del equilibrador de carga.
+ **`events`**: cree y administre reglas de EventBridge para supervisar eventos de EC2 y AWS Health relacionados con clústeres de EKS, lo que permite dar una respuesta automatizada a los cambios en la infraestructura y a las alertas de estado.
+ ** `iam` ** - Administre los perfiles de instancia de EC2 con el prefijo “eks”, incluidas la creación, la eliminación y la asociación de roles, lo cual es necesario para la administración de nodos de EKS. Permite describir cualquier perfil de instancia para que los usuarios definan perfiles de instancia personalizados que sus nodos de trabajo puedan utilizar.
+ **`pricing`** **`shield`**: acceda a la información de precios de AWS y al estado de protección de Shield, lo que facilita la administración de costos y el acceso a características avanzadas de seguridad para los recursos de EKS.
+ **Limpieza de recursos**: elimine de forma segura los recursos etiquetados con EKS, incluidos volúmenes, instantáneas, plantillas de lanzamiento e interfaces de red durante las operaciones de limpieza del clúster.
Para ver la versión más reciente del documento de política JSON, consulte [AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html#AmazonEKSServiceRolePolicy-json) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AmazonEKSVPCResourceController
Puede asociar la política `AmazonEKSVPCResourceController` a las identidades de IAM. Si utiliza [grupos de seguridad de pods](security-groups-for-pods.md), debe asociar esta política a su [rol de IAM del clúster de Amazon EKS](cluster-iam-role.md) para realizar acciones en su nombre.
Esta política concede permisos al rol de clúster para administrar las interfaces de red elásticas y las direcciones IP de los nodos.
**Detalles sobre los permisos**
Esta política incluye los siguientes permisos que permiten a Amazon EKS completar las siguientes tareas:
+ ** `ec2` ** – administra interfaces de red elásticas y direcciones IP para admitir grupos de seguridad de pods y nodos de Windows.
Para ver la versión más reciente del documento de política JSON, consulte [AmazonEKSVPCResourceController](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html#AmazonEKSVPCResourceController-json) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AmazonEKSWorkerNodePolicy
No puede adjuntar la `AmazonEKSWorkerNodePolicy` a sus entidades de IAM. Debe asociar esta política a un [rol de IAM de nodo](create-node-role.md) que especifique al crear nodos de Amazon EC2 que permiten a Amazon EKS realizar acciones en su nombre. Si crea un grupo de nodos con `eksctl`, crea el rol de IAM de nodo y adjunta esta política al rol de forma automática.
Esta política concede permisos a los nodos de Amazon EC2 de Amazon EKS para conectarse a los clústeres de Amazon EKS.
**Detalles sobre los permisos**
Esta política incluye los siguientes permisos que permiten a Amazon EKS completar las siguientes tareas:
+ ** `ec2` ** – lee el volumen de la instancia y la información de red. Esto es necesario para que los nodos de Kubernetes puedan describir información sobre los recursos de Amazon EC2 necesarios a fin de que el nodo se una al clúster de Amazon EKS.
+ ** `eks` ** – opcionalmente, describe el clúster como parte del arranque de nodos.
+ ** `eks-auth:AssumeRoleForPodIdentity` ** – permite la recuperación de credenciales para las cargas de trabajo de EKS en el nodo. Esto es necesario para que la Pod Identity de EKS funcione correctamente.
Para ver la versión más reciente del documento de política JSON, consulte [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html#AmazonEKSWorkerNodePolicy-json) en la Guía de referencia de políticas administradas de AWS.
## Política administrada por AWS: AmazonEKSWorkerNodeMinimalPolicy
Puede vincular la política AmazonEKSWorkerNodeMinimalPolicy a sus entidades de IAM. Puede asociar esta política a un rol de IAM de nodo que especifique al crear nodos de Amazon EC2 que permiten a Amazon EKS realizar acciones en su nombre.
Esta política concede permisos a los nodos de Amazon EC2 de Amazon EKS para conectarse a los clústeres de Amazon EKS. Esta política tiene menos permisos en comparación con la política AmazonEKSWorkerNodePolicy.
**Detalles sobre los permisos**
Esta política incluye los siguientes permisos que permiten a Amazon EKS completar las siguientes tareas:
+ `eks-auth:AssumeRoleForPodIdentity`: permite la recuperación de credenciales para las cargas de trabajo de EKS en el nodo. Esto es necesario para que la Pod Identity de EKS funcione correctamente.
Para ver la versión más reciente del documento de política JSON, consulte [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodeMinimalPolicy.html#AmazonEKSWorkerNodeMinimalPolicy-json) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AWSServiceRoleForAmazonEKSNodegroup
No puede asociar `AWSServiceRoleForAmazonEKSNodegroup` a sus entidades IAM. Esta política se encuentra adjunta a un rol vinculado a servicios que permite a Amazon EKS realizar acciones en su nombre. Para obtener más información, consulte [Permisos de roles vinculados a servicios para Amazon EKS](using-service-linked-roles-eks-nodegroups.md#service-linked-role-permissions-eks-nodegroups).
Esta política otorga permisos de rol de `AWSServiceRoleForAmazonEKSNodegroup` que permiten crear y administrar grupos de nodos de Amazon EC2 en su cuenta.
**Detalles sobre los permisos**
Esta política incluye los siguientes permisos que permiten a Amazon EKS completar las siguientes tareas:
+ ** `ec2` ** – trabaja con grupos de seguridad, etiquetas, reservas de capacidad y plantillas de lanzamiento. Esto es necesario para que los grupos de nodos administrados por Amazon EKS habiliten la configuración de acceso remoto y describan las reservas de capacidad que se pueden usar en grupos de nodos administrados por Amazon EKS. Además, los grupos de nodos administrados por Amazon EKS crean una plantilla de lanzamiento en su nombre. Esto es para configurar el grupo de Amazon EC2 Auto Scaling que respalda cada grupo de nodos administrados.
+ ** `iam` ** – crea un rol vinculado a servicios y transfiere un rol. Los grupos de nodos administrados por Amazon EKS lo requieren para administrar los perfiles de instancias del rol que se transfiere al crear un grupo de nodos administrados. Las instancias de Amazon EC2 lanzadas como parte de un grupo de nodos administrados utilizan este perfil de instancias. Amazon EKS necesita crear roles vinculadas a servicios para otros servicios, como los grupos de Amazon EC2 Auto Scaling. Estos permisos se usan en la creación de un grupo de nodos administrados.
+ ** `autoscaling` ** – trabaja con grupos de escalado automático de seguridad. Los grupos de nodos administrados por Amazon EKS lo requieren para administrar el grupo de Amazon EC2 Auto Scaling que respalda cada grupo de nodos administrados. También se utiliza para admitir funcionalidades como la expulsión de pods cuando los nodos se terminan o se reciclan durante actualizaciones de grupos de nodos, así como para administrar grupos de reserva en caliente configurados en grupos de nodos administrados.
Para ver la versión más reciente del documento de política JSON, consulte [AWSServiceRoleForAmazonEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html#AWSServiceRoleForAmazonEKSNodegroup-json) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AmazonEKSDashboardServiceRolePolicy
No puede asociar `AmazonEKSDashboardServiceRolePolicy` a sus entidades IAM. Esta política se encuentra adjunta a un rol vinculado a servicios que permite a Amazon EKS realizar acciones en su nombre. Para obtener más información, consulte [Permisos de roles vinculados a servicios para Amazon EKS](using-service-linked-roles-eks-dashboard.md#service-linked-role-permissions-eks-dashboard).
Esta política otorga permisos de rol de `AWSServiceRoleForAmazonEKSDashboard` que permiten crear y administrar grupos de nodos de Amazon EC2 en su cuenta.
**Detalles sobre los permisos**
Esta política incluye los siguientes permisos que permiten el acceso para completar las siguientes tareas:
+ **`organizations`**: vea información sobre la estructura y las cuentas de AWS Organizations. Esto incluye permisos para enumerar las cuentas de su organización, ver las unidades organizativas y las raíces, enumerar los administradores delegados, ver los servicios que tienen acceso a su organización y recuperar información detallada sobre su organización y sus cuentas.
Para consultar la versión más reciente del documento de política de JSON, consulte [AmazonEKSDashboardServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AmazonEBSCSIDriverPolicy
La política `AmazonEBSCSIDriverPolicy` permite que el controlador Interfaz de almacenamiento de contenedores (CSI) de Amazon EBS cree, modifique, copie, asocie, desasocie y elimine volúmenes en su nombre. Esto incluye modificar las etiquetas de los volúmenes existentes y habilitar la restauración rápida de instantáneas (FSR) en los volúmenes de EBS. También concede al controlador EBS CSI permisos para crear, bloquear, restaurar y eliminar instantáneas, así como para enumerar sus instancias, volúmenes e instantáneas.
Para ver la versión más reciente del documento de política JSON, consulte [AmazonEBSCSIDriverServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverPolicy.html#AmazonEBSCSIDriverPolicy-json) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AmazonEFSCSIDriverPolicy
La política de `AmazonEFSCSIDriverPolicy` permite a la interfaz de almacenamiento de contenedores (CSI) de Amazon EFS crear y eliminar puntos de acceso en su nombre. También otorga permisos al controlador CSI de Amazon EFS para enumerar sus puntos de acceso, sistemas de archivos, destinos de montaje y zonas de disponibilidad de Amazon EC2.
Para ver la versión más reciente del documento de política JSON, consulte [AmazonEFSCSIDriverServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEFSCSIDriverPolicy.html#AmazonEFSCSIDriverPolicy-json) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AmazonEKSLocalOutpostClusterPolicy
Puede asociar esta política a entidades de IAM. Antes de crear un clúster local, debe adjuntar esta política al [rol del clúster](cluster-iam-role.md). Los clústeres de Kubernetes administrados por Amazon EKS realizan llamadas a otros servicios de AWS en su nombre. Lo hacen para administrar los recursos que utiliza con el servicio.
La `AmazonEKSLocalOutpostClusterPolicy` incluye los siguientes permisos:
+ **Acciones de lectura de `ec2`**: permite a las instancias del plano de control describir las propiedades de la zona de disponibilidad, la tabla de enrutamiento, la instancia y la interfaz de red. Permisos necesarios para que las instancias de Amazon EC2 se unan correctamente al clúster como instancias del plano de control.
+ ** `ssm` ** – permite la conexión de Amazon EC2 Systems Manager a la instancia del plano de control, que Amazon EKS usa para comunicar y administrar el clúster local de su cuenta.
+ ** `logs` ** – permite que las instancias envíen registros a Amazon CloudWatch.
+ ** `secretsmanager` **: permite a las instancias obtener y eliminar los datos de arranque de las instancias del plano de control de forma segura desde AWS Secrets Manager.
+ ** `ecr` ** – permite que los pods y los contenedores que se ejecutan en las instancias del plano de control extraigan imágenes de contenedor almacenadas en Amazon Elastic Container Registry.
Para ver la versión más reciente del documento de política JSON, consulte [AmazonEKSLocalOutpostClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostClusterPolicy.html#AmazonEKSLocalOutpostClusterPolicy-json) en la Guía de referencia de políticas administradas de AWS.
## Política administrada de AWS: AmazonEKSLocalOutpostServiceRolePolicy
No puede adjuntar esta política a sus entidades de IAM. Al crear un clúster mediante una entidad principal de IAM que tiene el permiso `iam:CreateServiceLinkedRole`, Amazon EKS crea el rol vinculado a servicios [AWSServiceRoleforAmazonEKSLocalOutpost](using-service-linked-roles-eks-outpost.md) de forma automática en su nombre y le asocia esta política. Esta política permite al rol vinculado a servicios llamar a servicios de AWS para clústeres locales en su nombre.
La `AmazonEKSLocalOutpostServiceRolePolicy` incluye los siguientes permisos:
+ ** `ec2` ** – permite a Amazon EKS trabajar con la seguridad, la red y otros recursos para lanzar y administrar correctamente las instancias del plano de control en su cuenta.
+ ** `ssm`, `ssmmessages` ** – permite la conexión de Amazon EC2 Systems Manager a las instancias del plano de control, que Amazon EKS usa para comunicar y administrar el clúster local de su cuenta.
+ ** `iam` ** – permite a Amazon EKS administrar el perfil de instancia asociado a las instancias del plano de control.
+ ** `secretsmanager` **: permite a Amazon EKS colocar los datos de arranque de las instancias del plano de control en AWS Secrets Manager para que pueda consultarse de forma segura durante el arranque de la instancia.
+ ** `outposts` ** – permite a Amazon EKS obtener información de Outpost de su cuenta para lanzar correctamente un clúster local en un Outpost.
Para ver la versión más reciente del documento de política JSON, consulte [AmazonEKSLocalOutpostServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostServiceRolePolicy.html#AmazonEKSLocalOutpostServiceRolePolicy-json) en la Guía de referencia de políticas administradas de AWS.
## Actualizaciones de Amazon EKS en las políticas administradas de AWS
Es posible consultar los detalles sobre las actualizaciones de las políticas administradas de AWS para Amazon EKS debido a que este servicio comenzó a realizar el seguimiento de estos cambios.
Para recibir notificaciones de todos los cambios en el archivo de origen de esta página de documentación específica, puede suscribirse a la siguiente URL con un lector de RSS:
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/security/iam-reference/security-iam-awsmanpol.adoc.atom
```
| Cambio | Descripción | Fecha |
| --- | --- | --- |
| Permiso agregado a [Política administrada de AWS: AmazonEKSNetworkingPolicy](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy). | Se agregó el permiso `ec2:ModifyNetworkInterfaceAttribute` en `AmazonEKSNetworkingPolicy`. Esto permite al controlador de modo automático de Amazon EKS modificar los atributos de la interfaz de red relacionados con las instancias de EC2. | 3 de febrero de 2026 |
| Se agregaron permisos a [Política administrada de AWS: AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Se agregaron los permisos `autoscaling:PutWarmPool`, `autoscaling:DeleteWarmPool` y `autoscaling:DescribeWarmPool` a `AWSServiceRoleForAmazonEKSNodegroup`. Esto permite que los grupos de nodos administrados de Amazon EKS administren los recursos subyacentes del grupo de reserva en caliente de ASG durante el ciclo de vida del grupo de nodos. | 17 de febrero de 2026 |
| Se agregó el permiso a . [Política administrada de AWS: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Se eliminó el requisito del prefijo “eks” en el nombre del perfil de instancia de destino para el permiso `iam:GetInstanceProfile` en `AmazonEKSServiceRolePolicy`. Esto permite que el modo automático de Amazon EKS valide y utilice perfiles de instancia personalizados en las clases de nodos sin requerir el prefijo “eks” en la nomenclatura. | 2 de febrero de 2026 |
| Se agregaron permisos a [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | Se agregó el permiso `ec2:LockSnapshot` para permitir que el controlador EBS CSI bloquee directamente las instantáneas de EBS. | 15 de enero de 2026 |
| Presentó la política [Política administrada de AWS: AmazonEKSMCPReadOnlyAccess](#security-iam-awsmanpol-amazoneksmcpreadonlyaccess). | Amazon EKS introdujo una nueva política administrada de `AmazonEKSMCPReadOnlyAccess` para activar herramientas de solo lectura en el servidor MCP de Amazon EKS para la observabilidad y la solución de problemas. | 21 de noviembre de 2025 |
| Se agregaron permisos a [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | Se agregó el permiso `ec2:CopyVolumes` para permitir que el controlador CSI de EBS copie los volúmenes de EBS directamente. | 17 de noviembre de 2025 |
| Se agregó el permiso a . [Política administrada de AWS: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Se agregaron los permisos `ec2:DescribeRouteTables` y `ec2:DescribeNetworkAcls` a `AmazonEKSServiceRolePolicy`. De este modo, Amazon EKS puede detectar problemas de configuración con las tablas de enrutamiento de VPC y las ACL de red para nodos híbridos como parte de la información de los clústeres. | 22 de octubre de 2025 |
| Se agregó el permiso a [AWSServiceRoleForAmazonEKSConnector](using-service-linked-roles-eks-connector.md). | Se agregó el permiso `ssmmessages:OpenDataChannel` a `AmazonEKSConnectorServiceRolePolicy`. | 15 de octubre de 2025 |
| Se agregó el permiso a . [Política administrada de AWS: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) | Este rol puede adjuntar la nueva política de acceso `AmazonEKSEventPolicy`. Permisos restringidos para `ec2:DeleteLaunchTemplate` y `ec2:TerminateInstances`. | 26 de agosto de 2025 |
| Permiso agregado a [Política administrada de AWS: AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) | Se agregó el permiso `ssmmessages:OpenDataChannel` a `AmazonEKSLocalOutpostServiceRolePolicy`. | 26 de junio de 2025 |
| Se agregó el permiso a [Política administrada de AWS: AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy). | Se actualizaron los permisos de recursos para las acciones `ec2:RunInstances` y `ec2:CreateFleet` a fin de incluir las reservas de capacidad ` arn:aws:ec2:*:*:capacity-reservation/*`. Esto permite que el modo automático de Amazon EKS ejecute instancias mediante las reservas de capacidad bajo demanda de EC2 en su cuenta. Se agregó `iam:CreateServiceLinkedRole` para permitir que el modo automático de Amazon EKS cree el rol `AWSServiceRoleForEC2Spot` vinculado al servicio EC2 Spot en su nombre. | 20 de junio de 2025 |
| Se agregó un permiso a [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Se agregó el permiso `ec2:DescribeCapacityReservations` para permitir que el modo automático de Amazon EKS ejecute instancias mediante las reservas de capacidad bajo demanda de EC2 en su cuenta. | 20 de junio de 2025 |
| Presentó la política [Política administrada de AWS: AmazonEKSDashboardConsoleReadOnly](#security-iam-awsmanpol-amazoneksdashboardconsolereadonly). | Se introdujo una nueva política `AmazonEKSDashboardConsoleReadOnly`. | 19 de junio de 2025 |
| Presentó la política [Política administrada de AWS: AmazonEKSDashboardServiceRolePolicy](#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy). | Se introdujo una nueva política `AmazonEKSDashboardServiceRolePolicy`. | 21 de mayo de 2025 |
| Se agregaron permisos a [AmazonEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy). | Se agregó el permiso `ec2:DeleteNetworkInterfaces` para permitir que Amazon EKS elimine las interfaces de red elásticas que se excluyen si la CNI de la VPC se cierra inesperadamente. | 16 de abril de 2025 |
| Se agregó un permiso a [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Como parte de la versión 1.33 de EKS, se agregaron los permisos `ec2:RevokeSecurityGroupEgress` y `ec2:AuthorizeSecurityGroupEgress` para que los clientes de IA/ML de EKS puedan añadir reglas de salida de grupos de seguridad al clúster SG de EKS predeterminado que sean compatibles con EFA. | 14 de abril de 2025 |
| Se agregaron permisos a [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Se agregó el permiso para terminar instancias de EC2 creadas por el modo automático de EKS. | 28 de febrero de 2025 |
| Se agregaron permisos a [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | Se agregó una nueva declaración que autoriza al controlador CSI de EBS a restaurar todas las instantáneas. La política vigente permitía esto anteriormente, pero se requiere una nueva declaración explícita debido a un cambio en la gestión de IAM para `CreateVolume`. Se concedió al controlador CSI de EBS la capacidad de modificar las etiquetas de los volúmenes existentes. El controlador de CSI de EBS puede modificar las etiquetas de los volúmenes existentes a través de parámetros en VolumeAttributesClasses de Kubernetes. Se concedió al controlador CSI de EBS la capacidad de habilitar la restauración rápida de instantáneas (FSR) en los volúmenes de EBS. El controlador de CSI de EBS puede habilitar la FSR en volúmenes nuevos mediante parámetros en clases de almacenamiento de Kubernetes. | 13 de enero de 2025 |
| Se agregaron permisos a [Política administrada de AWS: AmazonEKSLoadBalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy). | Se actualizó `AmazonEKSLoadBalancingPolicy` para permitir la enumeración y descripción de los recursos de redes y direcciones IP. | 26 de diciembre de 2024 |
| Se agregaron permisos a [Política administrada de AWS: AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | `AWSServiceRoleForAmazonEKSNodegroup` se actualizó de modo que sea compatible con regiones de China. | 22 de noviembre de 2024 |
| Se agregaron permisos a [Política administrada de AWS: AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) | Se agregó un permiso `ec2:DescribeAvailabilityZones` a AWS de modo que el administrador de controladores de la nube de `AmazonEKSLocalOutpostClusterPolicy` en el plano de control del clúster pueda identificar la zona de disponibilidad en la que se encuentra cada nodo. | 21 de noviembre de 2024 |
| Se agregaron permisos a [Política administrada de AWS: AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Se actualizó la política `AWSServiceRoleForAmazonEKSNodegroup` para permitir `ec2:RebootInstances` para las instancias creadas por grupos de nodos administrados por Amazon EKS. Se restringieron los permisos `ec2:CreateTags` para los recursos de Amazon EC2. | 20 de noviembre de 2024 |
| Se agregaron permisos a [Política administrada de AWS: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | EKS actualizó la política `AmazonEKSServiceRolePolicy` administrada por AWS. Se han agregado permisos para las políticas de acceso a EKS, la administración del equilibrador de carga y la limpieza automatizada de los recursos del clúster. | 16 de noviembre de 2024 |
| Presentó la política [Política administrada de AWS: AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy). | EKS actualizó la política `AmazonEKSComputePolicy` administrada por AWS. Se actualizaron los permisos de recursos para la acción `iam:AddRoleToInstanceProfile`. | 7 de noviembre de 2024 |
| Presentó la política [Política administrada de AWS: AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy). | AWS presentó la `AmazonEKSComputePolicy`. | 1 de noviembre de 2024 |
| Se agregaron permisos a `AmazonEKSClusterPolicy` | Se agregó el permiso `ec2:DescribeInstanceTopology` para permitir que Amazon EKS asocie información de topología al nodo como marcas. | 1 de noviembre de 2024 |
| Presentó la política [Política administrada de AWS: AmazonEKSBlockStoragePolicy](#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy). | AWS presentó la `AmazonEKSBlockStoragePolicy`. | 30 de octubre de 2024 |
| Presentó la política [Política administrada de AWS: AmazonEKSLoadBalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy). | AWS presentó la `AmazonEKSLoadBalancingPolicy`. | 30 de octubre de 2024 |
| Se agregaron permisos a [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy). | Se agregaron permisos `cloudwatch:PutMetricData` para permitir que Amazon EKS publique métricas en Amazon CloudWatch. | 29 de octubre de 2024 |
| Presentó la política [Política administrada de AWS: AmazonEKSNetworkingPolicy](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy). | AWS presentó la `AmazonEKSNetworkingPolicy`. | 28 de octubre de 2024 |
| Permisos añadidos a las políticas `AmazonEKSServicePolicy` y `AmazonEKSServiceRolePolicy` | Se añadió `ec2:GetSecurityGroupsForVpc` y los permisos de etiquetas asociados para permitir que Amazon EKS lea la información del grupo de seguridad y actualice las etiquetas relacionadas. | 10 de octubre de 2024 |
| Introdujo [AmazonEKSWorkerNodeMinimalPolicy](#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy). | AWS presentó la `AmazonEKSWorkerNodeMinimalPolicy`. | 3 de octubre de 2024 |
| Se agregaron permisos a [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Se añadieron los permisos `autoscaling:ResumeProcesses` y `autoscaling:SuspendProcesses` para permitir que Amazon EKS suspenda y reanude el `AZRebalance` en los grupos de escalado automático administrados por Amazon EKS. | 21 de agosto de 2024 |
| Se agregaron permisos a [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Se agregó el permiso `ec2:DescribeCapacityReservations` para permitir que Amazon EKS describa la reserva de capacidad en la cuenta de usuario. Se agregó el permiso `autoscaling:PutScheduledUpdateGroupAction` para permitir configurar el escalado programado en los grupos de nodos `CAPACITY_BLOCK`. | 27 de junio de 2024 |
| [AmazonEKS\$1CNI\$1Policy](#security-iam-awsmanpol-amazoneks-cni-policy): actualización de una política existente | Amazon EKS ha agregado nuevos permisos `ec2:DescribeSubnets` para que el complemento CNI de Amazon VPC para Kubernetes pueda ver la cantidad de direcciones IP libres en las subredes de Amazon VPC. La CNI de la VPC puede usar las direcciones IP libres de cada subred para seleccionar las subredes con la mayor cantidad de direcciones IP libres y utilizarlas al crear una interfaz de red elástica. | 4 de marzo de 2024 |
| [AmazonEKSWorkerNodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy): Actualización de una política existente | Amazon EKS agregó nuevos permisos para permitir las Pod Identities de EKS. El agente de Pod Identity de Amazon EKS usa el rol de nodo. | 26 de noviembre de 2023 |
| Se presentó [AmazonEFSCSIDriverPolicy](#security-iam-awsmanpol-amazonefscsidriverservicerolepolicy). | AWS presentó la `AmazonEFSCSIDriverPolicy`. | 26 de julio de 2023 |
| Se agregaron permisos a [AmazonEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy). | Se agregó un permiso de `ec2:DescribeAvailabilityZones` para permitir que Amazon EKS obtenga los detalles de AZ durante la detección automática de subredes al crear equilibradores de carga. | 7 de febrero de 2023 |
| Condiciones de la política actualizadas en [AmazonEBSCSIdRiverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | Eliminación de condiciones de política no válidas con caracteres comodín en el campo clave de `StringLike`. También se agregó una nueva condición `ec2:ResourceTag/kubernetes.io/created-for/pvc/name: "*"` a `ec2:DeleteVolume`, que permite al controlador CSI de EBS eliminar los volúmenes creados por el complemento integrado en el árbol. | 17 de noviembre de 2022 |
| Se agregaron permisos a [AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy). | Se agregó `ec2:DescribeVPCAttribute`, `ec2:GetConsoleOutput` y `ec2:DescribeSecret` para permitir una mejor validación de los requisitos previos y un control del ciclo de vida administrado. También se agregó `ec2:DescribePlacementGroups` y `"arn:aws:ec2:*:*:placement-group/*"` a `ec2:RunInstances` para admitir el control de ubicación de las instancias de Amazon EC2 del plano de control en Outposts. | 24 de octubre de 2022 |
| Actualice los permisos del registro de Amazon Elastic Container Registry en [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). | Se movió la acción `ecr:GetDownloadUrlForLayer` de todas las secciones de recursos a una sección específica. Se agregó el recurso ` arn:aws:ecr:*:*:repository/eks/ `. Se eliminó el recurso ` arn:aws:ecr:`. Este recurso está cubierto por el recurso agregado ` arn:aws:ecr:*:*:repository/eks/*`. | 20 de octubre de 2022 |
| Se agregaron permisos a [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). | Se agregó el repositorio de Amazon Elastic Container Registry ` arn:aws:ecr:*:*:repository/kubelet-config-updater` para que las instancias del plano de control del clúster puedan actualizar algunos argumentos de `kubelet`. | 31 de agosto de 2022 |
| Se presentó [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy). | AWS presentó la `AmazonEKSLocalOutpostClusterPolicy`. | 24 de agosto de 2022 |
| Se presentó [AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy). | AWS presentó la `AmazonEKSLocalOutpostServiceRolePolicy`. | 23 de agosto de 2022 |
| Se presentó [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy). | AWS presentó la `AmazonEBSCSIDriverPolicy`. | 4 de abril de 2022 |
| Se agregaron permisos a [AmazonEKSWorkerNodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy). | Se agregó `ec2:DescribeInstanceTypes` para habilitar las AMI optimizadas de Amazon EKS que pueden detectar en forma automática las propiedades de nivel de instancia. | 21 de marzo de 2022 |
| Se agregaron permisos a [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup). | Se agregó el permiso `autoscaling:EnableMetricsCollection` para permitir que Amazon EKS habilite la recopilación de métricas. | 13 de diciembre de 2021 |
| Se agregaron permisos a [AmazonEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy). | Se han agregados permisos de `ec2:DescribeAccountAttributes`, `ec2:DescribeAddresses` y `ec2:DescribeInternetGateways` a fin de permitir que Amazon EKS cree un rol vinculado a servicios para un equilibrador de carga de red. | 17 de junio de 2021 |
| Amazon EKS comenzó a realizar el seguimiento de los cambios. | Amazon EKS comenzó a realizar el seguimiento de los cambios de las políticas administradas de AWS. | 17 de junio de 2021 |
# Solución de problemas de IAM
En este tema se tratan algunos errores habituales que pueden aparecer al utilizar Amazon EKS con IAM y cómo solucionarlos.
## AccessDeniedException
Si recibe una `AccessDeniedException` al llamar a una operación de API de AWS, las credenciales de la [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que utiliza no tienen los permisos necesarios para hacer esa llamada.
```
An error occurred (AccessDeniedException) when calling the DescribeCluster operation:
User: arn:aws:iam::111122223333:user/user_name is not authorized to perform:
eks:DescribeCluster on resource: arn:aws:eks:region:111122223333:cluster/my-cluster
```
En el mensaje de ejemplo anterior, el usuario no tiene permisos para llamar a la operación `DescribeCluster` de la API de Amazon EKS. Para proporcionar permisos de administrador de Amazon EKS a una entidad principal de IAM, consulte [Ejemplos de políticas de Amazon EKS basadas en identidades](security-iam-id-based-policy-examples.md).
Para obtener información general sobre IAM, consulte [Control del acceso con políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html) en la *Guía del usuario de IAM*.
## No puede ver **Nodos** en la pestaña **Informática** o cualquier cosa de la pestaña **Recursos** y recibe un error en la Consola de administración de AWS
Es posible que aparezca un mensaje de error en la consola que dice `Your current user or role does not have access to Kubernetes objects on this EKS cluster`. Asegúrese de que el usuario [principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) con el que está utilizando la Consola de administración de AWS tenga los permisos necesarios. Para obtener más información, consulte [Permisos necesarios](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
## El `ConfigMap` de aws-auth no concede acceso al clúster
El [autenticador de IAM de AWS](https://github.com/kubernetes-sigs/aws-iam-authenticator) no permite una ruta de acceso en el ARN de rol utilizado en el `ConfigMap`. Por lo tanto, antes de especificar `rolearn`, elimine la ruta de acceso. Por ejemplo, cambie ` arn:aws:iam::111122223333:role/team/developers/eks-admin ` a ` arn:aws:iam::111122223333:role/eks-admin `.
## No tengo autorización para realizar la operación iam:PassRole
Si recibe un error que indica que no tiene autorización para llevar a cabo la acción `iam:PassRole`, sus políticas deben actualizarse para permitirle pasar un rol a Amazon MQ.
Algunos servicios de AWS le permiten transferir un rol existente a dicho servicio en lugar de crear un nuevo rol de servicio o uno vinculado al servicio. Para ello, debe tener permisos para transferir el rol al servicio.
En el siguiente ejemplo, el error se produce cuando un usuario de IAM denominado `marymajor` intenta utilizar la consola para realizar una acción en Amazon EKS. Sin embargo, la acción requiere que el servicio cuente con permisos que otorguen un rol de servicio. Mary no tiene permisos para transferir el rol al servicio.
```
User: {arn-aws}iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
En este caso, las políticas de Mary se deben actualizar para permitirle realizar la acción `iam:PassRole`.
Si necesita ayuda, póngase en contacto con su administrador de AWS. El administrador es la persona que le proporcionó las credenciales de inicio de sesión.
## Quiero permitir que personas ajenas a mi cuenta de AWS accedan a mis recursos de Amazon EKS.
Puede crear un rol que los usuarios de otras cuentas o las personas externas a la organización puedan utilizar para acceder a sus recursos. Se puede especificar una persona de confianza para que asuma el rol. En el caso de los servicios que admitan las políticas basadas en recursos o las listas de control de acceso (ACL), puede utilizar dichas políticas para conceder a las personas acceso a sus recursos.
Para obtener más información, consulte lo siguiente:
+ Para saber si Amazon EKS admite estas características, consulte [Cómo funciona Amazon EKS con IAM](security-iam-service-with-iam.md).
+ Para obtener información acerca de cómo proporcionar acceso a los recursos de las cuentas de AWS de su propiedad, consulte [Proporcionar acceso a un usuario de IAM a otra cuenta de AWS de la que es propietario](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) en la *Guía del usuario de IAM*.
+ Para obtener información acerca de cómo proporcionar acceso a los recursos a cuentas de AWS de terceros, consulte [Proporcionar acceso a cuentas de AWS que son propiedad de terceros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) en la *Guía del usuario de IAM*.
+ Para obtener información sobre cómo proporcionar acceso mediante una federación de identidades, consulte [Proporcionar acceso a usuarios autenticados externamente (identidad federada)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) en la *Guía del usuario de IAM*.
+ Para conocer sobre la diferencia entre las políticas basadas en roles y en recursos para el acceso entre cuentas, consulte [Acceso a recursos entre cuentas en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) en la *Guía del usuario de IAM*.
## 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`
Los contenedores reciben este error si la aplicación lleva a cabo solicitudes explícitamente al punto de conexión de AWS STS global (`https://sts.amazonaws`) y su cuenta de servicio de Kubernetes está configurada para utilizar un punto de conexión regional. Puede resolver el problema con una de las siguientes opciones:
+ Actualice el código de la aplicación para eliminar las llamadas explícitas al punto de conexión global de AWS STS.
+ Actualice el código de la aplicación para realizar llamadas explícitas a puntos de conexión regionales, como `https://sts.us-west-2.amazonaws.com`. Su aplicación debe tener redundancia integrada para seleccionar una región de AWS diferente en caso de producirse un error del 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.
+ Configure sus cuentas de servicio para utilizar el punto de conexión global. Los clústeres utilizan el punto de conexión regional de forma predeterminada. Para obtener más información, consulte [Configure el punto de conexión AWS Security Token Service de una cuenta de servicio](configure-sts-endpoint.md).
# Rol de IAM del clúster de Amazon EKS
Se requiere un rol de IAM de clúster de Amazon EKS para cada clúster. Los clústeres de Kubernetes administrados por Amazon EKS utilizan este rol para administrar los nodos, y el [proveedor de nube heredado](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) lo usa para crear equilibradores de carga con Elastic Load Balancing para los servicios.
Para poder crear clústeres de Amazon EKS, debe crear un rol de IAM con una de las siguientes políticas de IAM:
+ [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html)
+ Una política de IAM personalizada. Los permisos mínimos que aparecen a continuación permiten que el clúster de Kubernetes administre los nodos, pero no que el [proveedor de nube heredado](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider) cree equilibradores de carga con Elastic Load Balancing. La política de IAM personalizada debe disponer al menos de los siguientes permisos:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"ForAnyValue:StringLike": {
"aws:TagKeys": "kubernetes.io/cluster/*"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcs",
"ec2:DescribeDhcpOptions",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeInstanceTopology",
"kms:DescribeKey"
],
"Resource": "*"
}
]
}
```
**nota**
Antes del 3 de octubre de 2023, se requería [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) en el rol de IAM de cada clúster.
Antes del 16 de abril de 2020, se requería [AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) y [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) y el nombre sugerido era `eksServiceRole`. Con el rol vinculado a servicios de `AWSServiceRoleForAmazonEKS`, la política [AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) ya no es necesaria para clústeres creados a partir del 16 de abril de 2020.
## Comprobar si existe un rol de clúster existente
Puede utilizar el siguiente procedimiento para verificar y conocer si la cuenta ya dispone del rol de clúster de Amazon EKS.
1. Abra la consola de IAM en https://console.aws.amazon.com/iam/.
1. En el panel de navegación izquierdo, elija **Roles**.
1. En la lista de roles, busque `eksClusterRole`. Si no existe un rol que incluya `eksClusterRole`, consulte [Crear el rol de clúster de Amazon EKS](#create-service-role) para crearlo. Si existe un rol que incluye `eksClusterRole`, seleccione el rol para ver las políticas asociadas.
1. Elija **Permissions**.
1. Asegúrese de que la política administrada **AmazonEKSClusterPolicy**se ha asociado al rol. Si la política se ha adjuntado, entonces el rol de clúster de Amazon EKS se ha configurado correctamente.
1. Elija **Trust relationships** (Relaciones de confianza) y, a continuación, **Edit trust policy** (Editar política de confianza).
1. Verifique que la relación de confianza contiene la siguiente política. Si la relación de confianza coincide con la política a continuación, seleccione **Cancelar**. Si la relación de confianza no coincide, copie la política en la ventana **Editar política de confianza** y elija **Actualizar política**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Crear el rol de clúster de Amazon EKS
Para crear el rol de clúster, puede utilizar la Consola de administración de AWS o la AWS CLI.
Consola de administración de AWS
1. Abra la consola de IAM en https://console.aws.amazon.com/iam/.
1. Elija **Roles** y, a continuación, **Create role (Crear rol)**.
1. En **Tipo de entidad de confianza**, seleccione **Servicio de AWS**.
1. En la lista desplegable **Casos de uso para otros servicios de AWS**, elija **EKS**.
1. Elija **EKS: clúster** para su caso de uso y, luego, elija **Siguiente**.
1. En la pestaña **Agregar permisos**, seleccione **Siguiente**.
1. En **Nombre del rol**, ingrese un nombre único para su rol, por ejemplo, `eksClusterRole`.
1. En **Description** (Descripción), ingrese texto descriptivo, como `Amazon EKS - Cluster role`.
1. Elija **Creación de rol**.
AWS CLI
1. Copie el siguiente contenido en un archivo denominado *cluster-trust-policy.json*.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Creación del rol. Puede reemplazar *eksClusterRole* con el nombre que usted elija.
```
aws iam create-role \
--role-name eksClusterRole \
--assume-role-policy-document file://"cluster-trust-policy.json"
```
1. Adjunte la política de IAM necesaria al rol de IAM
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy \
--role-name eksClusterRole
```
# Rol de IAM de nodo de Amazon EKS
El daemon de `kubelet` del nodo de Amazon EKS realiza llamadas a las API de AWS en su nombre. Los nodos reciben permisos de dichas llamadas de API a través de políticas asociadas y de un perfil de instancias de IAM. Antes de poder lanzar nodos y registrarlos en un clúster, debe crear un rol de IAM para dichos nodos, para utilizarlo cuando se lancen. Este requisito se aplica a nodos lanzados con la AMI optimizada para Amazon EKS proporcionada por Amazon o con cualquier otra AMI de nodo que pretenda utilizar. Además, este requisito se aplica tanto a los grupos de nodos administrados como a los administrados por el usuario.
**nota**
No se puede utilizar el mismo rol que se utiliza para crear clústeres.
Antes de crear un nodo, debe crear un rol de IAM con los siguientes permisos:
+ Permisos para que el `kubelet` pueda describir los recursos de Amazon EC2 en la VPC, tal y como los proporciona la política [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html). Esta política también proporciona los permisos para el agente de Pod Identity de Amazon EKS.
+ Permisos para que el `kubelet` pueda utilizar imágenes de contenedores de Amazon Elastic Container Registry (Amazon ECR), según lo dispuesto en la política [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ContainerRegistryPullOnly.html). Los permisos para utilizar imágenes de contenedor de Amazon Elastic Container Registry (Amazon ECR) son necesarios porque los complementos integrados para redes ejecutan pods que utilizan imágenes de contenedor de Amazon ECR.
+ (Opcional) Permisos para que el agente de Pod Identity de Amazon EKS utilice la acción `eks-auth:AssumeRoleForPodIdentity` para recuperar las credenciales de los pods. Si no usa [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html), debe proporcionar este permiso además de los permisos de EC2 para utilizar Pod Identity de EKS.
+ (Opcional) Si no utiliza Pod Identity de EKS e IRSA para otorgar permisos a los pods de CNI de VPC, debe proporcionar permisos para la CNI de la VPC en el rol de instancia. Puede utilizar la política administrada [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) (si creó el clúster con la familia `IPv4`) o una [política IPv6 que usted cree](cni-iam-role.md#cni-iam-role-create-ipv6-policy) (si creó el clúster con la familia `IPv6`). Sin embargo, en lugar de adjuntar la política a este rol, le recomendamos adjuntar la política a un rol independiente utilizado específicamente para el complemento Amazon VPC CNI. Para obtener más información acerca de cómo crear un rol independiente para el complemento Amazon VPC CNI, consulte [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md).
**nota**
Los grupos de nodos de Amazon EC2 deben tener un rol de IAM diferente al perfil de Fargate. Para obtener más información, consulte [Rol de IAM de ejecución de pods de Amazon EKS](pod-execution-role.md).
## Verificar un rol de nodo existente
Puede utilizar el siguiente procedimiento para verificar y conocer si la cuenta ya dispone del rol de nodo de Amazon EKS.
1. Abra la consola de IAM en https://console.aws.amazon.com/iam/.
1. En el panel de navegación izquierdo, elija **Roles**.
1. En la lista de roles, busque `eksNodeRole`, `AmazonEKSNodeRole` o `NodeInstanceRole`. Si no existe un rol con alguno de esos nombres, consulte [Crear el rol de IAM de nodo de Amazon EKS](#create-worker-node-role) para crear el rol. Si existe un rol que contiene `eksNodeRole`, `AmazonEKSNodeRole` o `NodeInstanceRole`, seleccione el rol para ver las políticas adjuntas.
1. Elija **Permisos**.
1. Asegúrese de que las políticas administradas **AmazonEKSWorkerNodePolicy** y **AmazonEC2ContainerRegistryPullOnly** estén asociadas al rol, o que haya una política personalizada asociada con los permisos mínimos.
**nota**
Si la política **AmazonEKS\$1CNI\$1Policy** se encuentra adjunta al rol, se recomienda eliminarla y adjuntarla a un rol de IAM asignado a la cuenta de servicio de Kubernetes de `aws-node` en su lugar. Para obtener más información, consulte [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md).
1. Elija **Relaciones de confianza** y, a continuación, **Editar política de confianza**.
1. Verifique que la relación de confianza contiene la siguiente política. Si la relación de confianza coincide con la política a continuación, seleccione **Cancelar**. Si la relación de confianza no coincide, copie la política en la ventana **Editar política de confianza** y elija **Actualizar política**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"Service": [
"ec2.amazonaws.com"
]
}
}
]
}
```
## Crear el rol de IAM de nodo de Amazon EKS
Puede crear el rol de IAM del nodo con la Consola de administración de AWS o la CLI de AWS.
Consola de administración de AWS
1. Abra la consola de IAM en https://console.aws.amazon.com/iam/.
1. En el panel de navegación izquierdo, elija **Roles**.
1. En la página **Roles**, elija **Crear rol**.
1. En la página **Seleccionar entidad de confianza**, haga lo siguiente:
1. En la sección **Tipo de entidad de confianza**, elija **Servicio de AWS**.
1. En **Caso de uso**, elija **EC2**.
1. Elija **Siguiente**.
1. En la página **Agregar permisos**, asocie una política personalizada o haga lo siguiente:
1. En el cuadro **Filtrar políticas**, escriba `AmazonEKSWorkerNodePolicy`.
1. A continuación, marque la casilla situada a la izquierda de **AmazonEKSWorkerNodePolicy** en los resultados de la búsqueda.
1. Elija **Borrar filtros**.
1. En el cuadro **Filtrar políticas**, escriba `AmazonEC2ContainerRegistryPullOnly`.
1. Marque la casilla situada a la izquierda de **AmazonEC2ContainerRegistryPullOnly** en los resultados de la búsqueda.
La política administrada **AmazonEKS\$1CNI\$1Policy** o una [política de IPv6](cni-iam-role.md#cni-iam-role-create-ipv6-policy) que cree también se tiene que adjuntar a este rol o a un rol diferente asignado a la cuenta de servicio de Kubernetes de `aws-node`. Se recomienda asignar la política al rol asociado a la cuenta de servicio de Kubernetes en lugar de asignarla a este rol. Para obtener más información, consulte [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md).
1. Elija **Siguiente**.
1. En la página **Nombrar, revisar y crear**, haga lo siguiente:
1. En **Nombre del rol**, ingrese un nombre único para su rol, por ejemplo, `AmazonEKSNodeRole`.
1. En **Descripción**, sustituya el texto actual por un texto descriptivo, como `Amazon EKS - Node role`.
1. En **Agregar etiquetas (Opcional)**, de manera opcional, agregue metadatos al rol asociando etiquetas como pares de clave-valor. Para obtener más información sobre el uso de etiquetas en IAM, consulte [Etiquetado de recursos de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) en la *Guía de usuario de IAM*.
1. Elija **Creación de rol**.
AWS CLI
1. Ejecute el siguiente comando para crear un archivo `node-role-trust-relationship.json`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"Service": [
"ec2.amazonaws.com"
]
}
}
]
}
```
1. Creación del rol de IAM.
```
aws iam create-role \
--role-name AmazonEKSNodeRole \
--assume-role-policy-document file://"node-role-trust-relationship.json"
```
1. Adjunte al rol de IAM las dos políticas administradas por IAM necesarias.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name AmazonEKSNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly \
--role-name AmazonEKSNodeRole
```
1. Adjunte una de las siguientes políticas de IAM al rol de IAM en función de la familia de IP con la que haya creado el clúster. La política debe adjuntarse a este rol o a un rol asociado a la cuenta de servicio de `aws-node` de Kubernetes que se utiliza para el complemento CNI de Amazon VPC. Se recomienda asignar la política al rol asociado a la cuenta de servicio de Kubernetes. Para asignar la política al rol asociado a la cuenta de servicio de Kubernetes, consulte [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md).
+ IPv4
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \
--role-name AmazonEKSNodeRole
```
+ IPv6
1. Copie el siguiente texto y guárdelo en un archivo llamado `vpc-cni-ipv6-policy.json`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssignIpv6Addresses",
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeInstanceTypes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
1. Creación de la política de IAM.
```
aws iam create-policy --policy-name AmazonEKS_CNI_IPv6_Policy --policy-document file://vpc-cni-ipv6-policy.json
```
1. Adjunte la política de IAM al rol de IAM. Reemplace *111122223333* por el ID de su cuenta.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::111122223333:policy/AmazonEKS_CNI_IPv6_Policy \
--role-name AmazonEKSNodeRole
```
# Rol de IAM del clúster del modo automático de Amazon EKS
Se requiere un rol de IAM de clúster de Amazon EKS para cada clúster. Los clústeres de Kubernetes administrados por Amazon EKS utilizan este rol para automatizar las tareas rutinarias de almacenamiento, redes y escalado automático de computación.
Antes de crear clústeres de Amazon EKS, debe crear un rol de IAM con las políticas necesarias para el modo automático de EKS. Puede asociar las políticas administradas de AWS IAM sugeridas o crear políticas personalizadas con permisos equivalentes.
+ [AmazonEKSComputePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [AmazonEKSNetworkingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
## Comprobar si existe un rol de clúster existente
Puede utilizar el siguiente procedimiento para verificar y conocer si la cuenta ya dispone del rol de clúster de Amazon EKS.
1. Abra la consola de IAM en https://console.aws.amazon.com/iam/.
1. En el panel de navegación izquierdo, elija **Roles**.
1. En la lista de roles, busque `AmazonEKSAutoClusterRole`. Si no existe un rol que incluya `AmazonEKSAutoClusterRole`, consulte las instrucciones de la siguiente sección para crear el rol. Si existe un rol que incluye `AmazonEKSAutoClusterRole`, seleccione el rol para ver las políticas asociadas.
1. Elija **Permissions**.
1. Asegúrese de que la política administrada **AmazonEKSClusterPolicy**se ha asociado al rol. Si la política se ha adjuntado, entonces el rol de clúster de Amazon EKS se ha configurado correctamente.
1. Elija **Trust relationships** (Relaciones de confianza) y, a continuación, **Edit trust policy** (Editar política de confianza).
1. Verifique que la relación de confianza contiene la siguiente política. Si la relación de confianza coincide con la política a continuación, seleccione **Cancelar**. Si la relación de confianza no coincide, copie la política en la ventana **Editar política de confianza** y elija **Actualizar política**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
**nota**
AWS no requiere el nombre `AmazonEKSAutoClusterRole` de este rol.
## Crear el rol de clúster de Amazon EKS
Para crear el rol de clúster, puede utilizar la Consola de administración de AWS o la AWS CLI.
### Consola de administración de AWS
1. Abra la consola de IAM en https://console.aws.amazon.com/iam/.
1. Elija **Roles** y, a continuación, **Create role (Crear rol)**.
1. En **Tipo de entidad de confianza**, seleccione **Servicio de AWS**.
1. En la lista desplegable **Casos de uso para otros servicios de AWS**, elija **EKS**.
1. Elija **EKS: clúster** para su caso de uso y, luego, elija **Siguiente**.
1. En la pestaña **Agregar permisos**, seleccione las políticas y, a continuación, elija **Siguiente**.
+ [AmazonEKSComputePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [AmazonEKSNetworkingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
1. En **Nombre del rol**, ingrese un nombre único para su rol, por ejemplo, `AmazonEKSAutoClusterRole`.
1. En **Description** (Descripción), ingrese texto descriptivo, como `Amazon EKS - Cluster role`.
1. Elija **Creación de rol**.
### AWS CLI
1. Copie el siguiente contenido en un archivo denominado *cluster-trust-policy.json*.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
1. Creación del rol. Puede reemplazar *AmazonEKSAutoClusterRole* por el nombre que elija.
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://"cluster-trust-policy.json"
```
1. Asocie las políticas de IAM necesarias al rol:
**AmazonEKSClusterPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
```
**AmazonEKSComputePolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSComputePolicy
```
**AmazonEKSBlockStoragePolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**AmazonEKSLoadBalancingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**AmazonEKSNetworkingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSNetworkingPolicy
```
# Rol de IAM de nodo del modo automático de Amazon EKS
**nota**
No se puede utilizar el mismo rol que se utiliza para crear clústeres.
Antes de crear nodos, debe crear un rol de IAM con las siguientes políticas, o permisos equivalentes:
+ [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
## Verificar un rol de nodo existente
Puede utilizar el siguiente procedimiento para verificar y conocer si la cuenta ya dispone del rol de nodo de Amazon EKS.
1. Abra la consola de IAM en https://console.aws.amazon.com/iam/.
1. En el panel de navegación izquierdo, elija **Roles**.
1. En la lista de roles, busque `AmazonEKSAutoNodeRole`. Si no existe un rol con uno de esos nombres, consulte las instrucciones que figuran en la siguiente sección para crear el rol. Si existe un rol que contiene `AmazonEKSAutoNodeRole`, seleccione el rol para ver las políticas asociadas.
1. Elija **Permisos**.
1. Asegúrese de que se asocian las políticas requeridas mencionadas anteriormente, o políticas personalizadas equivalentes.
1. Elija **Relaciones de confianza** y, a continuación, **Editar política de confianza**.
1. Verifique que la relación de confianza contiene la siguiente política. Si la relación de confianza coincide con la política a continuación, seleccione **Cancelar**. Si la relación de confianza no coincide, copie la política en la ventana **Editar política de confianza** y elija **Actualizar política**.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Crear el rol de IAM de nodo de Amazon EKS
Puede crear el rol de IAM del nodo con la Consola de administración de AWS o la CLI de AWS.
### Consola de administración de AWS
1. Abra la consola de IAM en https://console.aws.amazon.com/iam/.
1. En el panel de navegación izquierdo, elija **Roles**.
1. En la página **Roles**, elija **Crear rol**.
1. En la página **Seleccionar entidad de confianza**, haga lo siguiente:
1. En la sección **Tipo de entidad de confianza**, elija **Servicio de AWS**.
1. En **Caso de uso**, elija **EC2**.
1. Elija **Siguiente**.
1. En la página **Agregar permisos**, elija las siguientes políticas:
+ [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
1. En la página **Nombrar, revisar y crear**, haga lo siguiente:
1. En **Nombre del rol**, ingrese un nombre único para su rol, por ejemplo, `AmazonEKSAutoNodeRole`.
1. En **Descripción**, sustituya el texto actual por un texto descriptivo, como `Amazon EKS - Node role`.
1. En **Agregar etiquetas (Opcional)**, de manera opcional, agregue metadatos al rol asociando etiquetas como pares de clave-valor. Para obtener más información sobre el uso de etiquetas en IAM, consulte [Etiquetado de recursos de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) en la *Guía de usuario de IAM*.
1. Elija **Creación de rol**.
### AWS CLI
**Creación del rol de IAM de nodo**
Utilice el archivo **node-trust-policy.json** del paso anterior para definir qué entidades pueden asumir el rol. Ejecute el siguiente comando para crear el rol de IAM del nodo:
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
**Apunte el ARN del rol**
Después de crear el rol, recupere y guarde el ARN del rol de IAM del nodo. Necesitará este ARN en los pasos siguientes. Utilice el siguiente comando para obtener el ARN:
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
**Asociar las políticas necesarias**
Asocie las siguientes políticas administradas de AWS al rol de IAM del nodo para proporcionar los permisos necesarios:
Para asociar AmazonEKSWorkerNodeMinimalPolicy:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
Para asociar AmazonEC2ContainerRegistryPullOnly:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
# Rol de IAM de capacidad de Amazon EKS
Las capacidades de EKS necesitan que se configure un rol de IAM de capacidad (o rol de capacidad). Las capacidades utilizan este rol para llevar a cabo acciones en los servicios de AWS y acceder a los recursos de Kubernetes del clúster mediante entradas de acceso que se crean automáticamente.
Antes de poder especificar un rol de capacidad durante la creación de la capacidad, debe crear el rol de IAM con la política de confianza y los permisos adecuados para el tipo de capacidad. Una vez creado este rol de IAM, se puede reutilizar para cualquier cantidad de recursos de capacidad.
## Requisitos del rol de capacidad
El rol de capacidad debe cumplir los siguientes requisitos:
+ El rol debe estar en la misma cuenta de AWS que el clúster y el recurso de capacidad.
+ El rol debe tener una política de confianza que permita al servicio de las capacidades de EKS asumir el rol.
+ El rol debe tener los permisos adecuados para el tipo de capacidad y los requisitos del caso de uso (consulte [Permisos por tipo de capacidad](#capability-permissions)).
## Política de confianza para roles de capacidad
Todos los roles de capacidad deben incluir la siguiente política de confianza:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
Esta política de confianza permite a EKS hacer lo siguiente:
+ Asumir el rol para llevar a cabo operaciones de API de AWS
+ Etiquetar sesiones con fines de auditoría y seguimiento
## Permisos por tipo de capacidad
Los permisos de IAM necesarios dependen de la capacidad que utilice y del modelo de implementación.
**nota**
Para las implementaciones de producción que utilizan selectores de roles de IAM con ACK, o cuando se utilizan kro o Argo CD sin integración de servicios de AWS, es posible que el rol de capacidad no necesite ningún permiso de IAM más allá de la política de confianza.
**kro (Kube Resource Orchestrator)**
No se necesita ningún permiso de IAM. Puede crear un rol de capacidad sin políticas adjuntas. kro solo necesita los permisos de RBAC de Kubernetes para crear y administrar los recursos de Kubernetes.
** AWS Controladores para Kubernetes de (ACK)**
ACK admite dos modelos de permisos:
+ **Configuración sencilla (desarrollo y pruebas)**: agregue los permisos de los servicios de AWS directamente al rol de capacidad. Funciona bien para comenzar, para implementaciones de una sola cuenta o cuando todos los usuarios necesitan los mismos permisos.
+ **Práctica recomendada de producción**: utilice los selectores de roles de IAM para implementar el acceso de privilegio mínimo. Con este enfoque, el rol de capacidad solo necesita el permiso `sts:AssumeRole` para asumir roles específicos del servicio. No agregará ningún permiso de servicio de AWS (como S3 o RDS) al propio rol de capacidad, ya que esos permisos se conceden a los roles de IAM individuales que se asignan a espacios de nombres específicos.
Los selectores de roles de IAM permiten lo siguiente:
+ Aislamiento de permisos del espacio de nombres
+ Administración de recursos entre cuentas
+ Roles de IAM específicos de equipos
+ Modelo de seguridad de privilegio mínimo
Ejemplo de política de rol de capacidad para el enfoque del selector de roles de IAM:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::111122223333:role/ACK-S3-Role",
"arn:aws:iam::111122223333:role/ACK-RDS-Role",
"arn:aws:iam::444455556666:role/ACKCrossAccountRole"
]
}
]
}
```
Para obtener información detallada sobre la configuración de los permisos de ACK, lo que incluye los selectores de roles de IAM, consulte [Configuración de los permisos de ACK](ack-permissions.md).
**Argo CD**
No se necesita ningún permiso de IAM de forma predeterminada. Es posible que se necesiten permisos opcionales para:
+ **AWS Secrets Manager**: si utiliza Secrets Manager para almacenar las credenciales del repositorio de Git
+ **AWS CodeConnections**: si utiliza CodeConnections para la autenticación del repositorio de Git
Ejemplo de política de Secrets Manager y CodeConnections:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "arn:aws:secretsmanager:region:account-id:secret:argocd/*"
},
{
"Effect": "Allow",
"Action": [
"codeconnections:UseConnection",
"codeconnections:GetConnection"
],
"Resource": "arn:aws:codeconnections:region:account-id:connection/*"
}
]
}
```
Para obtener información detallada sobre los requisitos de permisos de Argo CD, consulte [Consideraciones sobre Argo CD](argocd-considerations.md).
## Comprobación de un rol de capacidad existente
Puede utilizar el procedimiento siguiente para comprobar si la cuenta ya dispone del rol de IAM de capacidad adecuado para su caso de uso.
1. Abra la consola de IAM en https://console.aws.amazon.com/iam/.
1. En el panel de navegación izquierdo, elija **Roles**.
1. Busque el nombre del rol de capacidad en la lista de roles (por ejemplo, `ACKCapabilityRole` o `ArgoCDCapabilityRole`).
1. Si existe un rol, selecciónelo para ver las políticas adjuntas y la relación de confianza.
1. Elija **Relaciones de confianza** y, a continuación, **Editar política de confianza**.
1. Compruebe que la relación de confianza coincida con la [política de confianza de capacidad](#capability-trust-policy). Si no coincide, actualice la política de confianza.
1. Elija **Permisos** y compruebe que el rol tenga los permisos adecuados para su tipo de capacidad y caso de uso.
## Creación de un rol de IAM de capacidad
Puede utilizar la Consola de administración de AWS o la AWS CLI para crear un rol de capacidad.
** Consola de administración de AWS **
1. Abra la consola de IAM en https://console.aws.amazon.com/iam/.
1. Elija **Roles** y, a continuación, **Create role (Crear rol)**.
1. En **Tipo de entidad de confianza**, seleccione **Política de confianza personalizada**.
1. Copie y pegue la [política de confianza de capacidad](#capability-trust-policy) en el editor de políticas de confianza.
1. Elija **Siguiente**.
1. En la pestaña **Agregar permisos**, seleccione o cree las políticas adecuadas para su tipo de capacidad (consulte [Permisos por tipo de capacidad](#capability-permissions)). En el caso de kro, también puede omitir este paso.
1. Elija **Siguiente**.
1. En **Nombre del rol**, ingrese un nombre único para su rol (por ejemplo, `ACKCapabilityRole`, `ArgoCDCapabilityRole` o `kroCapabilityRole`).
1. En **Description** (Descripción), ingrese texto descriptivo, como `Amazon EKS - ACK capability role`.
1. Elija **Creación de rol**.
** AWS CLI**
1. Copie la [política de confianza de capacidad](#capability-trust-policy) en un archivo denominado `capability-trust-policy.json`.
1. Creación del rol. Sustituya `ACKCapabilityRole` por el nombre del rol que desee.
```
aws iam create-role \
--role-name ACKCapabilityRole \
--assume-role-policy-document file://capability-trust-policy.json
```
1. Asocie las políticas de IAM necesarias al rol. En el caso de ACK, adjunte políticas para los servicios de AWS que desee administrar. En el caso de Argo CD, adjunte políticas para Secrets Manager o CodeConnections si es necesario. En el caso de kro, también puede omitir este paso.
Ejemplo de ACK con permisos de S3:
```
aws iam put-role-policy \
--role-name ACKCapabilityRole \
--policy-name S3Management \
--policy-document file://s3-policy.json
```
## Solución de problemas de roles de capacidad
**Se produce un error en la creación de la capacidad porque el rol de IAM no es válido"**
Verifique lo siguiente:
+ El rol existe en la misma cuenta que el clúster.
+ La política de confianza coincide con la [política de confianza de capacidad](#capability-trust-policy).
+ Tiene el permiso `iam:PassRole` para el rol.
**La capacidad muestra errores de permisos**
Verifique lo siguiente:
+ El rol tiene los permisos de IAM necesarios para el tipo de capacidad.
+ La entrada de acceso existe en el clúster para el rol.
+ Si es necesario, se deben configurar permisos de Kubernetes adicionales (consulte [Permisos de Kubernetes adicionales](capabilities-security.md#additional-kubernetes-permissions)).
**Los recursos de ACK fallan con errores de permiso denegado**
Verifique lo siguiente:
+ El rol tiene los permisos de IAM necesarios para su caso de uso.
+ En el caso de los controladores de ACK que hacen referencia a secretos, asegúrese de haber asociado la política de entrada de acceso `AmazonEKSSecretReaderPolicy` definida a los espacios de nombres adecuados.
Para obtener más orientación sobre la solución de problemas, consulte [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md).