Usar una identidad administrada en Azure Kubernetes Service (AKS)
Para acceder a los recursos de Azure ubicados en un clúster de Azure Kubernetes Service (AKS), como los equilibradores de carga y los discos administrados, es necesaria una identidad. Esta identidad puede ser una identidad administrada o una entidad de servicio.
En este artículo se proporcionan detalles sobre cómo habilitar los siguientes tipos de identidad administrada en un clúster de AKS nuevo o existente:
- Identidad administrada asignada por el sistema
- Traiga su propia identidad administrada asignada por el usuario
- Identidad administrada de Kubelet creada previamente
Información general
Al implementar un clúster de AKS, se crea automáticamente una identidad administrada asignada por el sistema y se administra mediante la plataforma de Azure, por lo que no es necesario aprovisionar ni rotar ningún secreto. Para más información, consulte Identidades administradas para los recursos de Azure.
AKS no crea automáticamente la entidad de servicio, por lo que debe crear una. Los clústeres que usan las entidades de servicio acaban expirando con el tiempo, por lo que la entidad de servicio debe renovarse para evitar afectar la autenticación del clúster con la identidad. La administración de entidades de servicio agrega complejidad, por lo que es más fácil usar identidades administradas. Se aplican los mismos requisitos de permisos tanto en las entidades de servicio como en las identidades administradas. Las identidades administradas usan la autenticación basada en certificados. Cada credencial de identidad administrada expira al cabo de 90 días y se revierte después de 45 días.
AKS usa tipos de identidad administrada asignados tanto por el sistema como por el usuario; estas identidades son inmutables. Estos tipos de identidad no deben confundirse con una identidad de carga de trabajo de Microsoft Entra, destinada a su uso por parte de una aplicación que se ejecuta en un pod.
Importante
El código abierto Identidad administrada por pod de Microsoft Entra (versión preliminar) en Azure Kubernetes Service ha quedado en desuso el 24/10/2022 y el proyecto archivado en septiembre de 2023. Para obtener más información, consulte el aviso de desuso. El complemento administrado por AKS comienza a quedar en desuso en septiembre de 2024.
Se recomienda revisar primero la introducción al Identificador de carga de trabajo de Microsoft Entra. La autenticación del id. de carga de trabajo de Entra reemplaza a la identidad administrada por pods de Microsoft Entra (versión preliminar) y es el método recomendado para permitir que una aplicación que se ejecuta en un pod se autentique en otros servicios de Azure que la admitan.
Antes de empezar
Asegúrese de haber instalado la CLI de Azure versión 2.23.0. Ejecute
az --version
para encontrar la versión. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.Para usar una identidad administrada kubelet creada previamente, necesita la versión 2.26.0 de la CLI de Azure o posterior instalada.
Para la identidad del plano de control de actualización en un clúster existente, necesita la versión 2.49.0 de la CLI de Azure o posterior instalada.
Limitaciones
- No se admite que los inquilinos trasladen o migren los clústeres habilitados para identidades administradas.
- Si el clúster tiene habilitada la identidad administrada por pods de Microsoft Entra (
aad-pod-identity
), los pods de Identidad administrada del nodo (NMI) modifican las tablas de IP de los nodos para interceptar las llamadas que se realizan en el punto de conexión de Azure Instance Metadata (IMDS). Esta configuración hace que la NMI intercepte toda solicitud realizada al punto de conexión de Metadata, incluso si el pod no utilizaaad-pod-identity
. La CRD de AzurePodIdentityException se puede configurar para informar aaad-pod-identity
de que las solicitudes dirigidas al punto de conexión de Metadata que se originen en un pod que coincida con las etiquetas definidas en la CRD deban pasar por el servidor proxy sin que se procesen en NMI. Los pods del sistema que tienen la etiquetakubernetes.azure.com/managedby: aks
del espacio de nombreskubernetes.azure.com/managedby: aks
deben excluirse enaad-pod-identity
mediante la configuración de la CRD de AzurePodIdentityException.- Para más información, consulte Deshabilitación de la identidad del pod de Microsoft Entra ID para un pod o una aplicación específicos.
- Para configurar una excepción, instale mic-exception.YAML.
- AKS no admite el uso de una identidad administrada asignada por el sistema cuando se usa una zona DNS privada personalizada.
Resumen de identidades administradas
AKS usa varias identidades administradas 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 | La usan los componentes del plano de control de AKS para administrar los recursos del clúster, incluidos los equilibradores de carga de entrada y las IP públicas administradas de AKS, el escalador automático de clústeres y los controladores CSI de disco, blob y archivo de Azure. | Rol de colaborador para un grupo de recursos de nodo | Compatible |
Kubelet | Nombre de clúster de AKS-agentpool | Autenticación con Azure Container Registry (ACR). | N/D (para kubernetes 1.15 y versiones posteriores) | Compatible |
Complemento | AzureNPM | No se requiere ninguna identidad. | N/D | No |
Complemento | Supervisión de red AzureCNI | No se requiere ninguna identidad. | N/D | No |
Complemento | azure-policy (gatekeeper) | No se requiere ninguna identidad. | N/D | No |
Complemento | azure-policy | No se requiere ninguna identidad. | N/D | No |
Complemento | Calico | No se requiere ninguna identidad. | N/D | No |
Complemento | Panel | No se requiere ninguna identidad. | N/D | No |
Complemento | application-routing | Administra los certificados de Azure DNS y de Azure Key Vault. | Rol de usuario de secretos de Key Vault para Key Vault, rol de colaborador de zona DNS para zonas DNS, rol de colaborador de zona DNS privada para zonas DNS privadas | No |
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 | Se usa para enviar las 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 (ACI). | Rol de colaborador para grupo de recursos de nodo | No |
Complemento | Análisis de costos | Se usa para recopilar datos de asignación de costos | ||
Identidad de la carga de trabajo | Id. de carga de trabajo de Microsoft Entra | Permite que las aplicaciones accedan de manera segura a los recursos en la nube mediante el id. de carga de trabajo de Microsoft Entra. | N/D | No |
Habilitación de identidades administradas en un nuevo clúster de AKS
Nota:
AKS crea una identidad kubelet asignada por el usuario en el grupo de recursos de nodo si usted no especifica su propia identidad administrada por kubelet.
Nota:
Si el clúster ya usa la identidad administrada y se cambió la identidad, por ejemplo, actualiza el tipo de identidad del clúster de asignado por el sistema a asignado por el usuario, hay un retraso para que los componentes del plano de control cambien a la nueva identidad. Los componentes del plano de control siguen usando la identidad antigua hasta que expire su token. Una vez actualizado el token, cambian a la nueva identidad. Este proceso puede tardar varias horas.
Cree un grupo de recursos de Azure con el comando
az group create
.az group create --name myResourceGroup --location westus2
Cree un clúster de AKS con el comando
az aks create
.az aks create -g myResourceGroup -n myManagedCluster --enable-managed-identity
Obtenga las credenciales para acceder al clúster usando el comando
az aks get-credentials
.az aks get-credentials --resource-group myResourceGroup --name myManagedCluster
Habilitación de identidades administradas en un clúster de AKS existente
Para actualizar un clúster de AKS existente que utiliza una entidad de servicio para emplear una identidad administrada asignada por el sistema, ejecute el comando az aks update
.
az aks update -g myResourceGroup -n myManagedCluster --enable-managed-identity
Después de actualizar el clúster, el plano de control y los pods usan la identidad administrada. Kubelet continúa usando una entidad de servicio hasta que actualice el grupo de agentes. Puede usar el comando az aks nodepool upgrade --resource-group myResourceGroup --cluster-name myAKSCluster --name mynodepool --node-image-only
en los nodos para actualizar a una identidad administrada. Una actualización del grupo de nodos provoca un tiempo de inactividad para el clúster de AKS, ya que los nodos de los grupos de nodos se acordonan o purgan y se restablece la imagen inicial.
Nota
Tenga en cuenta la siguiente información al actualizar el clúster:
Una actualización solo funciona si hay una actualización de VHD para consumir. Si ya ejecuta el VHD más reciente, deberá esperar hasta que la siguiente actualización del VHD esté disponible.
La CLI de Azure garantiza que el permiso del complemento se establezca correctamente después de la migración. Si no está usando la CLI de Azure para realizar la operación de migración, necesitará manejar el permiso de identidad del complemento por su cuenta. Para ver un ejemplo con una plantilla de Azure Resource Manager (ARM), consulte Asignación de roles de Azure mediante plantillas de ARM.
Si el clúster usaba el parámetro
--attach-acr
para extraer datos desde la imagen de Azure Container Registry, deberá volver a ejecutar el comandoaz aks update --resource-group myResourceGroup --name myAKSCluster --attach-acr <ACR resource ID>
después de actualizar el clúster para permitir que el kubelet recién creado que se usa con la identidad administrada obtenga el permiso para extraer datos desde ACR. De lo contrario, no podrá extraer datos desde ACR después de la actualización.
Incorporación de la asignación de roles para la identidad administrada
Cuando cree y use su propia red virtual, disco de Azure conectado, dirección IP estática, tabla de enrutamiento o identidad kubelet asignada por el usuario cuyos recursos existen fuera del grupo de recursos del nodo de trabajo, la CLI de Azure agregará la asignación de roles automáticamente. Si usa una plantilla de ARM o un método diferente, deberá usar el id. principal de la identidad administrada del clúster para realizar una asignación de roles.
Si en lugar de la CLI de Azure usa su propia red virtual, disco de Azure conectado, dirección IP estática, tabla de enrutamiento o identidad kubelet asignada por el usuario cuyos recursos existen fuera del grupo de recursos del nodo de trabajo, es recomendable usar una identidad administrada asignada por el usuario para el plano de control. En el caso del plano de control para usar una identidad administrada asignada por el sistema, no podemos obtener el id. de la identidad antes de crear el clúster, ya que esto retrasaría la aplicación de la asignación de roles.
Obtener el identificador de entidad de seguridad de la identidad administrada
Obtenga el id. de entidad de seguridad de la identidad existente mediante el comando
az identity show
.az identity show --ids <identity-resource-id>
La salida debería ser similar a la salida de ejemplo siguiente:
{ "clientId": "<client-id>", "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", "location": "eastus", "name": "myIdentity", "principalId": "<principal-id>", "resourceGroup": "myResourceGroup", "tags": {}, "tenantId": "<tenant-id>", "type": "Microsoft.ManagedIdentity/userAssignedIdentities" }
Agregar asignación de roles
Si usa una red virtual, un disco de Azure conectado, una dirección IP estática o una tabla de enrutamiento que existen fuera del grupo de recursos del nodo de trabajo predeterminado, deberá asignar el rol Contributor
al grupo de recursos personalizado que esté usando.
Asigne el rol
Contributor
en el grupo de recursos personalizado mediante el comandoaz role assignment create
.az role assignment create --assignee <control-plane-identity-principal-id> --role "Contributor" --scope "<custom-resource-group-resource-id>"
Si utiliza una identidad de kubelet asignada por el usuario que existe fuera del grupo de recursos del nodo de trabajo predeterminado, deberá asignar el rol Operador de identidad administrada a la identidad de kubelet para la identidad administrada del plano de control.
Asigne el rol
Managed Identity Operator
en la identidad de kubelet mediante el comandoaz role assignment create
.az role assignment create --assignee <control-plane-identity-principal-id> --role "Managed Identity Operator" --scope "<kubelet-identity-resource-id>"
Nota:
Los permisos concedidos a la identidad administrada del clúster pueden tardar hasta 60 minutos en rellenarse.
Traer su propia identidad administrada
Crear un clúster que use una identidad administrada asignada por el usuario
El uso de una identidad administrada asignada por el usuario para el plano de control le permitirá conceder acceso a una identidad existente antes de la creación de un clúster. Esta característica permite escenarios como el uso de una red virtual personalizada o outboundType de UDR con una identidad administrada previamente creada.
Nota:
Actualmente, no se admiten las regiones USDoD centro, USDoD este y USGov Iowa en la nube de Azure US Government.
AKS crea una identidad kubelet asignada por el usuario en el grupo de recursos de nodo si usted no especifica su propia identidad administrada por kubelet.
Si aún no tiene ninguna identidad administrada, cree una mediante la ejecución del comando
az identity create
.az identity create --name myIdentity --resource-group myResourceGroup
La salida debería ser similar a la salida de ejemplo siguiente:
{ "clientId": "<client-id>", "clientSecretUrl": "<clientSecretUrl>", "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", "location": "westus2", "name": "myIdentity", "principalId": "<principal-id>", "resourceGroup": "myResourceGroup", "tags": {}, "tenantId": "<tenant-id>", "type": "Microsoft.ManagedIdentity/userAssignedIdentities" }
Nota:
Los permisos concedidos a la identidad administrada del clúster pueden tardar hasta 60 minutos en rellenarse.
Antes de crear el clúster, agregue la asignación de roles para la identidad administrada con el comando
az role assignment create
.Crear un clúster con una identidad administrada asignada por el usuario.
az aks create \ --resource-group myResourceGroup \ --name myManagedCluster \ --network-plugin azure \ --vnet-subnet-id <subnet-id> \ --dns-service-ip 10.2.0.10 \ --service-cidr 10.2.0.0/24 \ --enable-managed-identity \ --assign-identity <identity-resource-id>
Deshabilitar la identidad administrada en un clúster existente
Nota:
Migrar la identidad administrada para el plano de control de "asignada por el sistema" a "asignada por el usuario" no provoca ningún tiempo de inactividad para el plano de control ni los grupos de agentes. Mientras tanto, los componentes del plano de control siguen usando la identidad asignada por el sistema antigua durante varias horas hasta la siguiente actualización del token.
Si aún no tiene ninguna identidad administrada, cree una mediante la ejecución del comando
az identity create
.az identity create --name myIdentity --resource-group myResourceGroup
La salida debería ser similar a la salida de ejemplo siguiente:
{ "clientId": "<client-id>", "clientSecretUrl": "<clientSecretUrl>", "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", "location": "westus2", "name": "myIdentity", "principalId": "<principal-id>", "resourceGroup": "myResourceGroup", "tags": {}, "tenantId": "<tenant-id>", "type": "Microsoft.ManagedIdentity/userAssignedIdentities" }
Después de crear la identidad administrada asignada por el usuario personalizada para el plano de control, agregue la asignación de roles para la identidad administrada con el comando
az role assignment create
.Actualice un clúster de AKS con las identidades existentes mediante el comando
az aks update
. Asegúrese de proporcionar el identificador de recurso de la identidad administrada para el plano de control mediante la inclusión del argumentoassign-identity
.az aks update \ --resource-group myResourceGroup \ --name myManagedCluster \ --enable-managed-identity \ --assign-identity <identity-resource-id>
La salida de una actualización correcta del clúster con su propia identidad administrada de kubelet debe ser similar a la siguiente salida de ejemplo:
"identity": { "principalId": null, "tenantId": null, "type": "UserAssigned", "userAssignedIdentities": { "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity": { "clientId": "<client-id>", "principalId": "<principal-id>" } } },
Uso de una identidad administrada de kubelet creada previamente
El uso de una identidad de kubelet le permitirá conceder acceso a una identidad existente antes de la creación de un clúster. Esta característica permite escenarios como la conexión a ACR con una identidad administrada creada previamente.
Limitaciones de identidad de kubelet creadas previamente
- Este proceso solo funciona con un clúster administrado asignado por el usuario.
- Actualmente, no se admiten las regiones Este de China ni Norte de China en Microsoft Azure operado por 21Vianet.
Cree identidades administradas asignadas por el usuario
Identidad administrada del plano de control
Si aún no tiene ninguna identidad administrada para el plano de control, cree una mediante la ejecución del comando
az identity create
.az identity create --name myIdentity --resource-group myResourceGroup
La salida debería ser similar a la salida de ejemplo siguiente:
{ "clientId": "<client-id>", "clientSecretUrl": "<clientSecretUrl>", "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", "location": "westus2", "name": "myIdentity", "principalId": "<principal-id>", "resourceGroup": "myResourceGroup", "tags": {}, "tenantId": "<tenant-id>", "type": "Microsoft.ManagedIdentity/userAssignedIdentities" }
Identidad administrada de kubelet
Si aún no tiene ninguna identidad administrada de kubelet, cree una mediante el comando
az identity create
.az identity create --name myKubeletIdentity --resource-group myResourceGroup
La salida debería ser similar a la salida de ejemplo siguiente:
{ "clientId": "<client-id>", "clientSecretUrl": "<clientSecretUrl>", "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity", "location": "westus2", "name": "myKubeletIdentity", "principalId": "<principal-id>", "resourceGroup": "myResourceGroup", "tags": {}, "tenantId": "<tenant-id>", "type": "Microsoft.ManagedIdentity/userAssignedIdentities" }
Creación de un clúster que use una identidad de kubelet asignada por el usuario
Ahora puede crear el clúster de AKS con sus identidades existentes. Asegúrese de proporcionar el identificador de recurso de la identidad administrada para el plano de control mediante la inclusión del argumento assign-identity
y la identidad administrada de kubelet mediante el argumento assign-kubelet-identity
.
Cree un clúster de AKS con las identidades existentes mediante el comando
az aks create
.az aks create \ --resource-group myResourceGroup \ --name myManagedCluster \ --network-plugin azure \ --vnet-subnet-id <subnet-id> \ --dns-service-ip 10.2.0.10 \ --service-cidr 10.2.0.0/24 \ --enable-managed-identity \ --assign-identity <identity-resource-id> \ --assign-kubelet-identity <kubelet-identity-resource-id>
La creación correcta del clúster de AKS mediante su propia identidad administrada de kubelet le mostrará una salida similar a la siguiente:
"identity": { "principalId": null, "tenantId": null, "type": "UserAssigned", "userAssignedIdentities": { "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity": { "clientId": "<client-id>", "principalId": "<principal-id>" } } }, "identityProfile": { "kubeletidentity": { "clientId": "<client-id>", "objectId": "<object-id>", "resourceId": "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity" } },
Actualización de un clúster existente mediante la identidad de kubelet
Advertencia
Al actualizar la identidad administrada de kubelet, se actualizan los grupos de nodos, lo que provoca un tiempo de inactividad para el clúster de AKS, ya que los nodos de los grupos de nodos se acordonan o purgan y se vuelven a crear imágenes.
Nota:
Si el clúster usaba el parámetro --attach-acr
para extraer datos desde la imagen de Azure Container Registry, deberá volver a ejecutar el comando az aks update --resource-group myResourceGroup --name myAKSCluster --attach-acr <ACR Resource ID>
después de actualizar el clúster para permitir que el kubelet recién creado que se usa con la identidad administrada obtenga el permiso para extraer datos desde ACR. De lo contrario, no podrá extraer datos desde ACR después de la actualización.
Obtener la identidad administrada del plano de control actual para el clúster de AKS
Ejecute el comando
az aks show
para confirmar que el clúster de AKS usa la identidad administrada asignada por el usuario.az aks show -g <RGName> -n <ClusterName> --query "servicePrincipalProfile"
Si el clúster utiliza una identidad administrada, la salida le mostrará el elemento
clientId
con el valor msi. Un clúster que usa una entidad de servicio le mostrará un id. de objeto. Por ejemplo:{ "clientId": "msi" }
Después de comprobar que el clúster usa identidades administradas, podrá encontrar el id. de recurso de la identidad administrada si ejecuta el comando
az aks show
.az aks show -g <RGName> -n <ClusterName> --query "identity"
Para una identidad administrada asignada por el usuario, la salida debe ser similar a la siguiente salida de ejemplo:
{ "principalId": null, "tenantId": null, "type": "UserAssigned", "userAssignedIdentities": <identity-resource-id> "clientId": "<client-id>", "principalId": "<principal-id>" },
Actualización del clúster con la identidad de kubelet
Si aún no tiene ninguna identidad administrada de kubelet, cree una mediante el comando
az identity create
.az identity create --name myKubeletIdentity --resource-group myResourceGroup
La salida debería ser similar a la salida de ejemplo siguiente:
{ "clientId": "<client-id>", "clientSecretUrl": "<clientSecretUrl>", "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity", "location": "westus2", "name": "myKubeletIdentity", "principalId": "<principal-id>", "resourceGroup": "myResourceGroup", "tags": {}, "tenantId": "<tenant-id>", "type": "Microsoft.ManagedIdentity/userAssignedIdentities" }
Actualice un clúster de AKS con las identidades existentes mediante el comando
az aks update
. Asegúrese de proporcionar el identificador de recurso de la identidad administrada para el plano de control con el argumentoassign-identity
y la identidad administrada de kubelet con el argumentoassign-kubelet-identity
.az aks update \ --resource-group myResourceGroup \ --name myManagedCluster \ --enable-managed-identity \ --assign-identity <identity-resource-id> \ --assign-kubelet-identity <kubelet-identity-resource-id>
La salida de una actualización correcta del clúster con su propia identidad administrada de kubelet debe ser similar a la siguiente salida de ejemplo:
"identity": { "principalId": null, "tenantId": null, "type": "UserAssigned", "userAssignedIdentities": { "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity": { "clientId": "<client-id>", "principalId": "<principal-id>" } } }, "identityProfile": { "kubeletidentity": { "clientId": "<client-id>", "objectId": "<object-id>", "resourceId": "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity" } },
Pasos siguientes
- Use las plantillas de Azure Resource Manager para crear un clúster habilitado para la identidad administrada.
- Obtenga información sobre cómo [usar kubelogin][kubelogin-authentication] para todos los métodos de autenticación admitidos de Microsoft Entra en AKS.