Cómo usar identidades administradas para App Service y Azure Functions

Artículo
06/27/2023

En este artículo se muestra cómo crear una identidad administrada para las aplicaciones App Service y Azure Functions y cómo usarla para acceder a otros recursos.

Importante

Dado que las identidades administradas no admiten escenarios entre directorios, no se comportan según lo esperado si la aplicación se migra entre suscripciones o inquilinos. Para volver a crear las identidades administradas después de este cambio, consulte ¿Se van a volver a crear automáticamente las identidades administradas si muevo una suscripción a otro directorio?. Los recursos de nivel inferior también han de tener directivas de acceso actualizadas para utilizar la nueva identidad.

Nota

Las identidades administradas no están disponibles para las aplicaciones implementadas en Azure Arc.

Una identidad administrada de Microsoft Entra ID permite a la aplicación acceder fácilmente a otros recursos protegidos por Microsoft Entra, como Azure Key Vault. La identidad está administrada por la plataforma Azure y no requiere que aprovisione o rote los secretos. Para obtener más información sobre las identidades administradas en Microsoft Entra ID, consulte Identidades administradas para recursos de Azure.

La aplicación puede tener dos tipos de identidades:

Una identidad asignada por el sistema está asociada a la aplicación y se elimina si 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 de Azure independiente que puede asignarse a la aplicación. Una aplicación puede tener varias identidades asignadas por el usuario.

La configuración de la identidad administrada es específica de la ranura. Para configurar una identidad administrada para una ranura de implementación en el portal, vaya primero a la ranura. Para buscar la identidad administrada de la aplicación web o la ranura de implementación en el inquilino de Microsoft Entra desde Azure Portal, búsquela directamente desde la página Información general del inquilino. Normalmente, el nombre de la ranura es similar a <app-name>/slots/<slot-name>.

En este vídeo, se muestra cómo usar identidades administradas para App Service.

Los pasos del vídeo también se describen en las secciones siguientes.

Adición de una identidad asignada por el sistema

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.
En la pestaña Asignado por el sistema, cambie Estado a Activado. Haga clic en Save(Guardar).

Ejecute el comando az webapp identity assign para crear una identidad asignada por el sistema:

az webapp identity assign --name myApp --resource-group myResourceGroup

Para App Service

Ejecute el comando Set-AzWebApp -AssignIdentity para crear una identidad asignada por el sistema para App Service:

Set-AzWebApp -AssignIdentity $true -Name <app-name> -ResourceGroupName <group-name>

Para Functions

Ejecute el comando Update-AzFunctionApp -IdentityType para crear una identidad asignada por el sistema para una aplicación de funciones:

Update-AzFunctionApp -Name $functionAppName -ResourceGroupName $resourceGroupName -IdentityType SystemAssigned

Se puede utilizar una plantilla de Azure Resource Manager para automatizar la implementación de los recursos de Azure. Para obtener más información acerca de la implementación en App Service y Functions, vea Automating resource deployment in App Service (Automatización de la implementación de recursos en App Service) y Automatización de la implementación de recursos para una aplicación de función en Azure Functions.

Se puede crear cualquier recurso de tipo Microsoft.Web/sites con una identidad mediante la inclusión de la siguiente propiedad en la definición de recursos:

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

Por ejemplo, una plantilla de aplicación web podría tener el aspecto del siguiente JSON:

{
    "apiVersion": "2022-03-01",
    "type": "Microsoft.Web/sites",
    "name": "[variables('appName')]",
    "location": "[resourceGroup().location]",
    "identity": {
        "type": "SystemAssigned"
    },
    "properties": {
        "name": "[variables('appName')]",
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
        "hostingEnvironment": "",
        "clientAffinityEnabled": false,
        "alwaysOn": true
    },
    "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]"
    ]
}

Cuando se crea el sitio, tiene las siguientes propiedades adicionales:

"identity": {
    "type": "SystemAssigned",
    "tenantId": "<tenant-id>",
    "principalId": "<principal-id>"
}

La propiedad tenantId identifica a qué inquilino de Microsoft Entra pertenece la identidad. El valor principalId es un identificador único para la nueva identidad de la aplicación. En Microsoft Entra ID, la entidad de servicio tiene el mismo nombre que asignó a la instancia de App Service o Azure Functions.

Si posteriormente tiene que hacer referencia a estas propiedades en la plantilla, puede hacerlo mediante la función de plantilla reference() con la marca 'Full', tal y como se muestra en este ejemplo:

{
    "tenantId": "[reference(resourceId('Microsoft.Web/sites', variables('appName')), '2018-02-01', 'Full').identity.tenantId]",
    "objectId": "[reference(resourceId('Microsoft.Web/sites', variables('appName')), '2018-02-01', 'Full').identity.principalId]",
}

Adición de una identidad asignada por el usuario

La creación de una aplicación con una identidad asignada por el usuario requiere que se cree la identidad y luego se agregue su identificador de recurso a la configuración de la aplicación.

En primer lugar, tendrá que crear un recurso de identidad asignada por el usuario.

Cree un recurso de identidad administrada asignada por el usuario según estas instrucciones.
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.
Seleccione Asignado por el usuario>Agregar.
Busque la identidad que ha creado anteriormente, selecciónela y seleccione Agregar.

Una vez que seleccione Agregar, la aplicación se reinicia.

Cree una identidad asignada por el usuario.

az identity create --resource-group <group-name> --name <identity-name>

Ejecute el comando az webapp identity assign para asignar la identidad a la aplicación.

az webapp identity assign --resource-group <group-name> --name <app-name> --identities <identity-id>

Para App Service

Actualmente no se admite la adición de una identidad asignada por el usuario en App Service.

Para Functions

Cree una identidad asignada por el usuario.

Install-Module -Name Az.ManagedServiceIdentity -AllowPrerelease
$userAssignedIdentity = New-AzUserAssignedIdentity -Name $userAssignedIdentityName -ResourceGroupName <group-name>

Ejecute el comando Update-AzFunctionApp -IdentityType UserAssigned -IdentityId para asignar la identidad en Functions:

Update-AzFunctionApp -Name <app-name> -ResourceGroupName <group-name> -IdentityType UserAssigned -IdentityId $userAssignedIdentity.Id

Se puede crear cualquier recurso de tipo Microsoft.Web/sites con una identidad incluyendo el siguiente bloque en la definición del recurso, que reemplaza <resource-id> por el identificador de recurso de la identidad deseada:

"identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
        "<resource-id>": {}
    }
}

Nota

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.

Al agregar el tipo asignado por el usuario se indica a Azure que use la identidad asignada por el usuario especificada para la aplicación.

Por ejemplo, una plantilla de aplicación web podría tener el aspecto del siguiente JSON:

{
    "apiVersion": "2022-03-01",
    "type": "Microsoft.Web/sites",
    "name": "[variables('appName')]",
    "location": "[resourceGroup().location]",
    "identity": {
        "type": "UserAssigned",
        "userAssignedIdentities": {
            "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', variables('identityName'))]": {}
        }
    },
    "properties": {
        "name": "[variables('appName')]",
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
        "hostingEnvironment": "",
        "clientAffinityEnabled": false,
        "alwaysOn": true
    },
    "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
        "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', variables('identityName'))]"
    ]
}

Cuando se crea el sitio, tiene las siguientes propiedades adicionales:

"identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
        "<resource-id>": {
            "principalId": "<principal-id>",
            "clientId": "<client-id>"
        }
    }
}

El valor principalId es un identificador único de la identidad que se usa para la administración de Microsoft Entra. El valor clientId es un identificador único de la nueva identidad de la aplicación que se usa para especificar qué identidad utilizar durante las llamadas de runtime.

Configurar recurso de destino

Es posible que deba configurar el recurso de destino para permitir el acceso desde la aplicación o la función. Por ejemplo, si solicita un token para acceder a Key Vault, también debe agregar una directiva de acceso que incluya la identidad administrada de la aplicación o la función. De lo contrario, las llamadas a Key Vault se rechazarán, incluso si usa un token válido. Lo mismo se aplica a Azure SQL Database. 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. Actualmente no existe ninguna forma de forzar la actualización de un token.

Conectar a los servicios de Azure en el código de la aplicación

Con su identidad administrada, una aplicación puede obtener tokens para los recursos de Azure protegidos por 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.

App Service y Azure Functions proporcionan un punto de conexión REST accesible internamente para la recuperación de tokens. Se puede acceder al punto de conexión REST desde dentro de la aplicación con un HTTP GET estándar, que se puede implementar con un cliente HTTP genérico en todos los lenguajes. Para .NET, JavaScript, Java y Python, la biblioteca cliente de identidad de Azure proporciona una abstracción sobre este punto de conexión REST y simplifica la experiencia de desarrollo. Conectarse a otros servicios de Azure es tan sencillo como agregar un objeto de credencial al cliente específico del servicio.

La solicitud HTTP GET sin formato es similar al ejemplo siguiente:

GET /MSI/token?resource=https://vault.azure.net&api-version=2019-08-01 HTTP/1.1
Host: localhost:4141
X-IDENTITY-HEADER: 853b9a84-5bfa-4b22-a3f3-0b9a43d9ad8a

Y una respuesta de ejemplo puede tener el siguiente aspecto:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJ0eXAi…",
    "expires_on": "1586984735",
    "resource": "https://vault.azure.net",
    "token_type": "Bearer",
    "client_id": "5E29463D-71DA-4FE0-8E69-999B57DB23B0"
}

Esta respuesta es la misma que la respuesta para la solicitud de token de acceso de servicio a servicio de Microsoft Entra. Para acceder a Key Vault, agregará el valor de access_token a una conexión de cliente con el almacén.

Nota

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. Por ejemplo, consulte Tutorial: protección de la conexión con Azure SQL Database desde App Service mediante una identidad administrada.

Para las aplicaciones y funciones de .NET, la manera más sencilla de trabajar con una identidad administrada es mediante la biblioteca cliente de identidad de Azure para .NET. Para obtener instrucciones detalladas, consulte Tutorial: Conexión a bases de datos de Azure desde App Service sin secretos mediante una identidad administrada.

Consulte los encabezados de documentación correspondientes de la biblioteca cliente para obtener información:

Los ejemplos vinculados usan DefaultAzureCredential. Resulta útil para la mayoría de los escenarios porque el mismo patrón funciona en Azure (con identidades administradas) y en la máquina local (sin identidades administradas).

Para las aplicaciones de Node.js y las funciones de JavaScript, la manera más sencilla de trabajar con una identidad administrada es mediante la biblioteca cliente de identidad de Azure para JavaScript. Para obtener instrucciones detalladas, consulte Tutorial: Conexión a bases de datos de Azure desde App Service sin secretos mediante una identidad administrada.

Consulte los encabezados de documentación correspondientes de la biblioteca cliente para obtener información:

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 y funciones de Python, la manera más sencilla de trabajar con una identidad administrada es mediante la biblioteca cliente de identidad de Azure para Python. Para obtener instrucciones detalladas, consulte Tutorial: Conexión a bases de datos de Azure desde App Service sin secretos mediante una identidad administrada.

Consulte los encabezados de documentación correspondientes de la biblioteca cliente para obtener información:

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. Para obtener instrucciones detalladas, consulte Tutorial: Conexión a bases de datos de Azure desde App Service sin secretos mediante una identidad administrada.

Consulte los encabezados de documentación correspondientes de la biblioteca cliente para obtener información:

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:

$resourceURI = "https://<AAD-resource-URI-for-resource-to-obtain-token>"
$tokenAuthURI = $env:IDENTITY_ENDPOINT + "?resource=$resourceURI&api-version=2019-08-01"
$tokenResponse = Invoke-RestMethod -Method Get -Headers @{"X-IDENTITY-HEADER"="$env:IDENTITY_HEADER"} -Uri $tokenAuthURI
$accessToken = $tokenResponse.access_token

Para más información sobre el punto de conexión REST, consulte Referencia del punto de conexión REST.

Quitar una identidad

Cuando se quita una identidad asignada por el sistema, se elimina de Microsoft Entra ID. Las identidades asignadas por el sistema también se quitan automáticamente de Microsoft Entra ID cuando se elimina el propio recurso de la aplicación.

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. Haga clic en Save(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 webapp identity remove --name <app-name> --resource-group <group-name>

Para quitar una o más identidades asignadas por el usuario:

az webapp identity remove --name <app-name> --resource-group <group-name> --identities <identity-id1> <identity-id2> ...

También puede quitar la identidad asignada por el sistema especificando [system] en --identities.

Para App Service

Ejecute el comando Set-AzWebApp -AssignIdentity para quitar una identidad asignada por el sistema para App Service:

Set-AzWebApp -AssignIdentity $false -Name <app-name> -ResourceGroupName <group-name>

Para Functions

Para quitar todas las identidades de Azure PowerShell (solo Azure Functions):

# Update an existing function app to have IdentityType "None".
Update-AzFunctionApp -Name $functionAppName -ResourceGroupName $resourceGroupName -IdentityType None

Para quitar todas las identidades de una plantilla de ARM:

"identity": {
    "type": "None"
}

Nota

También hay una configuración de aplicación que se puede establecer, WEBSITE_DISABLE_MSI, que simplemente deshabilita el servicio de token local. Sin embargo, con este valor, la identidad no se mueve y las herramientas siguen mostrando la identidad administrada como "activada" o "habilitada". Por lo tanto, no se recomienda su uso.

Referencia de punto de conexión REST

Una aplicación con una identidad administrada hace que este punto de conexión esté disponible mediante la definición de dos variables de entorno:

IDENTITY_ENDPOINT: dirección URL del servicio de token local.
IDENTITY_HEADER: encabezado que se usa para ayudar a mitigar los ataques de falsificación de solicitudes del servidor (SSRF). La plataforma se encarga de cambiarlo.

La variable IDENTITY_ENDPOINT es una dirección URL local desde la que la aplicación puede solicitar tokens. Para obtener un token para un recurso, realice una solicitud HTTP GET para este punto de conexión, incluyendo los parámetros siguientes:

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. Este podría ser uno de los servicios de Azure que admiten la autenticación de Microsoft Entra o cualquier otro URI de recurso.

api-version Consultar La versión de la API de token que se usará. Mediante 2019-08-01.

X-IDENTITY-HEADER Encabezado El valor de la variable de entorno IDENTITY_HEADER. Este encabezado se utiliza para ayudar a 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.

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. Este podría ser uno de los servicios de Azure que admiten la autenticación de Microsoft Entra o cualquier otro URI de recurso.
api-version	Consultar	La versión de la API de token que se usará. Mediante `2019-08-01`.
X-IDENTITY-HEADER	Encabezado	El valor de la variable de entorno IDENTITY_HEADER. Este encabezado se utiliza para ayudar a 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.

Cómo usar identidades administradas para App Service y Azure Functions

Adición de una identidad asignada por el sistema

Para App Service

Para Functions

Adición de una identidad asignada por el usuario

Para App Service

Para Functions

Configurar recurso de destino

Conectar a los servicios de Azure en el código de la aplicación

Quitar una identidad

Para App Service

Para Functions

Referencia de punto de conexión REST

Pasos siguientes

Recursos adicionales