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

Se aplica a: ✔️ AKS Automatic ✔️ AKS Standard

AKS usa la identidad en cinco escenarios distintos. Cada escenario responde a una pregunta diferente y tiene su propio modelo de configuración.

Para la mayoría de las cargas de trabajo de producción de AKS, AKS Automatic es la opción recomendada por defecto porque parte de una configuración base de la plataforma preparada para producción, incluidos los valores predeterminados relacionados con la identidad, a la vez que mantiene el mismo modelo de identidad de AKS descrito en este artículo.

En este artículo se ofrece una breve introducción a cada escenario, se explica cómo las directrices se aplican a AKS Automatic y AKS Standard, y se remite a la documentación detallada.

Los cinco escenarios de identidad en AKS

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

Postura de identidad en AKS Automatic y AKS Standard

Los cinco escenarios de identidad de este artículo se aplican tanto a AKS Automatic como a AKS Standard. La principal diferencia es la posición operativa:

  • AKS Automatic proporciona más identidades preconfiguradas y valores predeterminados de seguridad.
  • AKS Standard proporciona un mayor control manual y requiere más opciones de configuración.

Use AKS Automatic como punto de partida predeterminado para la mayoría de las cargas de trabajo de producción y use AKS Standard cuando necesite una configuración de plataforma personalizada más profunda.

Para obtener información general sobre AKS Automatic, consulte Introducción a Azure Kubernetes Service (AKS) Automático.

Comparación de la postura de identidad entre AKS Automatic y AKS Estándar

Área de identificación Postura automática de AKS Posición estándar de AKS Aprende más
Autenticación de la API de Kubernetes Valores predeterminados orientados a producción con Microsoft Entra integración como modelo recomendado Configurable, incluidas las cuentas locales y las opciones de integración de Entra Conceptos de autenticación de clúster
Autorización de api de Kubernetes Azure RBAC para la autorización de Kubernetes está preconfigurado Modelo de autorización con prioridad para cuentas locales seleccionado por la configuración del clúster Conceptos de autorización del clúster
Autorización de recursos de AKS Usa el modelo de RBAC de Azure estándar en las operaciones de recursos de AKS Usa el modelo de RBAC de Azure estándar en las operaciones de recursos de AKS Controlar el acceso a kubeconfig
Identidad del clúster Usa el modelo de identidad administrada con los valores predeterminados de línea base de producción Usa el modelo de identidad administrada con la configuración seleccionada por el operador Identidades administradas en AKS
Identidad de la carga de trabajo La identidad de carga de trabajo y el emisor de OIDC están preconfigurados Opcional y configurado por operador Descripción general de la identidad de carga de trabajo

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 las identidades y los 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 la mayoría de las cargas de trabajo de producción, empiece por AKS Automatic y la integración con Microsoft Entra.

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: el modelo nativo de Kubernetes Role, ClusterRoley RoleBinding evaluado por el servidor de API. Los permisos residen en el clúster como objetos de Kubernetes.
  • Autorización de Microsoft Entra ID: un webhook de autorización de AKS delega las decisiones de autorización a Microsoft Entra ID mediante asignaciones de roles en 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. Administre los permisos de forma centralizada en Microsoft Entra ID para 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.

En AKS Automatic, Azure RBAC para la autorización de Kubernetes viene preconfigurado como parte de la configuración predeterminada preparada para producción.

Para obtener una comparación 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. Esta operación usa RBAC estándar de Azure con respecto al proveedor de recursos Microsoft.ContainerService, está separada de la autorización de la API de Kubernetes y se aplica de la misma manera a AKS Automatic y AKS Standard. Para obtener más información, consulte Limitar el acceso al archivo de configuración del clúster y los roles integrados de 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: usada por el plano de control del clúster para administrar los recursos de Azure del clúster.
  • Identidad del kubelet: La usa el kubelet de cada nodo para autenticarse ante servicios como Azure Container Registry.
  • Identidad de complementos o extensiones: algunos complementos y extensiones de AKS usan sus propias identidades administradas.

AKS Automatic mantiene este mismo modelo de identidad al tiempo que reduce la fricción de configuración a través de los valores predeterminados de producción preconfigurados.

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.

AKS Automatic incluye la identidad de la carga de trabajo y el emisor OIDC como valores predeterminados preconfigurados. En AKS Standard, estas funcionalidades son opcionales y configuradas por el operador.

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
Empieza con una línea de base de identidad lista para producción para la mayoría de las cargas de trabajo Introducción a AKS Automatic
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
Creación de un clúster listo para producción con la posición de identidad predeterminada Creación de un clúster automático de AKS

Referencia de permisos de servicio de AKS

Para los permisos de Azure que usa 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.

Contenido relacionado

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

  • Last updated on