Editar

Compartir vía

Identidad y acceso de las cargas de trabajo de Kubernetes

Microsoft Entra ID
Azure Kubernetes Service (AKS)

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:

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.

Nota:

Este artículo forma parte de una serie de artículos que ayudan a los profesionales que están familiarizados con Amazon EKS a comprender Azure Kubernetes Service (AKS).

Administración de la identidad y acceso de Amazon EKS

Amazon EKS tiene dos opciones nativas para llamar a servicios de AWS desde un pod de Kubernetes: roles de IAM para cuentas de servicio y roles vinculados a servicios de Amazon EKS.

Los roles de IAM para cuentas de servicio asocian roles de IAM a una cuenta de servicio de Kubernetes. Esta cuenta de servicio proporciona permisos de AWS a los contenedores de cualquier pod que use la cuenta de servicio. Los roles de IAM para las cuentas de servicio proporcionan las siguientes ventajas:

  • Privilegios mínimos: no es necesario proporcionar permisos extendidos al rol de IAM de nodo para pods de ese nodo para llamar a las API de AWS. Puede establecer el ámbito de los permisos de IAM a una cuenta de servicio y solo los pods que usan esa cuenta de servicio tienen acceso a esos permisos. Esta característica también elimina la necesidad de soluciones de terceros, como kiam o kube2iam.

  • Aislamiento de credenciales: un contenedor solo puede recuperar las credenciales del rol de IAM asociado a la cuenta de servicio a la que pertenece. Un contenedor nunca tiene acceso a las credenciales de otro contenedor que pertenece a otro pod.

  • Capacidad de audición: Amazon CloudTrail proporciona acceso y registro de eventos para ayudar a garantizar la auditoría retrospectiva.

Los roles vinculados a servicios de Amazon EKS son roles de IAM únicos que están vinculados directamente a Amazon EKS. Amazon EKS predefine los roles vinculados a servicios e incluye todos los permisos necesarios para llamar a otros servicios de AWS en nombre del rol. Para el rol IAM de nodo de Amazon EKS, el demonio kubelet de nodo de Amazon EKS llama a las API de AWS en nombre del nodo. Los nodos obtienen permisos para estas llamadas API desde un perfil de instancia de IAM y directivas asociadas.

Identidades administradas por el clúster de AKS

Para acceder a los recursos de Azure, como los equilibradores de carga y los discos administrados, un clúster de AKS requiere una identidad. Esta identidad puede ser una identidad administrada o una entidad de servicio. De forma predeterminada, la creación de un clúster de AKS crea automáticamente una identidad administrada asignada por el sistema. La plataforma Azure administra la identidad y no es necesario aprovisionar ni rotar ningún secreto. Para más información sobre las identidades administradas, consulte Identidades administradas para recursos de Azure administradas por Microsoft Entra.

AKS no crea automáticamente una entidad de servicio, por lo que si desea usar una entidad de servicio, debe crearla. La entidad de servicio expira finalmente y debe renovarla para mantener el clúster en funcionamiento. La administración de entidades de servicio agrega complejidad, por lo que es más fácil usar identidades administradas.

Básicamente, las identidades administradas son contenedores en torno a entidades de servicio que simplifican la administración. Se aplican los mismos requisitos de permisos tanto a las entidades de servicio como a las identidades administradas. Las identidades administradas usan la autenticación basada en certificados. Las credenciales de cada identidad administrada expiran al cabo de 90 días y se revierten tras 45 días.

AKS usa tipos de identidad administrada asignados tanto por el sistema como por el usuario; estas identidades son inmutables. Al crear o usar una red virtual de AKS, un disco de Azure conectado, una dirección IP estática, una tabla de rutas o una identidad kubelet asignada por el usuario con recursos fuera del grupo de recursos de nodo, la CLI de Azure agrega automáticamente la asignación de roles.

Si usa otro método para crear el clúster de AKS, como una plantilla de Bicep, una plantilla de Azure Resource Manager o un módulo de Terraform, debe usar el id. de la entidad de seguridad de la identidad administrada del clúster para realizar una asignación de roles. La identidad del clúster de AKS debe tener al menos el rol Colaborador de la red en la subred de la red virtual. Para definir un rol personalizado en lugar de usar el rol integrado Colaborador de la red, necesita los permisos siguientes:

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

Cuando la identidad del clúster necesita acceder a un recurso existente, por ejemplo, al implementar un clúster de AKS en una red virtual existente, debe usar una identidad administrada asignada por el usuario. Si usa una identidad de plano de control asignada por el sistema, el proveedor de recursos no puede obtener su id. de entidad de seguridad antes de crear el clúster, por lo que es imposible crear las asignaciones de roles adecuadas antes del aprovisionamiento del clúster.

Resumen de identidades administradas

AKS usa las siguientes identidades administradas asignadas por el usuario para servicios integrados y complementos.

Identidad Nombre Caso de uso Permisos predeterminados Traiga su propia identidad
Plano de control Nombre del clúster de AKS Administra los recursos del clúster, incluidos los equilibradores de carga de entrada y las direcciones IP públicas administradas por AKS, el escalador automático de clústeres y los controladores CSI de disco de Azure y archivo de Azure Rol de colaborador para grupo de recursos de nodo Compatible
Kubelet Nombre de clúster de AKS-agentpool Autentica con Azure Container Registry N/D (para kubernetes 1.15 y versiones posteriores) Compatible
Complemento HTTPApplicationRouting Administra los recursos de red necesarios Rol de lector para grupo de recursos de nodo, rol colaborador para zona DNS No
Complemento Ingresar a la puerta de enlace de aplicaciones Administra los recursos de red necesarios Rol de colaborador para grupo de recursos de nodo No
Complemento omsagent Enviar métricas de AKS a Azure Monitor Supervisión del rol del publicador de métricas No
Complemento Nodo virtual (ACIConnector) Administra los recursos de red necesarios para Azure Container Instances Rol de colaborador para grupo de recursos de nodo No

Para obtener más información, consulte Uso de una identidad administrada en Azure Kubernetes Service.

Microsoft Entra Workload ID para Kubernetes

Las cargas de trabajo de Kubernetes requieren credenciales de aplicación de Microsoft Entra para acceder a los recursos protegidos por Microsoft Entra, como Azure Key Vault y Microsoft Graph. Una dificultad común para los desarrolladores es cómo administrar los secretos y las credenciales que protegen la comunicación entre los distintos componentes de una solución.

Microsoft Entra Workload ID para Kubernetes elimina la necesidad de administrar las credenciales para acceder a servicios en la nube como Azure Cosmos DB, Azure Key Vault o Azure Blob Storage. Una aplicación de carga de trabajo hospedada en AKS puede usar el identificador de carga de trabajo de Microsoft Entra para acceder a un servicio administrado de Azure mediante un token de seguridad de Microsoft Entra, en lugar de credenciales explícitas como una cadena de conexión, un nombre de usuario y una contraseña o una clave principal.

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

Diagrama que muestra un flujo de trabajo simplificado para una identidad administrada de pod en Azure.

  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.

La federación de Microsoft Entra Workload ID para Kubernetes solo se admite actualmente para las aplicaciones de Microsoft Entra, pero el mismo modelo podría extenderse potencialmente a identidades administradas de Azure.

Para obtener más información, automatización y documentación sobre Microsoft Entra Workload ID, consulte:

Carga de trabajo de ejemplo

La carga de trabajo de ejemplo ejecuta un front-end y un servicio back-end en un clúster de AKS. Los servicios de carga de trabajo usan Microsoft Entra Workload ID para acceder a los siguientes servicios de Azure mediante tokens de seguridad de Microsoft Entra:

  • Azure Key Vault
  • Azure Cosmos DB
  • Cuenta de Azure Storage
  • Espacio de nombres de Azure Service Bus

Requisitos previos

  1. Configure un clúster de AKS con el emisor de OIDC habilitado.
  2. Instale el webhook de mutación de admisión.
  3. Cree una cuenta de servicio de Kubernetes para las cargas de trabajo.
  4. Cree una aplicación de Microsoft Entra como se muestra en el inicio rápido.
  5. Asigne roles con los permisos adecuados a las aplicaciones registradas de Microsoft Entra necesarias.
  6. Establezca una credencial de identidad federada entre la aplicación de Microsoft Entra y el emisor y el sujeto de la cuenta de servicio.
  7. Implemente la aplicación de la carga de trabajo en el clúster de AKS.

Flujo de mensajes de Microsoft Entra Workload ID

Las aplicaciones de AKS obtienen tokens de seguridad para su cuenta de servicio del emisor de OIDC del clúster de AKS. Microsoft Entra Workload ID intercambia los tokens de seguridad con tokens de seguridad emitidos por Microsoft Entra ID, y las aplicaciones usan los tokens de seguridad emitidos por el identificador de Microsoft Entra para acceder a los recursos de Azure.

En el diagrama siguiente, se muestra cómo las aplicaciones de front-end y back-end adquieren tokens de seguridad de Microsoft Entra para usar servicios de plataforma como servicio (PaaS) de Azure.

Diagrama que muestra una aplicación de ejemplo que usa el ID de carga de trabajo de Microsoft Entra.

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:

Otros colaboradores:

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

Pasos siguientes