Una identidad administrada de Microsoft Entra ID permite que la aplicación contenedora acceda a otros recursos protegidos de Microsoft Entra. Para obtener más información sobre las identidades administradas en Microsoft Entra ID, consulte Identidades administradas para recursos de Azure.
La aplicación de contenedor puede tener dos tipos de identidades:
Una identidad asignada por el sistema está asociada a la aplicación de contenedor y esta se elimina si a su vez se elimina la aplicación. Una aplicación solo puede tener una identidad asignada por el sistema.
Una identidad asignada por el usuario es un recurso Azure independiente que puede asignar a la aplicación contenedora y a otros recursos. Una aplicación de contenedor puede tener varias identidades asignadas por el usuario. Las identidades asignadas por el usuario existen hasta que las elimine.
La aplicación se conecta a los recursos con la identidad administrada. No es necesario administrar las credenciales en la Container App.
Puede usar el control de acceso basado en roles para conceder permisos específicos a una identidad administrada.
Las identidades asignadas por el sistema se crean y administran automáticamente. Se eliminan cuando se elimina la Container App.
Puede agregar y eliminar identidades asignadas por el usuario y asignarlas a varios recursos. Son independientes del ciclo de vida de la aplicación de contenedor.
Las identidades asignadas por el sistema son las mejores para las cargas de trabajo que:
están contenidas en un solo recurso.
necesitan identidades independientes.
Las identidades asignadas por el usuario son ideales para cargas de trabajo que:
se ejecutan en varios recursos y pueden compartir una única identidad.
necesitan autorización previa para un recurso seguro.
Limitaciones
No se admiten identidades administradas en reglas de escalado. Debe incluir cadenas de conexión o claves en secretRef de la regla de escalado.
Los contenedores de inicialización no pueden acceder a identidades administradas.
Configuración de identidades administradas
Puede configurar las identidades administradas mediante:
Azure Portal
La CLI de Azure
la plantilla de Azure Resource Manager (ARM)
Cuando se agrega, elimina o modifica una identidad administrada en una Container App en ejecución, la aplicación no se reinicia automáticamente y no se crea una nueva revisión.
Nota:
Al agregar una identidad administrada a una aplicación de contenedor implementada antes del 11 de abril de 2022, debe crear una nueva revisión.
En la pestaña Asignado por el sistema, cambie Estado a Activado.
Seleccione Guardar.
Ejecute el comando az containerapp identity assign para crear una identidad asignada por el sistema:
az containerapp identity assign --name myApp --resource-group myResourceGroup --system-assigned
Se puede usar una plantilla de ARM para automatizar la implementación de la aplicación de contenedor y los recursos. Para agregar una identidad asignada por el sistema, agregue una sección identity a la plantilla de ARM.
"identity": {
"type": "SystemAssigned"
}
Al agregar el tipo asignado por el sistema se indica a Azure que debe crear y administrar la identidad para la aplicación. Para obtener un ejemplo completo de la plantilla de ARM, consulte Especificación de la API de ARM.
Algunos comandos de la CLI de Azure, incluidos az containerapp create y az containerapp job create, admiten archivos YAML para la entrada. Para agregar una identidad asignada por el sistema, agregue una sección identity a la plantilla de YAML.
identity:
type: SystemAssigned
Al agregar el tipo asignado por el sistema se indica a Azure que debe crear y administrar la identidad para la aplicación. Para obtener un ejemplo completo de plantilla YAML, consulte Especificación de API de ARM.
Se puede usar una plantilla de Bicep para automatizar la implementación de la aplicación de contenedor y los recursos. Para agregar una identidad asignada por el sistema, agregue una sección identity a la plantilla de Bicep.
La configuración de una Container App con una identidad asignada por el usuario requiere que primero cree la identidad; a continuación, debe agregar su identificador de recurso a la configuración de la Container App. Puede crear identidades asignadas por el usuario a través de Azure Portal o la CLI de Azure. Para obtener información sobre cómo crear y administrar identidades asignadas por el usuario, consulte Administración de identidades administradas asignadas por el usuario.
Dentro de la pestaña Usuario asignado, seleccione Agregar.
Busque y seleccione la identidad que creó anteriormente.
Seleccione Agregar.
Cree una identidad asignada por el usuario.
az identity create --resource-group <GROUP_NAME> --name <IDENTITY_NAME> --output json
Anote la propiedad id de la nueva identidad.
Ejecute el comando az containerapp identity assign para asignar la identidad a la aplicación. El parámetro "identities" es una lista separada por espacios.
Reemplace por <IDENTITY_RESOURCE_ID> la propiedad id de la identidad. Para asignar más de una identidad asignada por el usuario, proporcione una lista separada por espacios de identificadores de identidad al parámetro --user-assigned.
Para agregar una o varias identidades asignadas por el usuario, agregue una sección identity a la plantilla de ARM. Reemplace <IDENTITY1_RESOURCE_ID> y <IDENTITY2_RESOURCE_ID> por los identificadores de recursos de las identidades que quiere agregar.
Especifique cada identidad asignada por el usuario agregando un elemento al objeto userAssignedIdentities con el identificador de recursos de la identidad como clave. Use un objeto vacío como valor.
Una aplicación puede tener identidades asignadas por el sistema y asignadas por el usuario al mismo tiempo. En este caso, el valor de la propiedad type sería SystemAssigned,UserAssigned.
Para agregar una o varias identidades asignadas por el usuario, agregue una sección identity al archivo de configuración de YAML. Reemplace <IDENTITY1_RESOURCE_ID> y <IDENTITY2_RESOURCE_ID> por los identificadores de recursos de las identidades que quiere agregar.
Especifique cada identidad asignada por el usuario agregando un elemento al objeto userAssignedIdentities con el identificador de recursos de la identidad como clave. Use un objeto vacío como valor.
Una aplicación puede tener identidades asignadas por el sistema y asignadas por el usuario al mismo tiempo. En este caso, la propiedad type sería SystemAssigned,UserAssigned.
Para agregar una o varias identidades asignadas por el usuario, agregue una sección identity a la plantilla de Bicep. Reemplace <IDENTITY1_RESOURCE_ID> y <IDENTITY2_RESOURCE_ID> por los identificadores de recursos de las identidades que quiere agregar.
Especifique cada identidad asignada por el usuario agregando un elemento al objeto userAssignedIdentities con el identificador de recursos de la identidad como clave. Use un objeto vacío como valor.
Una aplicación puede tener identidades asignadas por el sistema y asignadas por el usuario al mismo tiempo. En este caso, la propiedad type sería SystemAssigned,UserAssigned.
Configuración de un recurso de destino
En el caso de algunos recursos, debe configurar las asignaciones de roles para que la identidad administrada de la aplicación le conceda acceso. De lo contrario, las llamadas de la aplicación a los servicios, como Azure Key Vault y Azure SQL Database, se rechazarán incluso cuando usa un token válido para esa identidad. Para obtener más información acerca del control de acceso basado en roles (Azure RBAC), consulte ¿Qué es RBAC? Para obtener más información sobre los recursos que admiten tokens de Microsoft Entra, consulte Servicios de Azure que admiten autenticación de Microsoft Entra.
Importante
Los servicios de back-end para identidades administradas mantienen una memoria caché por URI de recurso durante unas veinticuatro horas. Si actualiza la directiva de acceso de un recurso de destino determinado y recupera inmediatamente un token para ese recurso, es posible que siga obteniendo un token en caché con permisos obsoletos hasta la expiración del token. No se admite forzar una actualización de tokens.
Conectar a los servicios de Azure en el código de la aplicación
Con identidades administradas, una aplicación puede obtener tokens para acceder a los recursos de Azure que usan Microsoft Entra ID, como Azure SQL Database, Azure Key Vault y Azure Storage. Estos tokens representan a la aplicación que accede al recurso, y no a un usuario específico de la aplicación.
Container Apps proporciona un punto de conexión de REST accesible internamente para recuperar tokens. El punto de conexión REST está disponible desde dentro de la aplicación con una solicitud HTTP GET estándar, que puede enviar con un cliente HTTP genérico en su idioma preferido. Para .NET, JavaScript, Java y Python, la biblioteca cliente de identidad de Azure proporciona una abstracción sobre este punto de conexión de REST. Puede conectarse a otros servicios de Azure agregando un objeto de credencial al cliente específico del servicio.
Nota:
Cuando se utiliza la biblioteca de clientes de Azure Identity, es necesario especificar explícitamente el id de cliente de identidad administrada asignada por el usuario.
Al conectarse a orígenes de datos de Azure SQL con Entity Framework Core, considere la posibilidad de usar Microsoft.Data.SqlClient, que proporciona cadenas de conexión especiales para la conectividad de identidad administrada.
Para las aplicaciones de .NET, la manera más sencilla de trabajar con una identidad administrada es mediante la biblioteca cliente de identidad de Azure para .NET. Consulta los recursos siguientes para obtener más información:
Los ejemplos vinculados usan DefaultAzureCredential. Este objeto es eficaz en la mayoría de los escenarios, ya que el mismo patrón funciona en Azure (con identidades administradas) y en el equipo local (sin identidades administradas).
Para las aplicaciones de Node.js, la manera más sencilla de trabajar con una identidad administrada es mediante la biblioteca cliente de identidad de Azure para JavaScript. Consulta los recursos siguientes para obtener más información:
Los ejemplos vinculados usan DefaultAzureCredential. Este objeto es eficaz en la mayoría de los escenarios, ya que el mismo patrón funciona en Azure (con identidades administradas) y en el equipo local (sin identidades administradas).
Para obtener más ejemplos de código de la biblioteca cliente de identidad de Azure para JavaScript, consulte Ejemplos de identidad de Azure.
Para las aplicaciones de Python, la manera más sencilla de trabajar con una identidad administrada es mediante la biblioteca cliente de identidad de Azure para Python. Consulta los recursos siguientes para obtener más información:
Los ejemplos vinculados usan DefaultAzureCredential. Este objeto es eficaz en la mayoría de los escenarios, ya que el mismo patrón funciona en Azure (con identidades administradas) y en el equipo local (sin identidades administradas).
Para las aplicaciones y funciones de Java, la manera más sencilla de trabajar con una identidad administrada es mediante la biblioteca cliente de identidad de Azure para Java. Consulta los recursos siguientes para obtener más información:
Los ejemplos vinculados usan DefaultAzureCredential. Este objeto es eficaz en la mayoría de los escenarios, ya que el mismo patrón funciona en Azure (con identidades administradas) y en el equipo local (sin identidades administradas).
Para obtener más ejemplos de código de la biblioteca cliente de identidad de Azure para Java, consulte Ejemplos de identidad de Azure.
Use el siguiente script para recuperar un token del punto de conexión local especificando un URI de recurso de un servicio de Azure. Reemplace el marcador de posición por el URI del recurso para obtener el token.
Una solicitud HTTP GET sin formato es similar al ejemplo siguiente.
Obtenga la dirección URL del punto de conexión del token de la variable de entorno IDENTITY_ENDPOINT. x-identity-header contiene el GUID que se almacena en la variable de entorno IDENTITY_HEADER.
GET http://localhost:42356/msi/token?resource=https://vault.azure.net&api-version=2019-08-01 HTTP/1.1
x-identity-header: 853b9a84-5bfa-4b22-a3f3-0b9a43d9ad8a
Una respuesta podría ser similar a la de este ejemplo:
Una aplicación contenedora con una identidad administrada expone el punto de conexión de identidad mediante la definición de dos variables de entorno:
IDENTITY_ENDPOINT: dirección URL local desde donde la aplicación contenedora puede solicitar tokens.
IDENTITY_HEADER: encabezado usado para ayudar a mitigar los ataques de falsificación de solicitudes del lado servidor (SSRF). La plataforma se encarga de cambiarlo.
Para obtener un token para un recurso, realice una solicitud HTTP GET al punto de conexión, incluyendo los siguientes parámetros:
Nombre de parámetro
En
Descripción
resource
Consultar
El URI de recurso de Microsoft Entra del recurso para el que se debe obtener un token. El recurso podría ser uno de los servicios de Azure que admiten la autenticación de Microsoft Entra o cualquier otro URI de recursos.
api-version
Consultar
La versión de la API de token que se usará. Use "2019-08-01" o posterior.
X-IDENTITY-HEADER
Encabezado
Valor de la variable de entorno IDENTITY_HEADER. Este encabezado se utiliza para mitigar los ataques de falsificación de solicitudes del servidor (SSRF).
client_id
Consultar
(Opcional) El identificador del cliente de la identidad asignada por el usuario que se va a usar. No se puede usar en una solicitud que incluya principal_id, mi_res_id o object_id. Si se omiten todos los parámetros de identificador (client_id, principal_id, object_id y mi_res_id), se usa la identidad asignada por el sistema.
principal_id
Consultar
(Opcional) El identificador de la entidad de seguridad de la identidad asignada por el usuario que se va a usar. object_id es un alias que se puede utilizar en su lugar. No se puede usar en una solicitud que incluya client_id, mi_res_id u object_id. Si se omiten todos los parámetros de identificador (client_id, principal_id, object_id y mi_res_id), se usa la identidad asignada por el sistema.
mi_res_id
Consultar
(Opcional) El identificador del recurso de Azure de la identidad asignada por el usuario que se va a usar. No se puede usar en una solicitud que incluya principal_id, client_id o object_id. Si se omiten todos los parámetros de identificador (client_id, principal_id, object_id y mi_res_id), se usa la identidad asignada por el sistema.
Importante
Si intenta obtener tokens para las identidades asignadas por el usuario, debe incluir una de las propiedades opcionales. De lo contrario, el servicio de token intentará obtener un token para una identidad que haya asignado el sistema, la cual puede existir o no.
Visualización de identidades administradas
Puede mostrar las identidades administradas asignadas por el sistema y asignadas por el usuario mediante el siguiente comando de la CLI de Azure. La salida muestra el tipo de identidad administrada, los identificadores de inquilino y los identificadores de entidad de seguridad de todas las identidades administradas asignadas a la aplicación contenedora.
az containerapp identity show --name <APP_NAME> --resource-group <GROUP_NAME>
Eliminación de una entidad administrada
Cuando se quita una identidad asignada por el sistema, se elimina de Microsoft Entra ID. Las identidades asignadas por el sistema también se eliminan automáticamente de Microsoft Entra ID cuando se elimina el propio recurso de la aplicación contenedora. La eliminación de las identidades administradas asignadas por el usuario de su aplicación de contenedor no las elimina de Microsoft Entra ID.
En el panel de navegación izquierdo de la página de la aplicación, desplácese hacia abajo hasta el grupo Configuración.
Seleccione Identidad. A continuación, siga los pasos según el tipo de identidad:
Identidad asignada por el sistema: en la pestaña Asignado por el sistema, cambie Estado a Desactivado. Seleccione Guardar.
Identidad asignada por el usuario: seleccione la pestaña Asignado por el usuario, active la casilla de la identidad y seleccione Quitar. Seleccione Sí para confirmar la acción.
Para quitar la identidad asignada por el sistema:
az containerapp identity remove --name <APP_NAME> --resource-group <GROUP_NAME> --system-assigned
Para quitar una o más identidades asignadas por el usuario:
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
