View a markdown version of this page

Administración del acceso a los clústeres - Amazon EKS
Opciones de administración de acceso de EKSOpción 1: AWS IAM Identity Center con API de administración de acceso a clústeres (CAM)Opción 2: AWS IAM Users/Roles mapeado a grupos de KubernetesOpción 3: proveedores de OIDCAWS EKS Pod Identity frente a IRSA para cargas de trabajoRecomendación

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Administración del acceso a los clústeres

La gestión eficaz del acceso es fundamental para mantener la seguridad e integridad de los clústeres de Amazon EKS. En esta guía, se analizan varias opciones para la administración del acceso a EKS, centrándose en el uso de AWS IAM Identity Center (anteriormente, AWS SSO). Compararemos diferentes enfoques, analizaremos sus ventajas y desventajas y destacaremos las limitaciones y consideraciones conocidas.

Opciones de administración de acceso de EKS

nota

ConfigMap-based la gestión de acceso (aws-auth ConfigMap) está en desuso y se ha sustituido por la API de gestión de acceso a clústeres (CAM). En el caso de los nuevos clústeres de EKS, implemente la API CAM para gestionar el acceso a los clústeres. Para los clústeres existentes que utilizan aws-auth ConfigMap, migre a la API CAM.

Opción 1: AWS IAM Identity Center con API de administración de acceso a clústeres (CAM)

  • Administración centralizada de usuarios y permisos

  • Integración con los proveedores de identidad existentes (por ejemplo, Microsoft AD, Okta PingId y más)

  • La API CAM utiliza entradas de acceso para vincular a los principales (usuarios o roles) de AWS IAM con el clúster de EKS. Estas entradas funcionan con las identidades administradas del IAM Identity Center, lo que permite a los administradores controlar el acceso al clúster para los usuarios y grupos definidos en Identity Center.

Flujo de autenticación del clúster EKS:

Flujo de autenticación del clúster EKS

  1. Los directores (usuarios humanos) o los procesos automatizados se autentican mediante AWS IAM presentando los permisos de cuenta de AWS correspondientes. En este paso, se asignan al principal de AWS IAM correspondiente (rol o usuario).

  2. A continuación, una entrada de acceso a EKS asigna este principio de IAM a un principal RBAC de Kubernetes (usuario o grupo) mediante la definición de la política de acceso adecuada, que solo contiene los permisos de Kubernetes.

  3. Cuando un usuario final de Kubernetes intenta acceder a un clúster, aws-iam-authenticator o la CLI de AWS EKS procesan su solicitud de autenticación y la validan con el contexto del clúster en el archivo kubeconfig.

  4. Por último, el autorizador de EKS verifica los permisos asociados a la entrada de acceso del usuario autenticado y concede o deniega el acceso en consecuencia.

    • La API utiliza las políticas de EKS-specific acceso de Amazon para definir el nivel de autorización de cada entrada de acceso. Estas políticas se pueden asignar a las funciones y permisos configurados en el Centro de identidad de IAM, lo que garantiza un control de acceso uniforme en todos los servicios de AWS y los clústeres de EKS.

Ventajas en comparación con la gestión del ConfigMap-based acceso:

  1. Menor riesgo de errores de configuración: la API-based administración directa elimina los errores comunes asociados a la ConfigMap edición manual. Esto ayuda a evitar eliminaciones accidentales o errores de sintaxis que podrían impedir que los usuarios accedan al clúster.

  2. Principio de privilegios mínimos mejorado: elimina la necesidad del permiso de administrador del clúster de la identidad del creador del clúster y permite una asignación de permisos más detallada y adecuada. Puede optar por añadir este permiso para los casos de uso de breakglass.

  3. Modelo de seguridad mejorado: proporciona una validación integrada de las entradas de acceso antes de que se apliquen. Además, ofrece una integración más estrecha con AWS IAM para la autenticación.

  4. Operaciones simplificadas: ofrece una forma más intuitiva de administrar los permisos mediante herramientas. AWS-native

Prácticas recomendadas:

  1. Use AWS Organizations para administrar varias cuentas y aplicar políticas de control de servicios (SCP).

  2. Implemente el principio de privilegios mínimos creando conjuntos de permisos específicos para diferentes funciones de EKS (p. ej., administrador, desarrollador o de solo lectura).

  3. Utilice el control de acceso basado en atributos (ABAC) para asignar dinámicamente los permisos a los pods en función de los atributos del usuario.

  4. Audite y revise periódicamente los permisos de acceso.

Considerations/limitations:

  1. Los ARN de rol generados por Identity Center tienen sufijos aleatorios, lo que dificulta su uso en configuraciones estáticas.

  2. Soporte limitado para permisos detallados a nivel de recursos de Kubernetes. Se requiere una configuración adicional para las funciones RBAC personalizadas de Kubernetes. Junto con Kubernetes-native RBAC, considere usar Kyverno para la administración avanzada de permisos en los clústeres de EKS.

Opción 2: AWS IAM Users/Roles mapeado a grupos de Kubernetes

Ventajas:

  1. Fine-grained control sobre los permisos de IAM.

  2. ARN de roles estáticos y predecibles

Desventajas:

  1. Aumento de la sobrecarga de administración de las cuentas de usuario

  2. Falta de una administración de identidad centralizada

  3. Potencial de proliferación de entidades de IAM

Prácticas recomendadas:

  1. Utilice funciones de IAM en lugar de usuarios de IAM para mejorar la seguridad y la capacidad de administración

  2. Implemente una convención de nomenclatura para las funciones a fin de garantizar la coherencia y la facilidad de administración

  3. Utilice las condiciones de la política de IAM para restringir el acceso en función de las etiquetas u otros atributos.

  4. Cambie las claves de acceso y revise los permisos con regularidad.

Considerations/limitations:

  1. Problemas de escalabilidad al gestionar un gran número de usuarios o roles

  2. No hay capacidades de inicio de sesión único integradas

Opción 3: proveedores de OIDC

Ventajas:

  1. Integración con los sistemas de gestión de identidad existentes

  2. Reducción de la sobrecarga de administración de las cuentas de usuario

Desventajas:

  1. Complejidad de configuración adicional

  2. Posibilidad de aumentar la latencia durante la autenticación

  3. Dependencia de un proveedor de identidad externo

Mejores prácticas:

  1. Configure cuidadosamente el proveedor del OIDC para garantizar la validación segura del token.

  2. Utilice tokens de corta duración e implemente mecanismos de actualización de los mismos.

  3. Audite y actualice periódicamente las configuraciones del OIDC.

Consulte esta guía para obtener una implementación de referencia de la integración de Sign-On proveedores únicos externos con Amazon EKS.

Considerations/limitations:

  1. Integración nativa limitada con los servicios de AWS en comparación con IAM.

  2. La URL del emisor del proveedor del OIDC debe ser de acceso público para que EKS pueda descubrir las claves de firma.

AWS EKS Pod Identity frente a IRSA para cargas de trabajo

Amazon EKS ofrece dos formas de conceder permisos de IAM de AWS a las cargas de trabajo que se ejecutan en los clústeres de Amazon EKS: funciones de IAM para cuentas de servicio (IRSA) e identidades de pods de EKS.

Si bien las identidades de pod IRSA y EKS ofrecen las ventajas del acceso con privilegios mínimos, el aislamiento de credenciales y la auditabilidad, la forma recomendada de conceder permisos a las cargas de trabajo es EKS Pod Identity.

Para obtener una guía detallada sobre la identidad y las credenciales de los pods de EKS, consulte la sección Identidades y credenciales de las mejores prácticas de seguridad.

Recomendación

Combine el centro de identidad de IAM con la API de CAM

  • Administración simplificada: al usar la API de administración de acceso a clústeres junto con IAM Identity Center, los administradores pueden administrar el acceso a los clústeres de EKS junto con otros servicios de AWS, lo que reduce la necesidad de cambiar entre diferentes interfaces o editar ConfigMaps manualmente.

  • Utilice las entradas de acceso para administrar los permisos de Kubernetes de las entidades principales de IAM ajenos al clúster. Puede añadir y administrar el acceso al clúster mediante la API de EKS, la interfaz de línea de comandos de AWS, los SDK de AWS CloudFormation, AWS y la consola de administración de AWS. Esto significa que puede administrar los usuarios con las mismas herramientas con las que creó el clúster.

  • Los permisos granulares de Kubernetes se pueden aplicar mediante la asignación de usuarios o grupos de Kubernetes con los principios de IAM asociados a las identidades de SSO mediante entradas de acceso y políticas de acceso.

  • Para empezar, siga Cambiar el modo de autenticación para usar entradas de acceso y, a continuación, Migrar las entradas de aws-auth existentes a entradas de acceso. ConfigMap