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

ConfigMapLa gestión de acceso basada en clústeres (aws-auth ConfigMap) ha quedado obsoleta 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:

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, su solicitud de autenticación es procesada por la CLI de aws-iam-authenticator AWS EKS y validada en 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 políticas de acceso específicas de Amazon EKS 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 de acceso ConfigMap basada en bases:

1. Menor riesgo de errores de configuración: la administración directa basada en API elimina los errores comunes asociados con la edición manual ConfigMap . 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 nativas de AWS.

Mejores prácticas:

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

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.

Consideraciones y limitaciones:

1. Los roles ARNs 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. Además del RBAC nativo de Kubernetes, considera 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. Control detallado de los permisos de IAM.

2. Función estática y predecible ARNs

Desventajas:

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

2. Falta de administración de identidad centralizada

3. Potencial de proliferación de entidades de IAM

Mejores prácticas:

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.

Consideraciones y limitaciones:

1. Problemas de escalabilidad al administrar una gran cantidad 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 sobre la integración de proveedores de inicio de sesión único externos con Amazon EKS.

Consideraciones y limitaciones:

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 información detallada sobre la identidad y las credenciales de los pods de EKS, consulte la sección Identidades y credenciales de las prácticas recomendadas de seguridad.

Recomendación

Combine IAM Identity Center con la API 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, AWS SDKs 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 mapeando los 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