Authentification des applications hébergées dans Azure auprès de ressources Azure avec le Kit de développement logiciel (SDK) Azure pour Python

  • Article

Lorsque vous hébergez une application dans Azure à l’aide de services tels qu’Azure App Service, Azure Machines Virtuelles ou Azure Container Instances, l’approche recommandée pour authentifier une application auprès des ressources Azure est avec 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é que tout ce que vous devez faire est d’activer l’identité managée pour la ressource Azure hébergeant votre code, cette approche est le 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. Cette approche est la plus fréquemment utilisée lorsque votre solution a plusieurs charges de travail qui s’exécutent sur plusieurs ressources Azure qui doivent tous partager la même identité et les mêmes autorisations. Par exemple, si votre solution disposait de composants qui s’exécutent sur plusieurs instances d’App Service et de machines virtuelles qui ont tous besoin d’accéder au même ensemble de ressources Azure, une identité managée affectée par l’utilisateur utilisée sur ces ressources est 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 Django à 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 utilisez une machine virtuelle pour héberger votre application, vous pouvez autoriser votre machine virtuelle à utiliser l’identité managée.

Vous pouvez activer l’identité managée pour une ressource Azure à l’aide du Portail Azure ou d’Azure CLI.

Les commandes Azure CLI peuvent être exécutées dans Azure Cloud Shell ou sur une station de travail dans laquelle l’interface Azure CLI est installée.

Les commandes Azure CLI utilisées pour activer l’identité managée pour une ressource Azure sont de la forme az <command-group> identity --resource-group <resource-group-name> --name <resource-name>. Les commandes spécifiques pour les services Azure populaires sont indiquées ci-dessous.

az webapp identity assign --resource-group <resource-group-name> -name <web-app-name>

La sortie se présente comme suit :

{
  "principalId": "99999999-9999-9999-9999-999999999999",
  "tenantId": "33333333-3333-3333-3333-333333333333",
  "type": "SystemAssigned",
  "userAssignedIdentities": null
}

La valeur principalId est l’ID unique de l’identité managée. Conservez une copie de cette sortie, car vous aurez besoin de ces valeurs à l’étape suivante.

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.

Un rôle est attribué à une identité managée dans Azure à l’aide de la commande az role assignment create. Pour le bénéficiaire, utilisez le fichier que vous avez copié à l’étape principalId 1.

az role assignment create --assignee {managedIdentityprincipalId} \
    --scope /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} \
    --role "{roleName}"

Pour obtenir les noms de rôles auxquels un principal de service peut être affecté, utilisez la commande az role definition list.

az role definition list \
    --query "sort_by([].{roleName:roleName, description:description}, &roleName)" \
    --output table

Par exemple, pour autoriser l’identité managée avec l’ID de 99999999-9999-9999-9999-999999999999 lecture, d’écriture et de suppression de l’accès à Stockage Azure conteneurs d’objets blob et aux données dans tous les comptes de stockage du groupe de ressources msdocs-python-sdk-auth-example dans l’abonnement avec l’ID11111111-1111-1111-1111-111111111111, vous devez affecter le principal du service d’application au rôle contributeur aux données blob Stockage à l’aide de la commande suivante.

az role assignment create --assignee 99999999-9999-9999-9999-999999999999 \
    --scope /subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/msdocs-python-sdk-auth-example \
    --role "Storage Blob Data Contributor"

Pour plus d’informations sur l’attribution d’autorisations au niveau de la ressource ou de l’abonnement à l’aide d’Azure CLI, consultez l’article Attribuer des rôles Azure à l’aide d’Azure CLI.

3 - Implémenter DefaultAzureCredential dans votre application

Lorsque votre code s’exécute dans Azure et l’identité managée a été activé sur la ressource Azure hébergeant votre application, les DefaultAzureCredential informations d’identification à utiliser dans l’ordre suivant :

  1. Vérifiez l’environnement pour un principal de service tel que défini par les variables AZURE_CLIENT_IDd’environnement, AZURE_TENANT_IDet soit AZURE_CLIENT_SECRET ou AZURE_CLIENT_CERTIFICATE_PATH (éventuellement) AZURE_CLIENT_CERTIFICATE_PASSWORD.
  2. Vérifiez mot clé paramètres pour une identité managée affectée par l’utilisateur. Vous pouvez transmettre une identité managée affectée par l’utilisateur en spécifiant son ID client dans le managed_identity_client_id paramètre.
  3. Vérifiez la AZURE_CLIENT_ID variable d’environnement pour l’ID client d’une identité managée affectée par l’utilisateur.
  4. Utilisez l’identité managée affectée par le système pour la ressource Azure si elle est activée.

Vous pouvez exclure les identités managées des informations d’identification en définissant le exclude_managed_identity_credential paramètre Truemot clé .

Dans cet article, nous utilisons l’identité managée affectée par le système pour une application web Azure App Service. Nous n’avons donc pas besoin de configurer une identité managée dans l’environnement ou de la transmettre en tant que paramètre. Les étapes suivantes vous montrent comment utiliser DefaultAzureCredential.

Tout d’abord, ajoutez le azure.identity package à votre application.

pip install azure-identity

Ensuite, pour tout code Python qui crée un objet client du Kit de développement logiciel (SDK) Azure dans votre application, vous devez :

  1. Importez la DefaultAzureCredential classe à partir du azure.identity module.
  2. Créez un objet DefaultAzureCredential.
  3. Transmettez l’objet DefaultAzureCredential au constructeur d’objet client du Kit de développement logiciel (SDK) Azure.

Un exemple de ces étapes est illustré dans le segment de code suivant.

from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

# Acquire a credential object
token_credential = DefaultAzureCredential()

blob_service_client = BlobServiceClient(
        account_url="https://<my_account_name>.blob.core.windows.net",
        credential=token_credential)

Comme indiqué dans l’article de présentation de l’authentification Azure SDK pour Python, DefaultAzureCredential prend en charge plusieurs méthodes d’authentification et détermine la méthode d’authentification utilisée lors de l’exécution. L’avantage de cette approche est que votre application peut utiliser différentes méthodes d’authentification dans différents environnements sans implémenter de code spécifique à l’environnement. Lorsque le code précédent est exécuté sur votre station de travail pendant le développement local, DefaultAzureCredential utilisez un principal de service d’application, tel que déterminé par les paramètres d’environnement ou les informations d’identification de l’outil développeur pour s’authentifier auprès d’autres ressources Azure. Par conséquent, le 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.