Autenticación de aplicaciones hospedadas en recursos de Azure con el SDK de Azure para .NET
Cuando una aplicación se hospeda en Azure mediante un servicio como Azure App Service, Azure Virtual Machines o Azure Container Instances, el enfoque recomendado para autenticar una aplicación en recursos de Azure es usar una identidad administrada.
Una identidad administrada proporciona una identidad para la aplicación para que pueda conectarse a otros recursos de Azure sin necesidad de usar una clave secreta u otro secreto de aplicación. Internamente, Azure conoce la identidad de la aplicación y a qué recursos se le permite conectarse. Azure usa esta información para obtener automáticamente tokens de Microsoft Entra para que la aplicación permita la conexión a otros recursos de Azure, todo ello sin tener que administrar ningún secreto de aplicación.
Tipos de identidad administrada
Hay dos tipos de identidades administradas:
- Identidades administradas asignadas por el sistema: este tipo de identidad administrada se proporciona mediante un recurso de Azure y está vinculado a dicho recurso. Al habilitar la identidad administrada en un recurso de Azure, obtendrá una identidad administrada asignada por el sistema para ese recurso. Una identidad administrada asignada por el sistema está vinculada al ciclo de vida del recurso de Azure al que está asociada. Por tanto, cuando se elimina el recurso, Azure elimina automáticamente la identidad. Puesto que lo único que tiene que hacer es habilitar la identidad administrada para el recurso de Azure que hospeda el código, este es el tipo más sencillo de identidad administrada que se va a usar.
- Identidades administradas asignadas por el usuario: también es posible crear una identidad administrada como recurso independiente de Azure. Esto se usa con más frecuencia cuando la solución tiene varias cargas de trabajo que se ejecutan en varios recursos de Azure que necesitan compartir la misma identidad y los mismos permisos. Por ejemplo, si la solución tuviese componentes que se ejecutaran en varias instancias de máquina virtual y de App Service que necesitaran acceso al mismo conjunto de recursos de Azure, tendría sentido crear y usar una identidad administrada asignada por el usuario en dichos recursos.
En este artículo se describen los pasos necesarios para habilitar y usar una identidad administrada asignada por el sistema para una aplicación. Si necesita usar una identidad administrada asignada por el usuario, consulte el artículo Administración de identidades administradas asignadas por el usuario para obtener información sobre cómo crear una identidad administrada asignada por el usuario.
1: Activación de la identidad administrada en el recurso de Azure que hospeda la aplicación
El primer paso es habilitar la identidad administrada en el recurso de Azure que hospeda la aplicación. Por ejemplo, si hospeda una aplicación .NET mediante Azure App Service, debe habilitar la identidad administrada para la aplicación web de App Service que hospeda la aplicación. Si usara una máquina virtual para hospedar la aplicación, tendría que habilitar la máquina virtual para usar la identidad administrada.
Puede habilitar la identidad administrada para que se use para un recurso de Azure mediante Azure Portal o la CLI de Azure.
2: Asignación de roles a la identidad administrada
A continuación, debe determinar qué roles (permisos) necesita la aplicación y asignar la identidad administrada a dichos roles en Azure. Se pueden asignar roles a una identidad administrada en un ámbito de recurso, grupo de recursos o suscripción. En este ejemplo se muestra cómo asignar roles en el ámbito del grupo de recursos, ya que la mayoría de las aplicaciones agrupan todos sus recursos de Azure en un único grupo de recursos.
3: Implementación de DefaultAzureCredential en la aplicación
DefaultAzureCredential
admite varios métodos de autenticación y determina el método de autenticación que se usa en tiempo de ejecución. De esta manera, la aplicación puede usar diferentes métodos de autenticación en distintos entornos sin implementar código específico del entorno.
El orden y las ubicaciones en las que DefaultAzureCredential
busca las credenciales se encuentran en DefaultAzureCredential.
Para implementar DefaultAzureCredential
, agrega primero Azure.Identity
y, opcionalmente, los paquetes Microsoft.Extensions.Azure
a la aplicación. Puedes realizar esta acción mediante la línea de comandos o el Administrador de paquetes de NuGet.
Abre el entorno de terminal que prefieras en el directorio del proyecto de aplicación y escribe el comando siguiente.
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure
Por lo general, se accede a los servicios de Azure mediante las clases de cliente correspondientes desde el SDK. Estas clases y sus propios servicios personalizados deben registrarse en el archivo Program.cs
para que se pueda acceder a ellas a través de la inserción de dependencias en toda la aplicación. Dentro de Program.cs
, sigue los pasos que se indican a continuación para configurar correctamente el servicio y DefaultAzureCredential
.
- Incluye los espacio de nombres
Azure.Identity
yMicrosoft.Extensions.Azure
con una instrucción using. - Registra el servicio de Azure mediante los métodos auxiliares pertinentes.
- Pasa una instancia del objeto
DefaultAzureCredential
al métodoUseCredential
.
En el segmento de código siguiente se muestra un ejemplo de esto.
using Microsoft.Extensions.Azure;
using Azure.Identity;
// Inside of Program.cs
builder.Services.AddAzureClients(x =>
{
x.AddBlobServiceClient(new Uri("https://<account-name>.blob.core.windows.net"));
x.UseCredential(new DefaultAzureCredential());
});
Como alternativa, también puede usar DefaultAzureCredential
en los servicios de manera más directa sin la ayuda de los métodos de registro de Azure adicionales, tal como se muestra a continuación.
using Azure.Identity;
// Inside of Program.cs
builder.Services.AddSingleton<BlobServiceClient>(x =>
new BlobServiceClient(
new Uri("https://<account-name>.blob.core.windows.net"),
new DefaultAzureCredential()));
Cuando el código anterior se ejecuta en tu estación de trabajo local durante el desarrollo local, buscará una entidad de servicio de aplicación en las variables de entorno o en Visual Studio, VS Code, la CLI de Azure o Azure PowerShell para un conjunto de credenciales de desarrollador. Cualquiera de estas pueden usarse para autenticar la aplicación en los recursos de Azure durante el desarrollo local.
Cuando se implementa en Azure, este mismo código también puede autenticar tu aplicación en otros recursos de Azure. DefaultAzureCredential
puede recuperar la configuración del entorno y las configuraciones de identidad administrada para autenticarse en otros servicios automáticamente.
Comentarios
https://aka.ms/ContentUserFeedback.
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:Enviar y ver comentarios de