Compartir vía


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

Los recursos de Azure con compatibilidad con identidades administradas siempre proporcionan 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 una introducción a 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 escenarios. 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 como "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 cree la identidad administrada. Usa 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 un centro de desarrollo

Para poder usar la identidad administrada en el código, tenemos que asignarla a App Service que la usará. El proceso de configuración de una instancia de App Service para usar una identidad administrada asignada por el usuario requiere que especifique 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 este escenario, estamos usando esta identidad para interactuar con Azure Storage, por lo que debe usar el sistema de Control de acceso basado en rol (RBAC) de Azure para conceder permisos de identidad administrada asignadas 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.

Los recursos a los que desea acceder requieren 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 las identidades administradas en el código

Después de completar los pasos descritos anteriormente, App Service tiene 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 destino, en lugar de almacenar las credenciales en el código.

Recomendamos usar la biblioteca de identidades de Azure para el lenguaje de programación preferido. La biblioteca adquiere tokens de acceso para usted, lo que facilita la conexión a los recursos de destino.

Más información sobre las bibliotecas de identidades de Azure a continuación:

Uso de la biblioteca de identidades de Azure en el entorno de desarrollo

Las bibliotecas de identidad de Azure proporcionan un tipo DefaultAzureCredential. DefaultAzureCredential intenta autenticarse automáticamente mediante varios mecanismos, incluidas las variables de entorno o un inicio de sesión interactivo. El tipo de credencial se puede usar en el 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 y pasar 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();	

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.

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 memoria caché de tokens para que expire 5 minutos antes de 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