Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se proporciona información general sobre las identidades administradas asignadas por el sistema y asignadas por el usuario en AKS, incluido cómo funcionan, las asignaciones de roles y las características de identidad administrada específicas de AKS.
Para más información sobre las identidades administradas en Azure, consulte la documentación sobre identidades administradas para recursos de Azure.
Nota:
Las identidades administradas cubren el escenario de identidad de clúster a Azure en AKS: cómo actúa el clúster de AKS en Azure para administrar los recursos en su nombre. Para los otros escenarios de identidad (autenticación y autorización del plano de control, e identidad de carga de trabajo de pod a Azure), consulte Opciones de acceso e identidad para AKS.
Nota:
Los tipos de identidad asignados por el sistema y asignados por el usuario difieren de una identidad de carga de trabajo, que está pensada para su uso por una aplicación que se ejecuta en un pod.
Flujo de autorización de identidad administrada de AKS
Los clústeres de AKS usan identidades administradas asignadas por el sistema o asignadas por el usuario para solicitar tokens de Microsoft Entra. Estos tokens ayudan a autorizar el acceso a otros recursos que se ejecutan en Azure. Asigne un rol de control de acceso basado en rol de Azure (RBAC de Azure) a la identidad administrada para concederle permisos a un recurso de Azure determinado. Por ejemplo, puede conceder permisos a una identidad administrada para acceder a secretos en un almacén de claves de Azure para que lo use el clúster.
Comportamiento de la identidad administrada en AKS
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 o actualizar un clúster existente a otro tipo de identidad administrada.
Si el clúster ya usa una identidad administrada y cambia el tipo de identidad (por ejemplo, de asignado por el sistema a asignado por el usuario), hay un retraso mientras los componentes del plano de control cambian a la nueva identidad. Los componentes del plano de control siguen usando la identidad antigua hasta que expire el token de la identidad anterior. Después de actualizar el token, cambian a la nueva identidad. Este proceso puede tardar varias horas.
Nota:
También puede crear un clúster con una entidad de servicio de aplicación en lugar de una identidad administrada. Sin embargo, use una identidad administrada a través de una entidad de servicio de aplicación para mayor seguridad y facilidad de uso. Si tiene un clúster existente que usa un principal de servicio de aplicación, puede actualizarlo para usar una identidad administrada.
Administración de identidades y credenciales de AKS
La plataforma Azure administra tanto las identidades administradas asignadas por el sistema como las asignadas por el usuario y sus credenciales, por lo que se puede autorizar acceso desde sus aplicaciones sin necesidad de aprovisionar ni cambiar ningún secreto.
Identidad administrada asignada por el sistema
En la tabla siguiente se resumen las características clave de una identidad administrada asignada por el sistema en AKS:
| Cómo se crea | Comportamiento del ciclo de vida | Uso compartido de recursos | Casos de uso comunes en AKS |
|---|---|---|---|
| Creado como parte de un recurso de Azure, como un clúster de AKS | Asociado al ciclo de vida del recurso primario, por lo que se elimina cuando se elimina el recurso primario. | Solo se puede asociar a un único recurso | • Cargas de trabajo contenidas en un único recurso de Azure • Cargas de trabajo que requieren identidades independientes |
Identidad administrada asignada por el usuario
En la tabla siguiente se resumen las características clave de una identidad administrada asignada por el usuario en AKS:
| Cómo se crea | Comportamiento del ciclo de vida | Uso compartido de recursos | Casos de uso comunes en AKS |
|---|---|---|---|
| Se crea como un recurso de Azure independiente y debe existir antes de la creación del clúster. | Independiente del ciclo de vida de cualquier recurso específico, por lo que requiere la eliminación manual si ya no es necesario. | Se puede compartir entre varios recursos | • Cargas de trabajo que se ejecutan en varios recursos y pueden compartir una sola identidad • Cargas de trabajo que requieren la autenticación previa a un recurso seguro como parte de un proceso de aprovisionamiento • Cargas de trabajo en las que los recursos se reciclan con frecuencia, pero necesitan permisos coherentes |
Identidad de kubelet administrada creada previamente
Una identidad administrada de kubelet creada previamente es una identidad opcional asignada por el usuario que kubelet puede usar para acceder a otros recursos de Azure. Esta característica habilita escenarios como la conexión a Azure Container Registry (ACR) durante la creación del clúster. Si no especifica una identidad administrada asignada por el usuario para kubelet, AKS crea una identidad kubelet asignada por el usuario en el grupo de recursos de nodo. Para una identidad de kubelet asignada por el usuario fuera del grupo de recursos predeterminado de los nodos de trabajo, asigne el rol Operador de identidad administrada a la identidad del plano de control del clúster, ya sea administrada por el sistema o asignada por el usuario, con el ámbito de la asignación de rol establecido en la identidad de kubelet.
Asignaciones de roles para identidades administradas en AKS
Puede asignar un rol RBAC de Azure a una identidad administrada para conceder permisos de clúster en otro recurso de Azure. Azure RBAC admite definiciones de roles integradas y personalizadas que especifican niveles de permisos. Para asignar un rol, consulte Pasos para asignar un rol de Azure.
Al asignar un rol RBAC de Azure a una identidad administrada, debe definir el ámbito del rol. En general, se recomienda limitar el ámbito de un rol a los privilegios mínimos requeridos por la identidad administrada. Para más información sobre el ámbito de los roles RBAC de Azure, consulte Descripción del ámbito de RBAC de Azure.
Asignaciones de roles de identidad administrada del plano de control
Al crear y usar su propia red virtual, discos de Azure conectados, dirección IP estática, tabla de rutas o identidad de kubelet asignada por el usuario donde los recursos están fuera del grupo de recursos del nodo de trabajo, la CLI de Azure agrega automáticamente la asignación de roles. Si usa una plantilla de ARM u otro método, use el ID principal de la identidad administrada para realizar una asignación de funciones.
Si no usas la CLI de Azure, pero usas tu propia red virtual (VNet), discos de Azure conectados, una dirección IP estática, una tabla de rutas o una identidad de kubelet asignada por el usuario, si esos recursos están fuera del grupo de recursos del nodo de trabajo, te recomendamos usar una identidad administrada asignada por el usuario para el plano de control y realizar manualmente la asignación de roles necesaria mediante el identificador de la entidad de seguridad de esa identidad.
Cuando el plano de control usa una identidad administrada asignada por el sistema, se crea la identidad al mismo tiempo que el clúster, por lo que no se puede realizar la asignación de roles hasta después de la creación del clúster. Después de crear el clúster, obtenga el identificador de entidad de seguridad de la identidad y agregue la asignación de roles necesaria.
Resumen de identidades administradas usadas por AKS
AKS usa varias identidades administradas para servicios y complementos integrados. En la tabla siguiente se resumen las identidades administradas que usa AKS, sus casos de uso, permisos predeterminados y si puede traer su propia identidad:
| identidad | Nombre | Caso de uso | Permisos predeterminados | Traiga su propia identidad |
|---|---|---|---|---|
| Plano de control | Nombre del clúster de AKS | Lo usan los componentes del plano de control de AKS para administrar los recursos del clúster, incluidos los balanceadores de carga de entrada, las direcciones IP públicas administradas por AKS, el autoscaler de clústeres, y los controladores CSI de Azure Disk, File y Blob. | Rol de colaborador para el grupo de recursos de nodo | Compatible |
| Kubelet | Nombre de clúster de AKS-agentpool | Autenticación con Azure Container Registry (ACR) | Ninguno; requiere el rol ACR Pull en función del modo de permiso del registro | Compatible |
| Complemento | AzureNPM | No se requiere ninguna identidad | N/A | Sin fundamento |
| Complemento | Supervisión de red de AzureCNI | No se requiere ninguna identidad | N/A | Sin fundamento |
| Complemento | azure-policy (gatekeeper) | No se requiere ninguna identidad | N/A | Sin fundamento |
| Complemento | Calicó | No se requiere ninguna identidad | N/A | Sin fundamento |
| Complemento | enrutamiento de aplicaciones (NGINX) | Administra los certificados de Azure DNS y Azure Key Vault. | rol Usuario de certificados de Key Vault para Key Vault, rol Colaborador de zona DNS para zonas DNS | Sin fundamento |
| Complemento | ingressapplicationgateway-nombre del clúster de AKS | Administra los recursos de red necesarios para el controlador de entrada de Application Gateway (AGIC) | Depende de la topología de implementación. | Sin fundamento |
| Complemento | Información sobre contenedores | Recopila los registros de contenedor y los datos de inventario y los envía a un área de trabajo de Log Analytics | Usa la identidad administrada del clúster; no se requiere el rol de Publicador de métricas de supervisión | Usa la identidad del clúster |
| Complemento | Virtual-Node (ACIConnector) | Administra los recursos de red necesarios para Azure Container Instances (ACI) | Rol de colaborador para el grupo de recursos de nodo | Sin fundamento |
| Complemento | cost-analysis-identity | Recopila identificadores de Azure Resource Manager para la asignación de costes | Acceso de lectura al grupo de recursos del nodo | Sin fundamento |
| Identidad de carga de trabajo | Identidad de Microsoft Entra configurada por el usuario | Permite que las aplicaciones accedan a los recursos en la nube de forma segura con el identificador de carga de trabajo de Microsoft Entra | Depende de los recursos a los que accede la carga de trabajo. | Obligatorio |
Nota:
La identidad de kubelet requiere un rol de extracción de ACR. Para los registros que estén en modo Permisos del registro RBAC, use el rol AcrPull. Para los registros en modo de permisos de repositorio RBAC Registry + ABAC Repository, use el rol Container Registry Repository Reader. Agregue el Container Registry Repository Catalog Lister rol solo si la identidad necesita enumerar repositorios. Para obtener más información, consulte Identidad asignada por el nodo de AKS.
La fila de enrutamiento de aplicaciones describe la experiencia basada en NGINX. Microsoft ofrece soporte para los parches de seguridad críticos de los recursos Ingress de NGINX del complemento de enrutamiento de aplicaciones hasta noviembre de 2026. Migre a la API de Application Routing Gateway u otra implementación admitida en noviembre de 2026. La integración de DNS y TLS de la API de Gateway usa Id. de carga de trabajo de Microsoft Entra en lugar de la identidad administrada del complemento. Para la API de puerta de enlace, cree una identidad administrada asignada por el usuario, concédale los roles de Azure DNS y Azure Key Vault necesarios y cree credenciales de identidad federada para las cuentas de servicio de Kubernetes.
Los permisos de AGIC dependen de cómo implemente Application Gateway. Cuando el complemento crea una nueva instancia de Application Gateway, normalmente asigna automáticamente los permisos necesarios. Si necesita asignar permisos manualmente, conceda a la identidad del complemento el rol Network Contributor en la subred de Application Gateway. Para una instancia existente de Application Gateway en un grupo de recursos distinto del clúster de AKS, conceda a la identidad del complemento los roles Network Contributor y Reader sobre el grupo de recursos de Application Gateway. Para obtener más información, consulte Habilitación de AGIC con una nueva instancia de Application Gateway y habilitación de AGIC con una instancia de Application Gateway existente.
Container Insights tiene como valor predeterminado la autenticación de identidad administrada y usa la identidad administrada del clúster para enviar datos a Azure Monitor. La autenticación heredada, que requería el rol Monitoring Metrics Publisher, dejará de admitirse el 30 de septiembre de 2026. Container Insights recopila registros y datos de inventario en un área de trabajo de Log Analytics; Azure Monitor servicio administrado para Prometheus recopila por separado las métricas de Prometheus en un área de trabajo de Azure Monitor. Para más información, consulte Autenticación de Container Insights.
AKS crea el cost-analysis-identity con acceso de lectura al grupo de recursos de los nodos y lo asigna a los grupos de nodos del clúster al habilitar el análisis de costes. No se puede especificar una identidad diferente para el complemento. Para más información, consulte Habilitación del análisis de costos de AKS.
Id. de carga de trabajo de Microsoft Entra es un modelo de identidad de pod para Azure, no una identidad administrada de clúster ni de complemento. Configure la identidad de Microsoft Entra que usa cada carga de trabajo, anote la cuenta de servicio de Kubernetes con el identificador de cliente de la identidad y cree una credencial de identidad federada. Para obtener más información, consulte Implementación y configuración de Id. de carga de trabajo de Microsoft Entra.
Paso siguiente
Habilite el tipo de identidad administrada deseado en un clúster de AKS nuevo o existente mediante las siguientes guías: