Concesión de acceso a las cargas de trabajo de Kubernetes a AWS mediante las cuentas de servicio de Kubernetes - Amazon EKS
Tokens de cuenta de servicioComplementos de clústerConcesión de permisos a AWS Identity and Access Management a cargas de trabajo en clústeres de Amazon Elastic Kubernetes Service

Concesión de acceso a las cargas de trabajo de Kubernetes a AWS mediante las cuentas de servicio de Kubernetes

Una cuenta de servicio de Kubernetes proporciona una identidad para los procesos que se ejecutan en un Pod. Para obtener más información, consulte Administración de cuentas de servicio en la documentación de Kubernetes. Si su Pod necesita acceso a servicios de AWS, puede asignar la cuenta de servicio a una identidad de AWS Identity and Access Management para conceder ese acceso. Para obtener más información, consulte Roles de IAM para cuentas de servicio.

Tokens de cuenta de servicio

La característica BoundServiceAccountTokenVolume está habilitada de forma predeterminada en las versiones de Kubernetes. Esta función mejora la seguridad de los tokens de cuenta de servicio al permitir que las cargas de trabajo se ejecuten en Kubernetes para solicitar tokens web JSON que estén vinculados a la audiencia, la hora y la clave. Los tokens de cuenta de servicio tienen una caducidad de una hora. En versiones de Kubernetes anteriores, los tokens no tenían caducidad. Esto significa que los clientes que confían en estos tokens deben actualizar los tokens en una hora. Los siguientes ejemplos SDK de cliente de Kubernetes actualizan los tokens automáticamente dentro del plazo requerido:

  • Versión de Go 0.15.7 y posteriores

  • Versión de Python 12.0.0 y posteriores

  • Versión de Java 9.0.0 y posterior

  • Versión de JavaScript 0.10.3 y posterior

  • Rama de Ruby master

  • Versión de Haskell 0.3.0.0

  • Versión C# 7.0.5 y posterior

Si su carga de trabajo utiliza una versión de cliente anterior, debe actualizarla. Para permitir una migración fluida de los clientes a los tokens de cuenta de servicio con límite de tiempo más nuevos, Kubernetes agrega un período de vencimiento extendido al token de cuenta de servicio durante la hora predeterminada. Para los clústeres de Amazon EKS, el período de caducidad extendido es de 90 días. El servidor API de Kubernetes de los clústeres de Amazon EKS rechaza solicitudes con tokens de más de 90 días de antigüedad. Le recomendamos que compruebe sus aplicaciones y sus dependencias para asegurarse de que los SDK de cliente de Kubernetes son iguales o posteriores a las versiones indicadas anteriormente.

Cuando el servidor API recibe solicitudes con tokens de más de una hora de antigüedad, anota el evento de registro de auditoría de la API con annotations.authentication.k8s.io/stale-token. El valor de la anotación es similar al siguiente ejemplo:

subject: system:serviceaccount:common:fluent-bit, seconds after warning threshold: 4185802.

Si el clúster tiene un registro de Envío de los registros del plano de control a Registros de CloudWatchplano de control habilitado, entonces las anotaciones se encuentran en los registros de auditoría. Puede utilizar la siguiente consulta de CloudWatch Logs Insights para identificar todos los Pods del clúster de Amazon EKS que utilizan tokens obsoletos:

fields @timestamp
|filter @logStream like /kube-apiserver-audit/
|filter @message like /seconds after warning threshold/
|parse @message "subject: *, seconds after warning threshold:*\"" as subject, elapsedtime

El subject hace referencia a la cuenta de servicio que utilizó el Pod. El elapsedtime indica el tiempo transcurrido (en segundos) tras leer el último token. Las solicitudes al servidor API se denegan cuando el elapsedtime supera los 90 días (7 776 000 segundos). Debe actualizar de forma proactiva el SKD del cliente Kubernetes de las aplicaciones para utilizar una de las versiones enumeradas anteriormente que actualiza automáticamente el token. Si el token de cuenta de servicio utilizado dura casi 90 días y no tiene tiempo suficiente para actualizar las versiones del SDK de cliente antes de que el token caduque, puede terminar los Pods existentes y crear otros nuevos. Esto da como resultado la reactivación del token de la cuenta de servicio, lo que le da 90 días adicionales para actualizar los SDK de la versión de cliente.

Si el Pod forma parte de una implementación, la forma sugerida de finalizar los Pods y mantener la alta disponibilidad es realizar un despliegue con el siguiente comando. Reemplace my-deployment con el nombre de la implementación.

kubectl rollout restart deployment/my-deployment

Complementos de clúster

Los siguientes complementos de clúster se han actualizado para utilizar los SDK del cliente Kubernetes que reactivan automáticamente los tokens de cuentas de servicio. Recomendamos asegurarse de que las versiones enumeradas, o versiones posteriores, estén instaladas en su clúster.

Concesión de permisos a AWS Identity and Access Management a cargas de trabajo en clústeres de Amazon Elastic Kubernetes Service

Amazon EKS ofrece dos formas de conceder a AWS Identity and Access Management permisos a las cargas de trabajo que se ejecutan en los clústeres de Amazon EKS: los roles de IAM para cuentas de servicio y las identidades de Pod de EKS.

Roles de IAM para cuentas de servicio

Los roles de IAM para cuentas de servicio (IRSA) configuran las aplicaciones de Kubernetes que se ejecutan en AWS con permisos de IAM detallados para acceder a otros recursos de AWS, como los buckets de Amazon S3, las tablas de Amazon DynamoDB y más. Puede ejecutar varias aplicaciones juntas en el mismo clúster de Amazon EKS y asegurarse de que cada aplicación tenga solo el conjunto mínimo de permisos que necesita. IRSA se creó para admitir varias opciones de implementación de Kubernetes compatibles con AWS como Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service en AWS y clústeres de Kubernetes autoadministrados en instancias de Amazon EC2. Por lo tanto, IRSA se creó utilizando un servicio de AWS básico como IAM y no dependía directamente del servicio Amazon EKS ni de la API de EKS. Para obtener más información, consulte Roles de IAM para cuentas de servicio.

Pod Identities de EKS

Pod Identity de EKS ofrece a los administradores de clústeres un flujo de trabajo simplificado para autenticar las aplicaciones con el fin de acceder a otros recursos de AWS, como los buckets de Amazon S3, las tablas de Amazon DynamoDB y más. Pod Identity de EKS está dedicada solo para EKS y, como resultado, simplifica la forma en que los administradores de clústeres pueden configurar las aplicaciones de Kubernetes para obtener permisos de IAM. Estos permisos ahora se pueden configurar fácilmente con menos pasos: directamente a través de AWS Management Console, la API de EKS y AWS CLI, no es necesario realizar ninguna acción dentro del clúster ni en ningún objeto de Kubernetes. Los administradores de clústeres no necesitan cambiar entre los servicios de EKS y de IAM, ni utilizar operaciones de IAM privilegiadas para configurar los permisos que requieren sus aplicaciones. Los roles de IAM ahora se pueden usar en varios clústeres sin necesidad de actualizar la política de confianza de roles al crear nuevos clústeres. Las credenciales de IAM proporcionadas por Pod Identity de EKS incluyen etiquetas de sesión de rol, con atributos como el nombre del clúster, el espacio de nombres y el nombre de la cuenta de servicio. Las etiquetas de sesión de rol permiten a los administradores crear un único rol que puede funcionar en todas las cuentas de servicio, ya que permiten el acceso a los recursos de AWS en función de las etiquetas coincidentes. Para obtener más información, consulte Más información sobre cómo EKS Pod Identity concede a los pods acceso a los servicios de AWS.

Comparación de Pod Identity de EKS e IRSA

A un nivel alto, tanto Pod Identity de EKS como IRSA permiten conceder permisos de IAM a las aplicaciones que se ejecutan en clústeres de Kubernetes. Sin embargo, son fundamentalmente diferentes en cuanto a la forma de configurarlos, los límites admitidos y las funciones habilitadas. A continuación, comparamos algunos de los aspectos clave de ambas soluciones.

Atributo Pod Identity de EKS IRSA

Extensibilidad de roles

Debe configurar cada rol una vez para establecer una relación de confianza con el recién introducido pods.eks.amazonaws.com de director de servicio de Amazon EKS. Tras este único paso, no necesitará actualizar la política de confianza del rol cada vez que lo utilice en un clúster nuevo.

Debe actualizar la política de confianza del rol de IAM con el nuevo punto de conexión del proveedor OIDC de clústeres de EKS cada vez que desee utilizar el rol en un clúster nuevo.

Escalabilidad de los clústeres

Pod Identity de EKS no requiere que los usuarios configuren un proveedor de IAM OIDC, por lo que este límite no se aplica.

Cada clúster de EKS tiene una URL de emisor de OpenID Connect (OIDC) asociada. Para usar IRSA, es necesario crear un proveedor OpenID Connect único para cada clúster de EKS de IAM. IAM tiene un límite global predeterminado de 100 proveedores de OIDC para cada cuenta de AWS. Si planea tener más de 100 clústeres de EKS para cada cuenta de AWS con IRSA, alcanzará el límite de proveedor OIDC de IAM.

Escalabilidad de las funciones

Pod Identity de EKS no exige que los usuarios definan la relación de confianza entre el rol de IAM y la cuenta de servicio en la política de confianza, por lo que este límite no se aplica.

En IRSA, usted define la relación de confianza entre un rol de IAM y una cuenta de servicio en la política de confianza del rol. De forma predeterminada, el tamaño de la política de confianza es 2048. Esto significa que normalmente se pueden definir 4 relaciones de confianza en una sola política de confianza. Si bien puede aumentar el límite de duración de la política de confianza, normalmente está limitado a un máximo de 8 relaciones de confianza dentro de una sola política de confianza.

Reutilización de roles

Las credenciales temporales de AWS STS proporcionadas por Pod Identity de EKS incluyen etiquetas de sesión de rol, como el nombre del clúster, el espacio de nombres y el nombre de la cuenta de servicio. Las etiquetas de sesión de rol permiten a los administradores crear un único rol de IAM que se puede usar con varias cuentas de servicio, con diferentes permisos efectivos, ya que permiten el acceso a los recursos de AWS basados en las etiquetas adjuntas a ellas. Esto también se conoce como control de acceso basado en atributos (ABAC). Para obtener más información, consulte Concesión de acceso a los pods a los recursos de AWS en función de las etiquetas.

No se admiten etiquetas de sesión de AWS STS. Puede reutilizar un rol entre clústeres, pero cada pod recibe todos los permisos del rol.

Entornos compatibles

Pod Identity de EKS solo está disponible en Amazon EKS.

Se puede usar IRSA como Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service en AWS y clústeres de Kubernetes autoadministrados en instancias de Amazon EC2.

Versiones compatibles de EKS

Versiones 1.24 de Kubernetes de EKS o posteriores. Para saber las versiones de la plataforma específicas, consulte Versiones del clúster de Pod Identity de EKS.

Todas las versiones del clúster EKS compatibles.