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 de Microsoft Entra. Las identidades administradas para recursos de Azure son la manera recomendada de autorizar el acceso desde un clúster de AKS a otros servicios de Azure.

Puedes usar una identidad administrada para autorizar el acceso desde un clúster de AKS a cualquier servicio que admita la autorización de Microsoft Entra, sin necesidad de administrar las credenciales ni incluirlas en el código. Asigna a la identidad administrada un rol de control de acceso basado en rol (RBAC) de Azure para concederle permisos a un recurso determinado en Azure. Por ejemplo, puedes conceder permisos a una identidad administrada a fin de acceder a secretos en un almacén de claves de Azure para que lo use el clúster. Para más información acerca de Azure RBAC, consulte ¿Qué es el control de acceso basado en rol de Azure (Azure RBAC)?

En este artículo se muestra cómo habilitar los siguientes tipos de identidad administrada en un clúster de AKS nuevo o existente:

• Identidad administrada asignada por el sistema. Una identidad administrada asignada por el sistema se asocia con un único recurso de Azure, tal como un clúster de AKS. Solo existe durante el ciclo de vida del clúster.
• Identidad administrada asignada por el usuario. Una identidad administrada asignada por el usuario es un recurso de Azure independiente que un clúster de AKS puede usar para autorizar el acceso a otros servicios de Azure. Se conserva independientemente del clúster de AKS y se puede usar en varios recursos de Azure.
• Identidad administrada de kubelet 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. AKS crea una identidad de kubelet asignada por el sistema en el grupo de recursos de nodo si no especificas tu propia identidad administrada por kubelet.

Para más información sobre las identidades administradas, consulta Identidades administradas para recursos de Azure.

Información general

Un clúster de AKS usa una identidad administrada para solicitar tokens de Microsoft Entra. Estos tokens se usan para autorizar el acceso a otros recursos que se ejecutan en Azure. Puedes asignar un rol RBAC de Azure a una identidad administrada para conceder permisos de clúster a fin de acceder a recursos específicos. Por ejemplo, si el clúster necesita acceder a secretos en un almacén de claves de Azure, puedes asignar a la identidad administrada del clúster un rol de RBAC de Azure que conceda esos permisos.

Una identidad administrada puede ser asignada por el sistema o asignada por el usuario. Estos dos tipos de identidades administradas se parecen en que puedes usar cualquier tipo para autorizar el acceso a los recursos de Azure desde el clúster de AKS. La diferencia clave entre estos es que una identidad administrada asignada por el sistema está asociada a un único recurso de Azure, como un clúster de AKS, mientras que una identidad administrada asignada por el usuario es un recurso de Azure independiente. Para más información sobre las diferencias entre los tipos de identidades administradas, consulta Tipos de identidad administrada en Identidades administradas para recursos de Azure.

La plataforma Azure administra ambos tipos de identidades administradas, de modo que puedas autorizar el acceso desde las aplicaciones sin necesidad de aprovisionar ni girar ningún secreto. Azure administra automáticamente las credenciales de la identidad.

De manera predeterminada y automática, cuando implementas un clúster de AKS, se crea también una identidad administrada asignada por el sistema. También puedes crear el clúster con una identidad administrada asignada por el usuario.

También es posible crear un clúster con una entidad de servicio de aplicación en lugar de una identidad administrada. Las identidades administradas se recomiendan en lugar de entidades de servicio para mayor seguridad y facilidad de uso. Para más información sobre cómo crear un clúster con una entidad de servicio, consulta Uso de una entidad de servicio con Azure Kubernetes Service (AKS).

Puedes actualizar un clúster existente para usar una identidad administrada desde una entidad de servicio de aplicación. También puedes actualizar un clúster existente a otro tipo de identidad administrada. Si el clúster ya usa una identidad administrada y se cambió la identidad, por ejemplo, si has actualizado el tipo de identidad del clúster 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 su token. Una vez actualizado el token, cambian a la nueva identidad. Este proceso puede tardar varias horas.

Los tipos de identidad asignada por el sistema y asignada por el usuario varían de 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.

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 actualizar un clúster existente a fin de usar una identidad administrada asignada por el sistema o una identidad administrada asignada por el usuario, necesitas la versión 2.49.0 o posterior de la CLI de Azure instalada.

Para poder ejecutar los ejemplos de este artículo, establece la suscripción como la suscripción activa actual llamando al comando az account set y pasando el id. de suscripción.

az account set --subscription <subscription-id>

Si aún no tienes uno, crea también un grupo de recursos de Azure mediante el comando az group create.

az group create \
    --name myResourceGroup \
    --location westus2

Habilitación de una identidad administrada asignada por el sistema.

Una identidad administrada asignada por el sistema es una identidad asociada a un clúster de AKS u otro recurso de Azure. La identidad administrada asignada por el sistema está vinculada al ciclo de vida del clúster. Cuando se elimina el clúster, también se elimina la identidad administrada asignada por el sistema.

El clúster de AKS puede usar la identidad administrada asignada por el sistema para autorizar el acceso a otros recursos que se ejecutan en Azure. Puede asignar un rol RBAC de Azure a la identidad administrada asignada por el sistema para conceder a los clústeres permisos a fin de acceder a recursos específicos. Por ejemplo, si el clúster necesita acceder a secretos en un almacén de claves de Azure, puedes asignar a la identidad administrada asignada por el sistema un rol RBAC de Azure que conceda esos permisos.

Habilitación de una identidad administrada asignada por el sistema en un clúster nuevo de AKS

Para habilitar una identidad administrada asignada por el sistema en un nuevo clúster, llame a az aks create. Una identidad administrada asignada por el sistema está habilitada en el nuevo clúster de manera predeterminada.

Cree un clúster de AKS con el comando az aks create.

az aks create \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --generate-ssh-keys

A fin de comprobar que una identidad administrada asignada por el sistema está habilitada para el clúster una vez creada, consulta Determinación de qué tipo de identidad administrada usa un clúster.

Actualización de un clúster de AKS existente para usar una identidad administrada asignada por el sistema

Para actualizar un clúster de AKS existente que usa una entidad de servicio a fin de usar una identidad administrada asignada por el sistema en su lugar, ejecuta el comando az aks update con el parámetro --enable-managed-identity.

az aks update \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --enable-managed-identity

Después de actualizar el clúster a fin de usar una identidad administrada asignada por el sistema en lugar de una entidad de servicio, el plano de control y los pods usan la identidad administrada asignada por el sistema para la autorización al acceder a otros servicios en Azure. Kubelet continúa usando una entidad de servicio hasta que actualices también 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 y 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 (ACR), deberás 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 a fin de extraer datos desde ACR. De lo contrario, no podrá extraer datos desde ACR después de la actualización.

Incorporación de una asignación de roles para una identidad administrada asignada por el sistema

Puedes asignar un rol RBAC de Azure a la identidad administrada asignada por el sistema para conceder los permisos de clúster en otro recurso de Azure. Azure RBAC admite definiciones de roles integradas y personalizadas que especifican niveles de permisos. Para más información sobre la asignación de roles RBAC de Azure, consulta Pasos para asignar un rol de Azure.

Al asignar un rol RBAC de Azure a una identidad administrada, debes definir el ámbito del rol. En general, se recomienda limitar el ámbito de un rol a los privilegios mínimos que requiere la identidad administrada. Para más información sobre el ámbito de los roles RBAC de Azure, consulta Descripción del ámbito de RBAC de Azure.

Cuando crees y uses tu propia red virtual, discos de Azure conectados, 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 agrega la asignación de roles automáticamente. Si usas una plantilla de ARM u otro método, usa el id. de entidad de seguridad de la identidad administrada para realizar una asignación de roles.

Si en lugar de la CLI de Azure usas tu propia red virtual, discos de Azure conectados, 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. Cuando el plano de control usa una identidad administrada asignada por el sistema, la identidad se crea al mismo tiempo que el clúster, por lo que la asignación de roles no se puede realizar hasta que se haya creado el clúster.

Obtención del id. de entidad de seguridad de la identidad administrada asignada por el sistema

Para asignar un rol RBAC de Azure a la identidad administrada asignada por el sistema de un clúster, primero necesitas el id. de entidad de seguridad para la identidad administrada. Obtenga el id. de entidad de seguridad de la identidad administrada asignada por el sistema del clúster llamando al comando az aks show.

# Get the principal ID for a system-assigned managed identity.
CLIENT_ID=$(az aks show \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --query identity.principalId \
    --output tsv)

Asignación de un rol RBAC de Azure a la identidad administrada asignada por el sistema

Para conceder permisos de identidad administrada asignadas por el sistema a un recurso de Azure, llama al comando az role assignment create a fin de asignar un rol RBAC de Azure a la identidad administrada.

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 Network Contributor al grupo de recursos personalizado que esté usando.

Por ejemplo, asigna el rol Network Contributor en el grupo de recursos personalizado mediante el comando az role assignment create. En el parámetro --scope, proporciona el id. de recurso para el grupo de recursos del clúster.

az role assignment create \
    --assignee $CLIENT_ID \
    --role "Network Contributor" \
    --scope "<resource-group-id>"

Nota:

Los permisos concedidos a la identidad administrada del clúster pueden tardar hasta 60 minutos en propagarse.

Habilitación de una identidad administrada asignada por el usuario.

Se crea una identidad administrada asignada por el usuario como recurso de Azure independiente. Al crear un clúster con una identidad administrada asignada por el usuario para el plano de control, el recurso de identidad administrada asignada por el usuario debe existir antes de la creación del clúster. Esta característica permite escenarios como crear el clúster con una red virtual personalizada o con un tipo de salida de enrutamiento definido por el usuario (UDR).

Crear una identidad administrada asignada por el usuario

Si aún no tienes un recurso de identidad administrada asignada por el usuario, crea uno mediante el 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"
}

Obtención del id. de cliente de la identidad administrada asignada por el usuario

Para obtener el id. de entidad de seguridad de la identidad administrada asignada por el usuario, llama a az identity show y consulta la propiedad principalId:

CLIENT_ID=$(az identity show \
    --name myIdentity \
    --resource-group myResourceGroup \
    --query principalId \
    --output tsv)

Obtención del id. de recurso de la identidad administrada asignada por el usuario

Para crear un clúster con una identidad administrada asignada por el usuario, necesitarás el id. de recurso para la nueva identidad administrada. Para obtener el id. de recurso de la identidad administrada asignada por el usuario, llama a az aks show y consulta la propiedad id:

RESOURCE_ID=$(az identity show \
    --name myIdentity \
    --resource-group myResourceGroup \
    --query id \
    --output tsv)

Asignación de un rol RBAC de Azure a la identidad administrada asignada por el usuario

Antes de crear el clúster, agrega una asignación de roles para la identidad administrada llamando al comando az role assignment create.

En el ejemplo siguiente se asigna el rol Usuario de secretos de Key Vault a la identidad administrada asignada por el usuario para concederle permisos a fin de acceder a secretos en un almacén de claves. La asignación de roles se limita al recurso del almacén de claves:

az role assignment create \
    --assignee $CLIENT_ID \
    --role "Key Vault Secrets User" \
    --scope "<keyvault-resource-id>"

Nota:

Los permisos concedidos a la identidad administrada del clúster pueden tardar hasta 60 minutos en propagarse.

Creación de un clúster con la identidad administrada asignada por el usuario

Para crear un clúster de AKS con la identidad administrada asignada por el usuario, llama al comando az aks create. Incluye el parámetro --assign-identity y pasa el id. de recurso de la 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 \
    --assign-identity $RESOURCE_ID \
    --generate-ssh-keys

Nota:

Las regiones Centro de USDOD, Este de USDOD y USGov Iowa en la nube de Administración Pública de EE. UU. de Azure no admiten la creación de un clúster con una identidad administrada asignada por el usuario.

Actualización de un clúster existente para usar una identidad administrada asignada por el usuario

Para actualizar un clúster existente a fin de usar una identidad administrada asignada por el usuario, llama al comando az aks update. Incluye el parámetro --assign-identity y pasa el id. de recurso de la identidad administrada asignada por el usuario:

az aks update \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --enable-managed-identity \
    --assign-identity $RESOURCE_ID

La salida de una actualización correcta del clúster para usar una identidad administrada asignada por el usuario debe ser similar a la del ejemplo siguiente:

  "identity": {
    "principalId": null,
    "tenantId": null,
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity": {
        "clientId": "<client-id>",
        "principalId": "<principal-id>"
      }
    }
  },

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. Los componentes del plano de control continúan hasta varias horas con la identidad asignada por el sistema anterior hasta la siguiente actualización del token.

Determinación de qué tipo de identidad administrada usa un clúster

Para determinar qué tipo de identidad administrada usa el clúster de AKS existente, llama al comando az aks show y consulta la propiedad type de la identidad.

az aks show \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --query identity.type \
    --output tsv       

Si el clúster usa una identidad administrada, el valor de la propiedad type será SystemAssigned o UserAssigned.

Si el clúster está utilizando una entidad de servicio, el valor de la propiedad type será null. Considera la posibilidad de actualizar el clúster para usar una identidad administrada.

Uso de una identidad administrada de kubelet creada previamente

Una identidad kubelet creada previamente es una identidad administrada asignada por el usuario que existe antes de la creación del clúster. Esta característica habilita escenarios, como la conexión a Azure Container Registry (ACR), durante la creación del clúster.

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.

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.

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"
}

Asignación de un rol RBAC a la identidad administrada por kubelet

Asigne el rol ACRPull en la identidad de kubelet mediante el comando az role assignment create. Proporcione la identidad principal de la identidad del kubelet para la variable $KUBELET_CLIENT_ID y proporcione la identidad del registro de ACR para la variable $ACR_REGISTRY_ID.

az role assignment create \
    --assignee $KUBELET_CLIENT_ID \
    --role "acrpull" \
    --scope "$ACR_REGISTRY_ID"

Creación de un clúster para usar la identidad de kubelet

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 \
    --assign-identity <identity-resource-id> \
    --assign-kubelet-identity <kubelet-identity-resource-id> \
    --generate-ssh-keys

Una creación correcta de clústeres de AKS mediante una identidad administrada de kubelet debería generar 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 para usar la identidad de kubelet

Para actualizar un clúster existente a fin de usar la identidad administrada de kubelet, primero debes obtener la identidad administrada del plano de control actual para el clúster de AKS.

Advertencia

Al actualizar la identidad administrada de kubelet, se actualizan los grupos de nodos del clúster de AKS, lo que provoca tiempo de inactividad para el clúster a medida que los nodos de los grupos de nodos están acordonados o purgados y se vuelven a crear imágenes.

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 \
       --resource-group <RGName> \
       --name <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:

   # The cluster is using a managed identity.
   {
     "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 --resource-group <RGName> \
       --name <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>"
   },
   

3. Actualice un clúster de AKS con las identidades existentes mediante el comando az aks update. Proporciona el id. de recurso de la identidad administrada asignada por el usuario para el plano de control del argumento assign-identity. Proporciona el id. de recurso de la identidad administrada de kubelet para 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"
    }
  },

Nota:

Si el clúster usaba el parámetro --attach-acr para extraer datos desde la imagen de Azure Container Registry, ejecuta 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 a fin de extraer datos desde ACR. De lo contrario, no podrá extraer datos desde ACR después de la actualización.

Obtención de las propiedades de la identidad de kubelet

Para obtener las propiedades de la identidad de kubelet, llama a az aks show y consulta la propiedad identityProfile.kubeletidentity.

az aks show \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --query "identityProfile.kubeletidentity"

Limitaciones de identidad de kubelet creadas previamente

Ten en cuenta las siguientes limitaciones para la identidad de kubelet creada previamente:

• Una identidad de kubelet creada previamente debe ser una identidad administrada asignada por el usuario.
• Actualmente, no se admiten las regiones Este de China ni Norte de China en Microsoft Azure operado por 21Vianet.

Resumen de las identidades administradas que usa AKS

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

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 que revises Id. de carga de trabajo de Microsoft Entra. La autenticación de Id. de carga de trabajo de Entra reemplaza la característica de identidad administrada por pods en desuso (versión preliminar). Id. de carga de trabajo de Entra es el método recomendado para permitir que una aplicación que se ejecute en un pod se autentique en otros servicios de Azure que lo admitan.

Limitaciones

• No se admite el traslado o migración de un clúster habilitado para identidad administrada a otro inquilino.

• 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 significa que NMI intercepta cualquier solicitud realizada al punto de conexión IMDS, incluso si un pod determinado no usa aad-pod-identity.

  La definición de recursos personalizados (CRD) de AzurePodIdentityException se puede configurar para especificar que las solicitudes al punto de conexión de IMDS que se originan en etiquetas coincidentes de pod definidas en la CRD se deben procesar en proxy sin ningún procesamiento en NMI. Excluye los pods del sistema con la etiqueta kubernetes.azure.com/managedby: aks en el espacio de nombres kube-system en aad-pod-identity configurando la CRD de AzurePodIdentityException. Para obtener más información, consulta Uso de identidades administradas por pods de Microsoft Entra en Azure Kubernetes Service.

  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.

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 para todos los métodos de autenticación admitidos de Microsoft Entra en AKS.