Authentification d’applications hébergées par Azure auprès de ressources Azure avec le Kit de développement logiciel (SDK) Azure pour .NET
Lorsqu’une application est hébergée dans Azure à l’aide d’un service comme Azure App Service, Machines virtuelles Microsoft Azure 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 qu’elle puisse se connecter à d’autres ressources Azure sans avoir à utiliser une clé secrète ou un autre secret d’application. 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 les secrets d’application.
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 : ce type d’identité managée est fourni par et lié 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. Une identité managée affectée par le système est liée au cycle de vie de la ressource Azure à laquelle elle est associée. 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 : vous pouvez également créer une identité managée en tant que 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 App Service et de machines virtuelles qui devaient toutes 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 serait logique.
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.
1 - Activer l’identité managée dans la ressource Azure hébergeant l’application
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 .NET à l’aide d’Azure App Service, vous devez activer l’identité managée pour l’application web App Service qui héberge votre application. 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
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.
L’ordre et les emplacements dans lesquels DefaultAzureCredential
recherchent les informations d’identification se trouvent dans DefaultAzureCredential.
Pour implémenter DefaultAzureCredential
, ajoutez d’abord les packages Azure.Identity
et éventuellement Microsoft.Extensions.Azure
à votre application. Pour ce faire, utilisez la ligne de commande ou le Gestionnaire de package NuGet.
Ouvrez un environnement de terminal de votre choix dans le répertoire du projet d’application et entrez la commande ci-dessous.
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure
Les services Azure sont généralement accessibles à l’aide des classes clientes correspondantes à partir du SDK. Ces classes et vos propres services personnalisés doivent être inscrits dans le fichier Program.cs
afin qu’ils soient accessibles via l’injection de dépendances dans votre application. À l’intérieur de Program.cs
, suivez les étapes ci-dessous pour configurer correctement votre service et DefaultAzureCredential
.
- Incluez les espaces de noms
Azure.Identity
etMicrosoft.Extensions.Azure
avec une instruction using. - Inscrivez le service Azure à l’aide des méthodes d’assistance appropriées.
- Passez une instance de l’objet
DefaultAzureCredential
à la méthodeUseCredential
.
Un exemple de cela est illustré dans le segment de code suivant.
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());
});
Vous pouvez également utiliser plus directement DefaultAzureCredential
dans vos services sans l’aide de méthodes d’inscription Azure supplémentaires, comme indiqué ci-dessous.
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()));
Lorsque le code ci-dessus est exécuté sur votre station de travail locale pendant le développement local, il recherche dans les variables d’environnement un principal de service d’application ou dans Visual Studio, VS Code, Azure CLI ou Azure PowerShell un ensemble d’informations d’identification de développeur, qui peuvent être utilisées pour authentifier l’application auprès des ressources Azure pendant le développement local.
Lorsqu’il est déployé sur Azure, ce même code peut également authentifier votre application auprès d’autres ressources Azure. DefaultAzureCredential
peut récupérer les paramètres d’environnement et les configurations d’identité managée pour s’authentifier automatiquement auprès d’autres services.
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour