Authentification d’applications hébergées par Azure auprès de ressources Azure avec le Kit de développement logiciel (SDK) Azure pour JavaScript
Lorsqu’une application est hébergée dans Azure (à l’aide d’un service tel qu’Azure App Service, Azure Machines Virtuelles ou Azure Container Instances), l’approche recommandée pour authentifier une application auprès des ressources Azure consiste à utiliser une identité managée.
Une identité managée fournit une identité pour votre application afin que votre application se connecte à d’autres ressources Azure sans avoir à utiliser de secret (par exemple, une chaîne de connexion de clé). En interne, Azure connaît l’identité de votre application et les ressources auxquelles elle est autorisée à se connecter. Azure utilise ces informations pour obtenir automatiquement des jetons Microsoft Entra pour que l’application lui permette de se connecter à d’autres ressources Azure, sans avoir à gérer (créer ou faire pivoter) les secrets d’authentification.
Types d’identités managées
Il existe deux types d’identités administrées :
- Identités managées affectées par le système - ressource Azure unique
- Identités managées affectées par l’utilisateur - plusieurs ressources Azure
Cet article décrit les étapes permettant d’activer et d’utiliser une identité managée affectée par le système pour une application. Si vous devez utiliser une identité managée affectée par l’utilisateur, consultez l’article Gérer les identités managées affectées par l’utilisateur pour voir comment créer une identité managée affectée par l’utilisateur.
Identités managées affectées par le système pour une seule ressource
Les identités managées affectées par le système sont fournies et liées directement à une ressource Azure. Lorsque vous activez l’identité managée sur une ressource Azure, vous obtenez une identité managée affectée par le système pour cette ressource. Il est lié au cycle de vie de la ressource Azure. Lorsque la ressource est supprimée, Azure supprime automatiquement l’identité. Étant donné qu’il vous suffit d’activer l’identité managée pour la ressource Azure hébergeant votre code, il s’agit du type d’identité managée le plus simple à utiliser.
Identités managées affectées par l’utilisateur pour plusieurs ressources
Conceptuellement, cette identité est une ressource Azure autonome. Cela est le plus fréquemment utilisé lorsque votre solution a plusieurs charges de travail qui s’exécutent sur plusieurs ressources Azure qui doivent toutes partager la même identité et les mêmes autorisations. Par exemple, si votre solution avait des composants qui s’exécutaient sur plusieurs instances d’App Service et de machines virtuelles et qu’elles avaient tous besoin d’accéder au même ensemble de ressources Azure, la création et l’utilisation d’une identité managée affectée par l’utilisateur sur ces ressources seraient logiques.
1 - Affecté par le système : Activer dans l’application hébergée
La première étape consiste à activer l’identité managée sur la ressource Azure hébergeant votre application. Par exemple, si vous hébergez une application Django à l’aide d’Azure App Service, vous devez activer l’identité managée pour cette application web App Service. Si vous utilisiez une machine virtuelle pour héberger votre application, vous autoriseriez votre machine virtuelle à utiliser une identité managée.
Vous pouvez activer l’identité managée pour une ressource Azure à l’aide du Portail Azure ou d’Azure CLI.
2 - Attribuer des rôles à l’identité managée
Ensuite, vous devez déterminer les rôles (autorisations) dont votre application a besoin et affecter l’identité managée à ces rôles dans Azure. Une identité managée peut se voir attribuer des rôles au niveau d’une ressource, d’un groupe de ressources ou d’une étendue d’abonnement. Cet exemple montre comment attribuer des rôles à l’étendue du groupe de ressources, car la plupart des applications regroupent toutes leurs ressources Azure dans un seul groupe de ressources.
3 - Implémenter DefaultAzureCredential dans votre application
La DefaultAzureCredential
classe détecte automatiquement qu’une identité managée est utilisée et utilise l’identité managée pour s’authentifier auprès d’autres ressources Azure. Comme indiqué dans l’article de présentation de l’authentification JavaScript du Kit de développement logiciel (SDK) Azure pour JavaScript, DefaultAzureCredential
prend en charge plusieurs méthodes d’authentification et détermine la méthode d’authentification utilisée au moment de l’exécution. De cette façon, votre application peut utiliser différentes méthodes d’authentification dans différents environnements sans implémenter de code spécifique à l’environnement.
Tout d’abord, ajoutez le package @azure/identity à votre application.
npm install @azure/identity
Ensuite, pour tout code JavaScript qui crée un objet client azure SDK dans votre application, vous souhaitez :
- Importez la
DefaultAzureCredential
classe à partir du@azure/identity
module. - Créez un objet
DefaultAzureCredential
. - Transmettez l’objet
DefaultAzureCredential
au constructeur d’objet client du Kit de développement logiciel (SDK) Azure.
Un exemple de cela est illustré dans le segment de code suivant.
// 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()
);
Lorsque le code ci-dessus est exécuté sur votre station de travail locale pendant le développement local, la méthode sdk, DefaultAzureCredential(), examinez les variables d’environnement d’un principal de service d’application ou sur VS Code, Azure CLI ou Azure PowerShell pour un ensemble d’informations d’identification de développeur, dont l’une peut être utilisée pour authentifier l’application auprès des ressources Azure pendant le développement local. De cette façon, ce même code peut être utilisé pour authentifier votre application auprès des ressources Azure pendant le développement local et lors du déploiement sur Azure.