Opciones de acceso e identidad para Azure Kubernetes Service (AKS)

AKS usa la identidad en cinco escenarios distintos. Cada escenario responde a una pregunta diferente y tiene su propio modelo de configuración. En este artículo se ofrece una breve introducción a cada tema y se señala la documentación exhaustiva.

Los cinco escenarios de identidad en AKS

Escenario Preguntas que responde Documentación en profundidad
A. Autenticación de plano de control de Kubernetes ¿Quién es el autor de la llamada que alcanza la API de Kubernetes? Conceptos de autenticación de clúster, proveedores de identidades externos
B. Autorización del plano de control de Kubernetes ¿Qué puede hacer el autor de la llamada una vez autenticado en la API de Kubernetes? Conceptos de autorización del clúster
C. Autorización de recursos de AKS (Azure Resource Manager) ¿Quién puede realizar operaciones a nivel Azure en el recurso de AKS, como extraer kubeconfig? Limitar el acceso al archivo de configuración del clúster, los roles integrados de Azure
D. Identidad de clúster (clúster → Azure) ¿Cómo actúa el clúster de AKS en Azure para administrar recursos en su nombre? Identidades administradas en AKS
E. Identidad de carga de trabajo (pod → Azure) ¿Cómo se autentican los pods en servicios de Azure, como Key Vault o Storage? Introducción al identificador de carga de trabajo de Microsoft Entra

El resto de este artículo ofrece una breve orientación a cada escenario.

A. Autenticación de plano de control de Kubernetes

La autenticación del plano de control de Kubernetes establece la identidad de un usuario o entidad de servicio que llama al servidor de API de Kubernetes. AKS admite:

  • Microsoft Entra ID (recomendado). Use identidades y grupos de Entra ID para iniciar sesión en el clúster. Microsoft Entra integration aprovisiona y gestiona la integración para usted. Para habilitarlo, consulte Uso de la integración de Microsoft Entra.
  • Cuentas locales. Un certificado de administrador de clúster integrado que omite entra ID. Se recomienda deshabilitar las cuentas locales en producción. Consulte Administración de cuentas locales.
  • Proveedores de identidades externos. Use un proveedor de identidades compatible con OIDC que no sea Microsoft Entra ID. Consulte Autenticación del proveedor de identidades externo.

Para obtener información detallada sobre cómo AKS autentica las solicitudes de API de Kubernetes, consulte Conceptos de autenticación de clústeres.

B. Autorización del plano de control de Kubernetes

Una vez autenticado un autor de llamada en la API de Kubernetes, AKS autoriza la solicitud mediante uno (o ambos) de dos modelos:

  • RBAC de Kubernetes. Modelo nativo de Kubernetes Role / ClusterRole / RoleBinding evaluado por el servidor de API. Los permisos residen en el clúster como objetos de Kubernetes.
  • Autorización de ID de Microsoft Entra. Un webhook de autorización de AKS delega las decisiones de autorización a Microsoft Entra ID utilizando asignaciones de roles de Azure. Las asignaciones de roles de Azure RBAC con dataActions son compatibles con todos los recursos estándar de la API de Kubernetes, y se admiten asignaciones de roles con condiciones de Azure ABAC para recursos personalizados. Los permisos se administran de forma centralizada en el identificador de Microsoft Entra y pueden controlar muchos clústeres desde una sola asignación de roles en el ámbito de suscripción, grupo de administración o grupo de recursos.

Para obtener una comparación en paralelo e instrucciones sobre cuándo usar cada modelo, consulte Conceptos de autorización de clústeres.

C. Autorización de recursos de AKS (Azure Resource Manager)

Además de autorizar las llamadas a la API de Kubernetes, también debe autorizar las operaciones a nivel de Azure en el recurso AKS. El ejemplo más común es controlar quién puede gestionar un kubeconfigclúster, que es una operación independiente de Azure Resource Manager que puede gobernar detalladamente con RBAC de Azure. Este es el estándar de RBAC de Azure para el Microsoft.ContainerService proveedor de recursos, separando de esta forma la autorización de la API de Kubernetes. Consulte en Limitar el acceso al archivo de configuración del clúster y en los roles integrados en Azure.

D. Identidad de clúster (clúster → Azure)

Los clústeres de AKS usan identidades administradas de Azure para actuar en los recursos de Azure en su nombre, por ejemplo, para crear equilibradores de carga, conectar discos o extraer imágenes de Azure Container Registry. Las identidades principales son:

  • Identidad del plano de control. Lo usa el plano de control del clúster para administrar los recursos de Azure para el clúster.
  • Identidad de Kubelet. Lo usa kubelet en cada nodo para autenticarse en servicios como Azure Container Registry.
  • Identidad de complementos o extensiones. Algunos complementos y extensiones de AKS usan sus propias identidades administradas.

Para más información sobre cada tipo de identidad y cómo usar identidades asignadas por el sistema frente a identidades asignadas por el usuario, consulte Identidades administradas en AKS.

E. Identidad de carga de trabajo (pod → Azure)

La identidad de carga de trabajo permite que los pods que se ejecutan en el clúster de AKS se autentiquen en los servicios de Azure protegidos por Entra de Microsoft (como Key Vault, Storage o Cosmos DB) sin almacenar secretos en el clúster. AKS usa el identificador de carga de trabajo de Microsoft Entra, que proyecta un token de cuenta de servicio de Kubernetes federado a una aplicación de Microsoft Entra o a una identidad administrada asignada por el usuario.

No use la identidad administrada por pods de Microsoft Entra obsoleta para las nuevas cargas de trabajo.

Guía para la toma de decisiones

Objetivo Uso de estos documentos
Inicia sesión de los usuarios en el clúster con Microsoft Entra ID Habilitación de la integración de Microsoft Entra
Controlar quién puede hacer lo que en la API de Kubernetes en muchos clústeres Usa la autorización de Microsoft Entra ID para la API de Kubernetes
Restricción del acceso a tipos de recursos personalizados específicos Condiciones ABAC para la autorización en Entra ID
Otorgar permisos por clúster y por espacio de nombres como objetos de Kubernetes Utilice RBAC de Kubernetes con integración de Entra
Permitir que el clúster extraiga de ACR o conecte discos Identidades administradas en AKS
Permitir que los pods lleguen a Key Vault o Storage sin secretos Introducción al identificador de carga de trabajo de Microsoft Entra
Restricción de quién puede descargar el clúster kubeconfig Limitar el acceso al archivo de configuración del clúster

Referencia de permisos de servicio de AKS

Para los permisos de Azure usados por AKS ( la identidad que crea el clúster, la identidad del clúster en tiempo de ejecución, los permisos de identidad de clúster adicionales y el acceso al nodo de AKS), consulte referencia de permisos de servicio de AKS.

Pasos siguientes

Para obtener más información sobre los conceptos básicos de Kubernetes y AKS, consulte los artículos siguientes:

  • Last updated on