Autenticación de aplicaciones hospedadas en Azure en recursos de Azure con el SDK de Azure para JavaScript
Cuando una aplicación se hospeda en Azure (mediante un servicio como App de Azure 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 la aplicación se conecte a otros recursos de Azure sin necesidad de usar un secreto (por ejemplo, un cadena de conexión de clave). 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 la aplicación para permitir que se conecte a otros recursos de Azure, todo ello sin tener que administrar (crear o rotar) los secretos de autenticación.
Tipos de identidad administrada
Hay dos tipos de identidades administradas:
- Identidades administradas asignadas por el sistema: un único recurso de Azure
- Identidades administradas asignadas por el usuario: varios recursos de Azure
En este artículo se describen los pasos 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.
Identidades administradas asignadas por el sistema para un único recurso
Las identidades administradas asignadas por el sistema se proporcionan y están vinculadas directamente a un recurso de Azure. Al habilitar la identidad administrada en un recurso de Azure, obtendrá una identidad administrada asignada por el sistema para ese recurso. Está vinculado al ciclo de vida del recurso de Azure. 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 para varios recursos
Conceptualmente, esta identidad es un recurso de Azure independiente. 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 tuviera componentes que se ejecutaron en varias instancias de App Service y máquina virtual, y todos ellos necesitaban acceso al mismo conjunto de recursos de Azure, crear y usar una identidad administrada asignada por el usuario en esos recursos tendría sentido.
1 - Asignado por el sistema: Habilitar en la aplicación hospedada
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 de Django mediante App de Azure Service, debe habilitar la identidad administrada para esa aplicación web de App Service. 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
La DefaultAzureCredential
clase detectará automáticamente que se usa una identidad administrada y usará la identidad administrada para autenticarse en otros recursos de Azure. Como se describe en el artículo Introducción a la autenticación de Azure SDK para JavaScript, 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.
Primero, agregue el paquete @azure/identity a la aplicación.
npm install @azure/identity
A continuación, para cualquier código javaScript que cree un objeto de cliente del SDK de Azure en la aplicación, quiere:
- Importar la clase
DefaultAzureCredential
desde el módulo@azure/identity
. - Crear un objeto
DefaultAzureCredential
. - Pasar el objeto
DefaultAzureCredential
al constructor de objetos de cliente del SDK de Azure.
En el segmento de código siguiente se muestra un ejemplo de esto.
// connect-with-default-azure-credential.js
import { BlobServiceClient } from '@azure/storage-blob';
import { DefaultAzureCredential } from '@azure/identity';
import 'dotenv/config'
const accountName = process.env.AZURE_STORAGE_ACCOUNT_NAME;
if (!accountName) throw Error('Azure Storage accountName not found');
const blobServiceClient = new BlobServiceClient(
`https://${accountName}.blob.core.windows.net`,
new DefaultAzureCredential()
);
Cuando el código anterior se ejecuta en la estación de trabajo local durante el desarrollo local, el método sdk, DefaultAzureCredential(), busque en las variables de entorno de una entidad de servicio de aplicación o en VS Code, la CLI de Azure o Azure PowerShell para un conjunto de credenciales de desarrollador, cualquiera de las cuales se puede usar para autenticar la aplicación en los recursos de Azure durante el desarrollo local. De este modo, este mismo código se puede usar para autenticar la aplicación en los recursos de Azure durante el desarrollo local y cuando se implementa en Azure.