Partager via


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

Lorsque vous hébergez une application dans Azure à l'aide de services tels que Azure App Service, Azure Virtual Machines ou Azure Container Instances, l'approche recommandée pour authentifier une application auprès des ressources Azure est l'identité géré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.

Remarque

Les applications exécutées sur Azure Kubernetes Service (AKS) peuvent utiliser une identité de charge de travail pour s'authentifier auprès des ressources Azure. Dans AKS, une identité de charge de travail représente une relation de confiance entre une identité gérée et un compte de service Kubernetes. Si une application déployée sur AKS est configurée avec un compte de service Kubernetes dans une telle relation, DefaultAzureCredential authentifie l’application auprès d’Azure à l’aide de l’identité managée. L’authentification à l’aide d’une identité de charge de travail est abordée dans la section Utiliser Microsoft Entra Workload ID avec Azure Kubernetes Service. Pour connaître les étapes de la configuration de l'identité de la charge de travail, voir Déployer et configurer l'identité de la charge de travail sur un cluster Azure Kubernetes Service (AKS).

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é. Puisque tout ce que vous avez à faire est d'activer l'identité gérée pour la ressource Azure hébergeant votre code, cette approche est le type d'identité gérée le plus facile à utiliser.
  • Identités gérées attribuées par l'utilisateur - Vous pouvez également créer une identité gérée en tant que ressource Azure autonome. Cette approche est le plus souvent utilisée lorsque votre solution comporte plusieurs charges de travail qui s'exécutent sur plusieurs ressources Azure et qui doivent toutes partager la même identité et les mêmes permissions. Par exemple, si votre solution a des composants qui s'exécutent sur plusieurs instances d'App Service et de machines virtuelles qui ont toutes besoin d'accéder au même ensemble de ressources Azure, alors une identité gérée attribuée à l'utilisateur utilisée sur l'ensemble de ces ressources a du sens.

Cet article couvre les étapes pour activer et utiliser une identité gérée attribué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é gérée pour l'application Web App Service qui héberge votre application. Si vous utilisez une machine virtuelle pour héberger votre application, vous devez activer l'identité gérée pour votre machine virtuelle.

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": "aaaaaaaa-bbbb-cccc-1111-222222222222",
  "tenantId": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "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 au niveau 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 l'assigné, utilisez le principalId que vous avez copié à l'étape 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é gérée avec l'ID de aaaaaaaa-bbbb-cccc-1111-222222222222 à accéder en lecture, écriture et suppression aux conteneurs et données blob d'Azure Storage dans tous les comptes de stockage du groupe de ressources msdocs-python-sdk-auth-example dans l'abonnement avec l'ID aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e, vous affecteriez le principal de service d'application au rôle Contributeur de données blob de stockage à l'aide de la commande suivante.

az role assignment create --assignee aaaaaaaa-bbbb-cccc-1111-222222222222 \
    --scope /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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 est exécuté dans Azure et que l'identité gérée a été activée sur la ressource Azure hébergeant votre application, le DefaultAzureCredential détermine les informations d'identification à utiliser dans l'ordre suivant :

  1. Vérifier l'environnement pour un principal de service tel que défini par les variables d'environnement AZURE_CLIENT_ID, AZURE_TENANT_ID, et soit AZURE_CLIENT_SECRET ou AZURE_CLIENT_CERTIFICATE_PATH et (optionnellement) AZURE_CLIENT_CERTIFICATE_PASSWORD.
  2. Vérifiez les paramètres des mots-clés pour une identité gérée attribuée à l'utilisateur. Vous pouvez transmettre une identité gérée attribuée par l'utilisateur en spécifiant son ID client dans le paramètre managed_identity_client_id.
  3. Vérifiez la variable d'environnement AZURE_CLIENT_ID pour l'ID client d'une identité gérée attribuée par l'utilisateur.
  4. Utilisez l'identité gérée attribuée par le système pour la ressource Azure si elle est activée.

Vous pouvez exclure les identités gérées de l'accréditation en définissant le paramètre exclude_managed_identity_credential du mot-clé True.

Dans cet article, nous utilisons l'identité gérée attribuée par le système pour une application Web Azure App Service, nous n'avons donc pas besoin de configurer une identité géré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 package azure.identity à votre application.

pip install azure-identity

Ensuite, pour tout code Python qui crée un objet client Azure SDK dans votre application, vous devrez :

  1. Importez la classe DefaultAzureCredential du module azure.identity.
  2. Créez un objet DefaultAzureCredential.
  3. Transmettez l'objet DefaultAzureCredential au constructeur de l'objet client du SDK Azure.

Un exemple de ces étapes est présenté 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 Azure SDK for Python authentication overview, 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. 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 lors d'un développement local, DefaultAzureCredential utilisera soit un principal de service d'application, déterminé par les paramètres de l'environnement, soit les informations d'identification de l'outil de développement pour s'authentifier auprès d'autres ressources Azure. Ainsi, le même code peut être utilisé pour authentifier votre application auprès des ressources Azure à la fois pendant le développement local et lors du déploiement sur Azure.