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

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 utiliza aad-pod-identity. La CRD de AzurePodIdentityException se puede configurar para informar a aad-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 etiqueta kubernetes.azure.com/managedby: aks del espacio de nombres kubernetes.azure.com/managedby: aks deben excluirse en aad-pod-identity mediante la configuración de la CRD de AzurePodIdentityException.
  • 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.

  1. Cree un grupo de recursos de Azure con el comando az group create.

    az group create --name myResourceGroup --location westus2
    
  2. Cree un clúster de AKS con el comando az aks create.

    az aks create -g myResourceGroup -n myManagedCluster --enable-managed-identity
    
  3. 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 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.

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 comando az 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 comando az 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 argumento assign-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

  1. 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"
    }
    
  2. 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

  1. 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"
    }
    
  2. 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 argumento assign-identity y la identidad administrada de kubelet con el argumento assign-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.