Consideraciones sobre la seguridad para las capacidades de EKS - Amazon EKS
Rol de IAM de capacidadEntradas de acceso de EKSPermisos de Kubernetes adicionalesPermisos de IAM que necesita la capacidadPrácticas recomendadas de seguridadSiguientes pasos

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.

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:

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.

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 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

  2. 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.

La capacidad de kro de EKS establece automáticamente el nombre de la sesión /kro.

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.

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 con la interfaz de usuario y la API de Argo CD desde la VPC sin tener que atravesar la Internet pública.

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.

Siguientes pasos