Identidad y acceso de las cargas de trabajo de Kubernetes

En este artículo se describe cómo Amazon Elastic Kubernetes Service (Amazon EKS) y Azure Kubernetes Service (AKS) proporcionan identidad para que las cargas de trabajo de Kubernetes accedan a los servicios de plataforma en la nube. Para obtener una comparación detallada de Amazon Web Services (AWS), Identity and Access Management (IAM) y Microsoft Entra ID, consulte:

• Administración de identidades y acceso de Microsoft Entra para AWS
• Asignación de conceptos de IAM de AWS a otros similares en Azure

En esta guía se explica cómo los clústeres de AKS, los servicios integrados y los complementos usan identidades administradas para acceder a recursos de Azure, como equilibradores de carga y discos administrados. En el artículo, también se muestra cómo usar Microsoft Entra Workload ID para que las cargas de trabajo de AKS puedan acceder a los recursos de Azure sin necesidad de una cadena de conexión, una clave de acceso o credenciales de usuario.

Administración de la identidad y acceso de Amazon EKS

Amazon Elastic Kubernetes Service (EKS) proporciona opciones nativas para administrar la administración de identidades y acceso en pods de Kubernetes. Estas opciones incluyen roles de IAM para cuentas de servicio y roles vinculados al servicio de Amazon EKS.

Roles de IAM para cuentas de servicio

Los roles de IAM para las cuentas de servicio permiten asociar roles de IAM con cuentas de servicio de Kubernetes. Esta asociación proporciona permisos de AWS a los contenedores dentro de cualquier pod que use la cuenta de servicio. Las ventajas de usar roles de IAM para cuentas de servicio son las siguientes:

• privilegios mínimos: puede asignar permisos de IAM específicos a una cuenta de servicio, lo que garantiza que solo los pods que usen esa cuenta de servicio tengan acceso a esos permisos. Esto elimina la necesidad de conceder permisos extendidos al rol de IAM de nodo para todos los pods de un nodo, lo que proporciona un enfoque más seguro y granular. Además, esta característica elimina la necesidad de soluciones de terceros como kube2iam. Para obtener más información, consulte roles de IAM para cuentas de servicio.

• aislamiento de credenciales: cada contenedor de un pod solo puede recuperar las credenciales del rol de IAM asociado a su cuenta de servicio correspondiente. Este aislamiento garantiza que un contenedor no pueda acceder a las credenciales que pertenecen a otro contenedor en un pod diferente.

• auditoría: Amazon EKS aprovecha amazon CloudTrail para proporcionar acceso y registro de eventos, lo que facilita la auditoría retrospectiva y el cumplimiento.

Para obtener más información sobre los roles de IAM para las cuentas de servicio, consulte la documentación oficial de .

Roles vinculados a servicios de Amazon EKS

Los roles vinculados a servicios de Amazon EKS son roles de IAM únicos vinculados directamente a Amazon EKS. Estos roles predefinidos incluyen todos los permisos necesarios para llamar a los servicios de AWS en nombre del rol asociado. El rol principal vinculado al servicio para Amazon EKS es el rol de IAM de nodo de Amazon EKS .

El nodo Amazon EKS kubelet demonio utiliza el rol IAM del nodo Amazon EKS para realizar llamadas API a los servicios de AWS en nombre del nodo. El perfil de instancia de IAM y las directivas asociadas proporcionan permisos para estas llamadas API. Esta configuración simplifica la administración de roles de IAM para nodos dentro del clúster EKS.

Para obtener más información sobre los roles vinculados a servicios de Amazon EKS, visite la documentación oficial de .

Información adicional

Además de los roles de IAM para las cuentas de servicio y los roles vinculados a servicios de Amazon EKS, hay otros aspectos esenciales para administrar la identidad y el acceso en Amazon EKS.

1. la autorización RBAC de Amazon EKS: Amazon EKS admite el control de acceso basado en rol (RBAC), lo que le permite definir permisos específicos para los recursos de Kubernetes dentro del clúster.

2. AWS Identity and Access Management (IAM): IAM proporciona una solución completa de administración de identidades para los servicios de AWS, incluido EKS. Permite crear y administrar usuarios, grupos y roles para controlar el acceso a los recursos de EKS.

3. grupos de seguridad de Amazon EKS: Amazon EKS le permite aplicar reglas de grupo de seguridad a los pods que se ejecutan dentro del clúster para controlar el tráfico entrante y saliente.

Para obtener más información sobre cómo administrar la administración de identidades y acceso en Amazon EKS, consulte la documentación oficial de Amazon EKS .

Identidades administradas por el clúster de AKS

Los clústeres de Azure Kubernetes Service (AKS) requieren un identidad de Microsoft Entra acceder a recursos de Azure, como equilibradores de carga y discos administrados. Las identidades administradas para recursos de Azure son la manera recomendada de autorizar el acceso desde un clúster de AKS a otros servicios de Azure.

¿Qué son las identidades administradas?

Un desafío común para los desarrolladores es la administración de secretos, credenciales, certificados y claves que se usan para proteger la comunicación entre los servicios. identidades administradas eliminar la necesidad de que los desarrolladores administren estas credenciales. Las identidades administradas permiten autenticar el clúster de AKS sin administrar credenciales ni incluirlas en el código. Con las identidades administradas, asigna un rol de control de acceso basado en rol (RBAC de Azure) de Azure a la identidad, concediéndole permisos a recursos específicos en Azure.

Estos son dos tipos de identidades administradas:

• asignados por el sistema. Algunos recursos de Azure, como las máquinas virtuales, permiten habilitar una identidad administrada directamente en el recurso. Al habilitar una identidad administrada asignada por el sistema:

  • Se crea una entidad de servicio de un tipo especial en microsoft Entra ID para la identidad. La entidad de servicio está vinculada al ciclo de vida de ese recurso de Azure. Cuando se elimina el recurso de Azure, Azure elimina automáticamente la entidad de servicio automáticamente.
  • Por diseño, solo ese recurso de Azure puede usar esta identidad para solicitar tokens de Microsoft Entra ID.
  • Autoriza a la identidad administrada a tener acceso a uno o varios servicios.
  • El nombre de la entidad de servicio asignada por el sistema siempre es el mismo que el nombre del recurso de Azure para el que se crea.

• asignado por el usuario. También puede crear una identidad administrada como un recurso de Azure independiente. Puede crear una identidad administrada asignada por el usuario y asignarla a uno o varios recursos de Azure. Al habilitar una identidad administrada asignada por el usuario:

  • Se crea una entidad de servicio de un tipo especial en microsoft Entra ID para la identidad. La entidad de servicio se administra independientemente de los recursos que lo usan.
  • Varios recursos pueden usar identidades asignadas por el usuario.
  • Autoriza a la identidad administrada a tener acceso a uno o varios servicios.

Para obtener más información sobre las diferencias entre los dos tipos de identidades administradas, consulte tipos de identidad administrada.

Identidades administradas en Azure Kubernetes Service (AKS)

Estos dos tipos de identidades administradas son similares en que puede usar cualquier tipo para autorizar el acceso a los recursos de Azure desde el clúster de AKS. La diferencia clave entre ellos es que una identidad administrada asignada por el sistema está asociada a un único recurso de Azure, como un clúster de AKS, mientras que una identidad administrada asignada por el usuario es un recurso de Azure independiente. Para más información sobre las diferencias entre los tipos de identidades administradas, consulte tipos de identidad administrada en Identidades administradas para recursos de Azure.

Hay tres tipos de identidades administradas que puede usar con un clúster de AKS:

1. identidad administrada asignada por el sistema: Este tipo de identidad administrada está asociada a un único recurso de Azure, como un clúster de AKS. Solo existe para el ciclo de vida del clúster.

2. identidad administrada asignada por el usuario: Una identidad administrada asignada por el usuario es un recurso de Azure independiente que puede usar para autorizar el acceso a otros servicios de Azure desde el clúster de AKS. Se conserva por separado del clúster y se puede usar en varios recursos de Azure.

3. identidad administrada kubelet creada previamente: Se trata de una identidad opcional asignada por el usuario que el kubelet puede usar para acceder a otros recursos de Azure. Si no se especifica ninguna identidad administrada asignada por el usuario para kubelet, AKS crea una identidad kubelet asignada por el usuario en el grupo de recursos de nodo.

¿Cómo usa AKS las identidades administradas?

Al implementar un clúster de AKS, se crea automáticamente una identidad administrada asignada por el sistema . También puede crear el clúster con una identidad administrada asignada por el usuario . El clúster usa esta identidad administrada para solicitar tokens de Microsoft Entra ID, que se usan para autorizar el acceso a otros recursos que se ejecutan en Azure.

Mediante la asignación de un rol de RBAC de Azure a la identidad administrada, puede conceder a los clústeres permisos para acceder a recursos específicos. Por ejemplo, puede asignar la identidad administrada a un rol de RBAC de Azure que le permita acceder a secretos en una instancia de Azure Key Vault. De este modo, puede autorizar fácilmente el acceso al clúster sin administrar las credenciales.

Uso de identidades administradas en AKS

Al usar identidades administradas en AKS, no es necesario aprovisionar ni rotar ningún secreto. Azure administra las credenciales de la identidad. Esto le permite autorizar el acceso desde las aplicaciones sin administrar secretos adicionales.

Si ya tiene un clúster de AKS que usa una identidad administrada, puede actualizarlo a otro tipo de identidad administrada. Sin embargo, tenga en cuenta que puede haber un retraso mientras los componentes del plano de control cambian a la nueva identidad. Este proceso puede tardar varias horas y, durante este tiempo, los componentes del plano de control seguirán usando la identidad antigua hasta que expire su token.

Resumen de identidades administradas usadas por AKS

AKS usa diferentes tipos de identidades administradas para habilitar varios servicios y complementos integrados. Este es un resumen de las identidades administradas que usa AKS:

Para más información sobre las identidades administradas en AKS, consulte Uso de una identidad administrada en Azure Kubernetes Service.

Microsoft Entra Workload ID para Kubernetes

id. de carga de trabajo de Microsoft Entra se integra con Kubernetes para permitir que las cargas de trabajo implementadas en un clúster de AKS accedan a recursos protegidos de Microsoft Entra, como Azure Key Vault y Microsoft Graph. Usa las funcionalidades nativas de Kubernetes para federarse con proveedores de identidades externos. Para más información, consulte Uso del identificador de carga de trabajo de Microsoft Entra con Azure Kubernetes Service.

Para usar el identificador de carga de trabajo de Microsoft Entra, debe configurar una cuenta de servicio en Kubernetes. A continuación, los pods usan esta cuenta de servicio para autenticar y acceder a los recursos de Azure de forma segura. El identificador de carga de trabajo de Microsoft Entra funciona bien con las bibliotecas cliente de Identidad de Azure o la colección de la Biblioteca de autenticación de Microsoft (MSAL), junto con el registro de aplicaciones.

Para aprovechar completamente el identificador de carga de trabajo de Microsoft Entra en un clúster de Kubernetes, debe configurar el clúster de AKS para emitir tokens y publicar un documento de detección de OIDC para la validación de tokens. Para más información, consulte Creación de un proveedor de OpenID Connect en Azure Kubernetes Service.

También debe configurar las aplicaciones de Microsoft Entra para confiar en los tokens de Kubernetes. A continuación, los desarrolladores pueden configurar sus implementaciones para que usen cuentas de servicio de Kubernetes para obtener tokens, que luego se intercambian por tokens de Microsoft Entra por el identificador de carga de trabajo de Microsoft Entra. Por último, las cargas de trabajo de clúster de AKS pueden usar estos tokens de Microsoft Entra para acceder de forma segura a los recursos protegidos en Azure.

Como se muestra en el diagrama siguiente, el clúster de Kubernetes se convierte en un emisor de tokens de seguridad que emite tokens a cuentas de servicio de Kubernetes. Puede configurar estos tokens para que sean de confianza en aplicaciones de Microsoft Entra. A continuación, los tokens se pueden intercambiar para los tokens de acceso de Microsoft Entra mediante los SDK de identidad de Azure o la biblioteca de autenticación de Microsoft (MSAL).

1. El agente kubelet proyecta un token de cuenta de servicio en la carga de trabajo en una ruta de acceso de archivo configurable.
2. La carga de trabajo de Kubernetes envía el token de cuenta de servicio proyectado y firmado a Microsoft Entra ID y solicita un token de acceso.
3. Microsoft Entra ID usa un documento de detección de OIDC para comprobar la confianza en la identidad administrada definida por el usuario o la aplicación registrada y validar el token entrante.
4. Microsoft Entra ID emite un token de acceso de seguridad.
5. La carga de trabajo de Kubernetes accede a los recursos de Azure mediante el token de acceso de Microsoft Entra.

Para obtener más información, documentación y automatización relacionada con el identificador de carga de trabajo de Microsoft Entra, consulte los siguientes recursos:

• proyecto de código abierto azure Workload Identity
• Federación de identidades de carga de trabajo
• Federación de Microsoft Entra Workload ID con Kubernetes
• Federación de Microsoft Entra Workload ID con proveedores de identidades OIDC externos
• Federación mínima de Microsoft Entra Workload ID
• documentación del identificador de carga de trabajo de Microsoft Entra
• Inicio rápido de Microsoft Entra Workload ID
• ejemplo: Uso del identificador de carga de trabajo de Microsoft Entra para Kubernetes con una identidad administrada asignada por el usuario en una aplicación .NET Standard

Carga de trabajo de ejemplo

Una carga de trabajo de ejemplo que se ejecuta en un clúster de AKS consta de un front-end y un servicio back-end. Estos servicios usan el identificador de carga de trabajo de Microsoft Entra para acceder a los servicios de Azure, incluidos Azure Key Vault, Azure Cosmos DB, la cuenta de Azure Storage y el espacio de nombres de Azure Service Bus. Para configurar esta carga de trabajo de ejemplo, se deben cumplir los siguientes requisitos previos:

1. Configure un clúster de AKS con el del emisor de OpenID Connect OpenID Connect y habilitado el identificador de carga de trabajo de Microsoft Entra.
2. Cree una cuenta de servicio de Kubernetes en el espacio de nombres de carga de trabajo.
3. Cree una identidad administrada asignada por el usuario de Microsoft Entra o aplicación registrada.
4. Establezca una credencial de identidad federada entre la identidad administrada de Microsoft Entra o la aplicación registrada y la cuenta de servicio de carga de trabajo.
5. Asigne los roles necesarios con los permisos adecuados a la identidad administrada de Microsoft Entra o a la aplicación registrada.
6. Implemente la carga de trabajo y compruebe la autenticación con la identidad de carga de trabajo.

Flujo de mensajes de Microsoft Entra Workload ID

En esta carga de trabajo de ejemplo, las aplicaciones front-end y back-end adquieren tokens de seguridad de Microsoft Entra para acceder a los servicios de plataforma como servicio (PaaS) de Azure. En el diagrama siguiente se muestra el flujo de mensajes:

Descargue un archivo Visio de esta arquitectura.

1. Kubernetes emite un token al pod cuando se programa en un nodo, en función del pod o de las especificaciones de implementación.
2. El pod envía el token emitido por OIDC a Microsoft Entra ID para solicitar un token de Microsoft Entra para el appId y recurso específicos.
3. Microsoft Entra ID comprueba la confianza en la aplicación y valida el token entrante.
4. Microsoft Entra ID emite un token de seguridad: {sub: appId, aud: requested-audience}.
5. El pod usa el token de Microsoft Entra para acceder al recurso de Azure de destino.

Para usar Microsoft Entra Workload ID de un extremo a otro en un clúster de Kubernetes:

1. Configure el clúster de AKS para emitir tokens y publicar un documento de detección de OIDC para permitir la validación de estos tokens.
2. Configure las aplicaciones de Microsoft Entra para que confíen en los tokens de Kubernetes.
3. Los desarrolladores configuran sus implementaciones para usar las cuentas de servicio de Kubernetes para obtener tokens de Kubernetes.
4. Microsoft Entra Workload ID intercambia los tokens de Kubernetes para los tokens de Microsoft Entra.
5. Las cargas de trabajo de clúster de AKS usan los tokens de Microsoft Entra para acceder a recursos protegidos, como Microsoft Graph.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

• Paolo Salvatori | Ingeniero de servicio principal
• Martin Gjoshevski | Ingeniero principal de servicio

Otros colaboradores:

• Laura Nicolas | Ingeniera de software sénior
• Chad Kittel | Ingeniero principal de software
• Ed Price | Responsable sénior de programas de contenido
• Theano Petersen | Escritor técnico

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

• AKS para profesionales de Amazon EKS
• Supervisión y registro de Kubernetes
• Protección del acceso de red a Kubernetes
• Opciones de almacenamiento para un clúster de Kubernetes
• Administración de costos para Kubernetes
• Administración de nodos y grupos de nodos de Kubernetes
• Gobernanza de clústeres
• Administración de identidades y acceso de Microsoft Entra para AWS

Recursos relacionados

• Use una entidad de servicio con Azure Kubernetes Service (AKS)
• Uso de una identidad administrada en Azure Kubernetes Service
• Implementación de Azure Kubernetes Service (AKS)
• Administración de la identidad y el acceso en Microsoft Entra ID