Compartir a través de


Conexión desde la aplicación a los recursos sin administrar credenciales

Los recursos de Azure con compatibilidad con identidades administradas siempre incluyen una opción para especificar una identidad administrada con la que conectarse a los recursos de Azure que admiten la autenticación de Microsoft Entra. La compatibilidad con identidades administradas hace que los desarrolladores no necesiten administrar credenciales en el código. Las identidades administradas son la opción de autenticación recomendada cuando se trabaja con recursos de Azure que las admitan. Lea la introducción a la identidades administradas.

En esta página se muestra cómo configurar una instancia de App Service para que pueda conectarse a Azure Key Vault, Azure Storage y Microsoft SQL Server. Se pueden usar los mismos principios para cualquier recurso de Azure que admita identidades administradas y que se conecte a los recursos que admitan la autenticación de Microsoft Entra.

Los ejemplos de código usan la biblioteca cliente de Identidad de Azure, que es el método recomendado, ya que administra automáticamente muchos de los pasos, incluida la adquisición de un token de acceso que se utiliza en la conexión.

¿A qué recursos se pueden conectar las identidades administradas?

Una identidad administrada puede conectarse a cualquier recurso que admita la autenticación de Microsoft Entra. En general, no se requiere una compatibilidad especial para que el recurso permita que las identidades administradas se conecten a él.

Algunos recursos no admiten la autenticación de Microsoft Entra o su biblioteca cliente no admite la autenticación con un token. Siga leyendo para ver nuestras instrucciones sobre cómo usar una identidad administrada para acceder de forma segura a las credenciales sin necesidad de almacenarlas en el código o la configuración de la aplicación.

Creación de identidades administradas

Hay dos tipos de identidades administradas: asignadas por el sistema y asignadas por el usuario. Las identidades asignadas por el sistema están vinculadas directamente a un único recurso de Azure. Cuando se elimina el recurso de Azure, también se elimina la identidad. Una identidad administrada asignada por el usuario se puede asociar a varios recursos de Azure, y su ciclo de vida es independiente de esos recursos.

Le recomendamos usar una identidad administrada asignada por el usuario para la mayoría de casos. Si el recurso de origen que utiliza no admite identidades administradas asignadas por el usuario, debe consultar la documentación del proveedor de ese recurso para aprender a configurarlo y que tenga una identidad administrada asignada por el sistema.

Importante

La cuenta usada para crear identidades administradas necesita un rol del tipo "Colaborador de identidad administrada" para crear una nueva identidad administrada asignada por el usuario.

Cree una identidad administrada asignada por el usuario mediante la opción preferida:

Después de crear una identidad administrada asignada por el usuario, anote los valores clientId y principalId que se devuelven cuando se crea la identidad administrada. Usará principalId al agregar permisos y clientId en el código de la aplicación.

Configuración de App Service con una identidad administrada asignada por el usuario

Para poder usar la identidad administrada en el código, tenemos que asignarla a la instancia de App Service que la usará. Para el proceso de configuración de una instancia de App Service que sirve para usar una identidad administrada asignada por el usuario es necesario que indique el identificador de recursos de la identidad administrada en la configuración de la aplicación.

Incorporación de permisos a la identidad

Una vez que haya configurado App Service para que use una identidad administrada asignada por el usuario, conceda los permisos necesarios a la identidad. En esta situación, estamos usando esta identidad para interactuar con Azure Storage, por lo que debe usar el sistema de Control de acceso basado en roles (RBAC) de Azure para conceder permisos de identidad administrada asignada por el usuario al recurso.

Importante

Necesitará un rol como "Administrador de acceso de usuario" o "Propietario" para el recurso de destino a fin de agregar asignaciones de roles. Asegúrese de conceder los privilegios mínimos necesarios para que se ejecute la aplicación.

Para los recursos a los que desea acceder es necesario que conceda los permisos de identidad. 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.

Uso de identidades administradas en el código

Después de completar los pasos descritos anteriormente, App Service tendrá una identidad administrada con permisos para un recurso de Azure. Puede usar la identidad administrada para obtener un token de acceso que el código puede usar para interactuar con los recursos de Azure, en lugar de almacenar las credenciales en el código.

Se recomienda usar las bibliotecas cliente que proporcionamos para su lenguaje de programación preferido. Estas bibliotecas adquieren tokens de acceso para usted, lo que facilita la autenticación con el identificador de Microsoft Entra. Para más información, consulte Bibliotecas de cliente para la autenticación de identidades administradas.

Uso de una biblioteca de identidades de Azure para acceder a los recursos de Azure

Cada una de las bibliotecas de Identidad de Azure proporciona un tipo de DefaultAzureCredential. DefaultAzureCredential intenta autenticar automáticamente al usuario a través de flujos diferentes, incluidas las variables de entorno o un inicio de sesión interactivo. El tipo de credencial se puede usar en un entorno de desarrollo con sus propias credenciales. También se puede utilizar en el entorno de producción de Azure mediante una identidad administrada. No se requieren cambios en el código al implementar la aplicación.

Si usa identidades administradas asignadas por el usuario, también debe especificar explícitamente la identidad administrada asignada por el usuario con la que desea autenticarse pasando el identificador de cliente de la identidad como parámetro. Para recuperar el identificador de cliente, vaya a la identidad en Azure Portal.

Acceso a un blob en Azure Storage

using Azure.Identity;
using Azure.Storage.Blobs;

// code omitted for brevity

// Specify the Client ID if using user-assigned managed identities
var clientID = Environment.GetEnvironmentVariable("Managed_Identity_Client_ID");
var credentialOptions = new DefaultAzureCredentialOptions
{
    ManagedIdentityClientId = clientID
};
var credential = new DefaultAzureCredential(credentialOptions);                        

var blobServiceClient1 = new BlobServiceClient(new Uri("<URI of Storage account>"), credential);
BlobContainerClient containerClient1 = blobServiceClient1.GetBlobContainerClient("<name of blob>");
BlobClient blobClient1 = containerClient1.GetBlobClient("<name of file>");

if (blobClient1.Exists())
{
    var downloadedBlob = blobClient1.Download();
    string blobContents = downloadedBlob.Value.Content.ToString();                
}

Acceso a un secreto almacenado en Azure Key Vault

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;
using Azure.Core;

// code omitted for brevity

// Specify the Client ID if using user-assigned managed identities
var clientID = Environment.GetEnvironmentVariable("Managed_Identity_Client_ID");
var credentialOptions = new DefaultAzureCredentialOptions
{
    ManagedIdentityClientId = clientID
};
var credential = new DefaultAzureCredential(credentialOptions);        

var client = new SecretClient(
    new Uri("https://<your-unique-key-vault-name>.vault.azure.net/"),
    credential);
    
KeyVaultSecret secret = client.GetSecret("<my secret>");
string secretValue = secret.Value;

Acceso a Azure SQL Database

using Azure.Identity;
using Microsoft.Data.SqlClient;

// code omitted for brevity

// Specify the Client ID if using user-assigned managed identities
var clientID = Environment.GetEnvironmentVariable("Managed_Identity_Client_ID");
var credentialOptions = new DefaultAzureCredentialOptions
{
    ManagedIdentityClientId = clientID
};

AccessToken accessToken = await new DefaultAzureCredential(credentialOptions).GetTokenAsync(
    new TokenRequestContext(new string[] { "https://database.windows.net//.default" }));                        

using var connection = new SqlConnection("Server=<DB Server>; Database=<DB Name>;")
{
    AccessToken = accessToken.Token
};
var cmd = new SqlCommand("select top 1 ColumnName from TableName", connection);
await connection.OpenAsync();
SqlDataReader dr = cmd.ExecuteReader();
while(dr.Read())
{
    Console.WriteLine(dr.GetValue(0).ToString());
}
dr.Close();	

Uso de la Biblioteca de autenticación de Microsoft (MSAL) para acceder a los recursos de Azure

Además de las bibliotecas de identidad de Azure, también puede usar MSAL para acceder a los recursos de Azure mediante identidades administradas. Los fragmentos de código siguientes muestran cómo usar MSAL para acceder a los recursos de Azure en varios lenguajes de programación.

En el caso de las identidades administradas asignadas por el sistema, el desarrollador no necesita pasar ninguna información adicional. MSAL deduce automáticamente los metadatos pertinentes sobre la identidad asignada. En el caso de las identidades administradas asignadas por el usuario, el desarrollador debe pasar el identificador de cliente, el identificador de recurso completo o el identificador de objeto de la identidad administrada.

A continuación, puede adquirir un token para acceder a un recurso. Antes de usar identidades administradas, los desarrolladores deben habilitarlas para los recursos que quieren usar.

using Microsoft.Identity.Client;
using System;

string resource = "https://vault.azure.net";

// Applies to system-assigned managed identities only
IManagedIdentityApplication mi = ManagedIdentityApplicationBuilder.Create(ManagedIdentityId.SystemAssigned)
    .Build();

// Applies to user-assigned managed identities only
string userAssignedManagedIdentityClientId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx";
IManagedIdentityApplication mi = ManagedIdentityApplicationBuilder.Create(ManagedIdentityId.WithUserAssignedClientId(userAssignedManagedIdentityClientId))
    .Build();

// Acquire token
AuthenticationResult result = await mi.AcquireTokenForManagedIdentity(resource)
    .ExecuteAsync()
    .ConfigureAwait(false);

if (!string.IsNullOrEmpty(result.AccessToken))
{
    Console.WriteLine(result.AccessToken);
}

Conexión a recursos que no admiten la autenticación de Microsoft Entra o basada en tokens en las bibliotecas

Algunos recursos de Azure no admiten aún la autenticación de Microsoft Entra o sus bibliotecas cliente no admiten la autenticación con un token. Normalmente, estos recursos son tecnologías de código abierto que esperan un nombre de usuario y una contraseña o una clave de acceso en una cadena de conexión.

Para evitar almacenar las credenciales en el código o la configuración de la aplicación, puede almacenar las credenciales como un secreto en Azure Key Vault. Con el ejemplo mostrado anteriormente, puede recuperar el secreto de Azure Key Vault mediante una identidad administrada y pasar las credenciales a la cadena de conexión. Este enfoque significa que no es necesario administrar las credenciales directamente en el código o el entorno. Para obtener un ejemplo detallado, consulte Uso de identidades administradas para acceder a certificados de Azure Key Vault. Para más información sobre la autenticación de Azure Key Vault, consulte Autenticación de Azure Key Vault.

Instrucciones en caso de administrar tokens directamente

En algunos escenarios, es posible que quiera adquirir tokens para identidades administradas manualmente en lugar de usar un método integrado para conectarse al recurso de destino. Estos escenarios no incluyen ninguna biblioteca cliente para el lenguaje de programación que está utilizando o el recurso de destino al que se está conectando o al conectarse a recursos que no se ejecutan en Azure. Al adquirir tokens manualmente, se proporcionan las siguientes directrices:

Almacenamiento en caché de los tokens adquiridos

Para mejorar el rendimiento y la confiabilidad, se recomienda que la aplicación almacene en caché los tokens en la memoria local o cifrados si desea guardarlos en el disco. Como los tokens de identidad administrada son válidos durante 24 horas, no hay ninguna ventaja en solicitar nuevos tokens con regularidad, ya que se devolverá uno almacenado en caché desde el punto de conexión de emisión de tokens. Si supera los límites de solicitud, se le limitará la velocidad y recibirá un error HTTP 429.

Al adquirir un token, puede establecer la caché de tokens para que expire 5 minutos antes de la expires_on (o propiedad equivalente) que se devolverá cuando se genere el token.

Inspección de tokens

La aplicación no se debe basar en el contenido de un token. El contenido del token está pensado solo para la audiencia (recurso de destino) a la que se accede, no para el cliente que solicita el token. El contenido del token puede cambiar o cifrarse en el futuro.

No exponer ni mover tokens

Los tokens deben tratarse como credenciales. No los exponga a usuarios u otros servicios; por ejemplo, soluciones de registro y supervisión. No se deben mover desde el recurso de origen que los usa, excepto para autenticarse en el recurso de destino.

Pasos siguientes