Partekatu honen bidez:

Preguntas más frecuentes sobre las identidades administradas para recursos de Azure

  • Artikulua

Identidades administradas para recursos de Azure es una característica de Microsoft Entra ID. Cada servicio de Azure compatible con Managed Identities for Azure Resources está sujeto a su propia escala de tiempo. Asegúrese de revisar el estado de disponibilidad de las identidades administradas para el recurso y los problemas conocidos antes de comenzar.

Nota:

Identidades administradas para recursos de Azure es el nombre con el que ahora se conoce al servicio Managed Service Identity (MSI).

Administración

¿Cómo se pueden encontrar los recursos que tienen una identidad administrada?

Puede encontrar la lista de recursos con una identidad administrada asignada por el sistema mediante el siguiente comando de la CLI de Azure:

az resource list --query "[?identity.type=='SystemAssigned'].{Name:name,  principalId:identity.principalId}" --output table

¿Qué permisos de Azure RBAC son necesarios para usar una identidad administrada en un recurso?

  • Identidad administrada asignada por el sistema: Debe tener permisos de escritura sobre el recurso. Por ejemplo, para las máquinas virtuales, necesita Microsoft.Compute/virtualMachines/write. Esta acción se incluye en los roles integrados específicos del recurso como, por ejemplo, Colaborador de máquina virtual.
  • Asignación de identidades administradas asignadas por el usuario a recursos: necesita permisos de escritura sobre el recurso. Por ejemplo, para las máquinas virtuales, necesita Microsoft.Compute/virtualMachines/write. También necesitará la acción Microsoft.ManagedIdentity/userAssignedIdentities/*/assign/action sobre la identidad asignada por el usuario. Esta acción se incluye en el rol integrado Operador de identidad administrada.
  • Administración de identidades asignadas por el usuario: para crear o eliminar entidades administradas asignadas por el usuario, necesita la asignación de roles Colaborador de identidad administrada.
  • Administración de asignaciones de roles para identidades administradas: necesita la asignación de roles Propietario o Administrador de acceso de usuario en el recurso al que va a conceder acceso. Necesitará la asignación de roles Lector para el recurso con una identidad asignada por el sistema, o a la identidad asignada por el usuario a la que se asigna el rol. Si no tiene acceso de lectura, puede buscar por "Usuario, grupo o entidad de servicio" para encontrar la entidad de servicio de respaldo de la identidad, en lugar de buscar por identidad administrada al agregar la asignación de roles. Más información sobre la asignación de roles de Azure.

¿Cómo evito la creación de identidades administradas asignadas por el usuario?

Puede impedir que los usuarios creen identidades administradas asignadas por el usuario mediante Azure Policy

  1. Inicie sesión en Azure Portal y vaya a Directiva.

  2. Elija Definiciones.

  3. Seleccione + Definición de directiva y escriba la información necesaria.

  4. En la sección de la regla de directiva, pegue lo siguiente:

    {
  "mode": "All",
  "policyRule": {
    "if": {
      "field": "type",
      "equals": "Microsoft.ManagedIdentity/userAssignedIdentities"
    },
    "then": {
      "effect": "deny"
    }
  },
  "parameters": {}
}

Después de crear la directiva, asígnela al grupo de recursos que quiere usar.

  1. Navegue a los grupos de recursos.
  2. Busque el grupo de recursos que usa para las pruebas.
  3. Elija Directivas en el menú izquierdo.
  4. Seleccione Asignar directiva.
  5. En la sección Datos básicos, proporcione:
    1. Ámbito: el grupo de recursos que se usa para las pruebas.
    2. Definición de directiva: La directiva que creamos anteriormente.
  6. Deje todas las demás opciones con sus valores predeterminados y elija Revisar y crear.

En este momento, se produce un error en cualquier intento de crear una identidad administrada asignada por el usuario en el grupo de recursos.

Captura de pantalla que muestra una infracción de directiva.

Conceptos

¿Las identidades administradas tienen un objeto de aplicación de respaldo?

No, las identidades administradas y los registros de aplicaciones de Microsoft Entra no son lo mismo en el directorio.

Los registros de aplicaciones tienen dos componentes: Un objeto de aplicación y un objeto de entidad de servicio. Las identidades administradas para los recursos de Azure solo tienen uno de estos componentes: un objeto de entidad de servicio.

Las identidades administradas no tienen un objeto de aplicación en el directorio, que es lo que se suele usar para conceder permisos de aplicación para MS Graph. En su lugar, los permisos de MS Graph para identidades administradas deben concederse directamente a la entidad de servicio.

¿Cuál es la credencial asociada a una identidad administrada? ¿Qué validez tiene y con qué frecuencia se rota?

Nota

La forma de autenticarse las identidades administradas es un dato de implementación interno que está sujeto a cambios sin previo aviso.

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.

¿A qué identidad se aplicará de forma predeterminada IMDS si no se especifica la identidad en la solicitud?

  • Si la identidad administrada asignada por el sistema está habilitada y no se especifica ninguna identidad en la solicitud, Azure Instance Metadata Service (IMDS) adopta como valor predeterminado la identidad administrada asignada por el sistema.
  • Si la identidad administrada asignada por el sistema no está habilitada, y solo existe una identidad administrada asignada por el usuario, IMDS será la identidad administrada asignada de manera predeterminada a ese único usuario.

    Si se asigna al recurso otra identidad administrada asignada por el usuario por cualquier motivo, las solicitudes a IMDS comenzarán a producir el error Multiple user assigned identities exist, please specify the clientId / resourceId of the identity in the token request. Se recomienda especificar explícitamente una identidad en la solicitud, incluso si actualmente solo existe una identidad administrada asignada por el usuario para el recurso.

  • Si la identidad administrada asignada por el sistema no está habilitada y existen varias identidades administradas asignadas por el usuario, es necesario especificar una identidad administrada en la solicitud.

Limitaciones

¿Se puede usar la misma identidad administrada en varias regiones?

En resumen, sí puede usar identidades administradas asignadas por el usuario en más de una región de Azure. La respuesta más larga es que, mientras que las identidades administradas asignadas por el usuario se crean como recursos regionales, la entidad de servicio asociada (SP) creada en Microsoft Entra ID está disponible globalmente. La entidad de servicio se puede usar desde cualquier región de Azure y su disponibilidad depende de la disponibilidad de Microsoft Entra ID. Por ejemplo, si ha creado una identidad administrada asignada por el usuario en la región Centro y Sur, y esa región deja de estar disponible, este problema solo afecta a las actividades del plano de control en la propia identidad administrada. Las actividades realizadas por los recursos ya configuradas para usar las identidades administradas no se verán afectadas.

¿Funcionan las identidades administradas para recursos de Azure con Azure Cloud Services (clásico)?

Las identidades administradas para los recursos de Azure no tienen compatibilidad con Azure Cloud Services (clásico) en este momento. “

¿Cuál es el límite de seguridad de las identidades administradas para recursos de Azure?

El límite de seguridad de la identidad es el recurso al que está asociada. Por ejemplo, el límite de seguridad para una máquina virtual que tenga las identidades administradas para recursos de Azure habilitadas, es la máquina virtual. Cualquier código que se ejecute en esa máquina virtual puede llamar a los tokens de punto de conexión y solicitud de las identidades administradas. La experiencia es similar cuando se trabaja con otros recursos que admiten identidades administradas.

¿Se van a volver a crear automáticamente las identidades administradas si muevo una suscripción a otro directorio?

No, si mueve una suscripción a otro directorio, tendrá que volver a crearlas manualmente y volver a conceder asignaciones de roles de Azure.

  • Para las identidades administradas asignadas por el sistema, tiene que desactivarlas y volver a activarlas.
  • Para las identidades administradas asignadas por el usuario, tiene que eliminarlas, volver a crearlas y adjuntarlas de nuevo a los recursos necesarios (por ejemplo, máquinas virtuales).

¿Puedo usar una identidad administrada para acceder a un recurso en un directorio o inquilino diferente?

No, las identidades administradas no admiten actualmente escenarios entre directorios.

¿Hay algún límite de frecuencia que se aplique a las identidades administradas?

Los límites de identidades administradas tienen dependencias de los límites de servicio de Azure, los de Azure Instance Metadata Service (IMDS) y los de Microsoft Entra.

  • Los límites de servicio de Azure definen el número de operaciones de creación que se pueden realizar en los niveles de inquilino y suscripción. Las identidades administradas asignadas por el usuario también tienen limitaciones en cuanto a cómo se les puede asignar un nombre.
  • IMDS En general, las solicitudes a IMDS se limitan a cinco por segundo. Las solicitudes que superen este umbral se rechazarán con respuestas 429. Las solicitudes a la categoría Identidad administrada se limitan a 20 por segundo y cinco solicitudes simultáneas. Puede leer más en el artículo Azure Instance Metadata Service (Windows).
  • Servicio Microsoft Entra Cada identidad administrada cuenta para el límite de cuota de objetos de un inquilino de Microsoft Entra, tal y como se describe en Límites y restricciones del servicio Microsoft Entra.

¿Se puede trasladar una identidad administrada asignada por el usuario a otro grupo de recursos o suscripción?

No se admite el movimiento de una identidad administrada asignada por el usuario a otro grupo de recursos.

¿Los tokens de identidades administradas se almacenan en caché?

Los tokens de identidad administrada se almacenan en caché mediante la infraestructura de Azure para aumentar el rendimiento y la resistencia: los servicios back-end para identidades administradas mantienen una caché por URI de recurso durante unas 24 horas. Los cambios en los permisos de una identidad administrada pueden tardar varias horas en aplicarse, por ejemplo. En la actualidad, no es posible forzar la actualización del token de una identidad administrada antes de su expiración. Para más información, consulte Limitación del uso de identidades administradas para la autorización.

¿Se eliminan temporalmente las identidades administradas?

Sí, las identidades administradas se eliminan temporalmente durante 30 días. Puede ver la entidad de servicio de identidad administrada eliminada temporalmente, pero no puede restaurarla ni eliminarla de forma permanente.

¿Qué ocurre con los tokens después de eliminar una identidad administrada?

Cuando se elimina una identidad administrada, un recurso de Azure que estaba asociado anteriormente a esa identidad ya no puede solicitar nuevos tokens para esa identidad. Los tokens emitidos antes de que se eliminara la identidad seguirán siendo válidos hasta su expiración original. Algunos sistemas de autorización de los puntos de conexión de destino pueden llevar a cabo otras comprobaciones en el directorio de la identidad, en cuyo caso se produce un error en la solicitud, ya que no se encuentra el objeto. Aun así, algunos sistemas, como RBAC de Azure, seguirán aceptando solicitudes de ese token hasta que expire.

Pasos siguientes