Authentifier des applications Python auprès des services Azure à l’aide du Kit de développement logiciel (SDK) Azure pour Python

Lorsqu’une application doit accéder à une ressource Azure comme Stockage Azure, Azure Key Vault ou les services Azure AI, l’application doit être authentifiée auprès d’Azure. Cette exigence est vraie pour toutes les applications, qu’elles soient déployées sur Azure, déployées localement ou en cours de développement sur une station de travail de développeur locale. Cet article décrit les approches recommandées pour authentifier une application auprès d’Azure lorsque vous utilisez le Kit de développement logiciel (SDK) Azure pour Python.

Approche d’authentification d’application recommandée

Utilisez l’authentification basée sur des jetons plutôt que des chaîne de connexion pour vos applications lorsqu’elles s’authentifient auprès des ressources Azure. Le Kit de développement logiciel (SDK) Azure pour Python fournit des classes qui prennent en charge l’authentification basée sur des jetons. Les applications peuvent s’authentifier en toute transparence auprès des ressources Azure, que l’application soit en développement local, déployée sur Azure ou déployée sur un serveur local.

Le type spécifique d’authentification basée sur les jetons qu’une application utilise pour s’authentifier auprès des ressources Azure dépend de l’emplacement d’exécution de l’application. Les types d’authentification basée sur les jetons sont présentés dans le diagramme suivant.

• Lorsqu’un développeur exécute une application pendant le développement local : l’application s’authentifie auprès d’Azure à l’aide d’un principal de service d’application pour le développement local ou des informations d’identification Azure du développeur. Ces options sont décrites dans la section Authentification pendant le développement local.
• Lorsqu’une application est hébergée sur Azure : l’application s’authentifie auprès des ressources Azure à l’aide d’une identité managée. Cette option est décrite dans la section Authentification dans les environnements serveur.
• Lorsqu’une application est hébergée et déployée localement : l’application s’authentifie auprès des ressources Azure à l’aide d’un principal de service d’application. Cette option est décrite dans la section Authentification dans les environnements serveur.

DefaultAzureCredential

La classe DefaultAzureCredential fournie par le Kit de développement logiciel (SDK) Azure permet aux applications d’utiliser différentes méthodes d’authentification en fonction de l’environnement dans lequel elles sont exécutées. De cette façon, les applications peuvent être promues du développement local aux environnements de test vers la production sans modification du code.

Vous configurez la méthode d’authentification appropriée pour chaque environnement et DefaultAzureCredential détecte et utilise automatiquement cette méthode d’authentification. L’utilisation d’une logique conditionnelle ou d’indicateurs de fonctionnalités de codage manuel est préférable à l’utilisation de DefaultAzureCredential différentes méthodes d’authentification dans différents environnements.

Vous trouverez plus d’informations sur l’utilisation de la DefaultAzureCredential classe dans la section Utiliser DefaultAzureCredential dans une application.

Avantages de l’authentification par jeton

Utilisez l’authentification basée sur des jetons au lieu d’utiliser des chaîne de connexion lorsque vous créez des applications pour Azure. L’authentification basée sur les jetons offre les avantages suivants par rapport à l’authentification avec des chaîne de connexion s :

• Les méthodes d’authentification basées sur les jetons décrites dans cet article vous permettent d’établir les autorisations spécifiques nécessaires par l’application sur la ressource Azure. Cette pratique suit le principe du privilège minimum. En revanche, une chaîne de connexion accorde des droits complets à la ressource Azure.
• Toute personne ou n’importe quelle application disposant d’un chaîne de connexion peut se connecter à une ressource Azure, mais les méthodes d’authentification basées sur des jetons permettent d’accéder à la ressource uniquement aux applications destinées à accéder à la ressource.
• Avec une identité managée, il n’existe aucun secret d’application à stocker. L’application est plus sécurisée, car il n’existe aucun chaîne de connexion ou secret d’application qui peut être compromis.
• Le package azure.identity dans le SDK Azure gère les jetons pour vous en arrière-plan. Les jetons managés facilitent l’utilisation de l’authentification basée sur les jetons comme chaîne de connexion.

Limitez l’utilisation des chaîne de connexion aux applications de preuve de concept initiales ou aux prototypes de développement qui n’accèdent pas aux données de production ou sensibles. Dans le cas contraire, les classes d’authentification basées sur les jetons disponibles dans le Kit de développement logiciel (SDK) Azure sont toujours préférées lorsqu’elles s’authentifient auprès des ressources Azure.

Authentification dans les environnements serveur

Lorsque vous hébergez dans un environnement serveur, chaque application reçoit une identité d’application unique par environnement où l’application s’exécute. Dans Azure, une identité d’application est représentée par un principal de service. Ce type spécial de principal de sécurité identifie et authentifie les applications auprès d’Azure. Le type de principal de service à utiliser pour votre application dépend de l’emplacement d’exécution de votre application :

Méthode d'authentification	Description
Applications hébergées dans Azure	Les applications hébergées dans Azure doivent utiliser un principal de service d’identité managée. Les identités managées sont conçues pour représenter l’identité d’une application hébergée dans Azure et peuvent uniquement être utilisées avec des applications hébergées par Azure. Par exemple, une application web Django hébergée dans Azure App Service se voit attribuer une identité managée. L’identité managée affectée à l’application sera ensuite utilisée pour authentifier l’application auprès d’autres services Azure. Les applications s’exécutant dans Azure Kubernetes Service (AKS) peuvent utiliser des informations d’identification d’identité de charge de travail. Ces informations d’identification sont basées sur une identité managée qui a une relation d’approbation avec un compte de service AKS. , En savoir plus sur l’authentification à partir d’applications hébergées sur Azure
Applications hébergées en dehors d’Azure (par exemple, applications locales)	Les applications hébergées en dehors d’Azure (par exemple, les applications locales) qui doivent se connecter aux services Azure doivent utiliser un principal de service d’application. Un principal de service d’application représente l’identité de l’application dans Azure, et il est créé par le biais du processus d’inscription de l’application. Par exemple, considérez une application web Django hébergée localement qui utilise Stockage Blob Azure. Vous créez un principal de service d’application pour l’application à l’aide du processus d’inscription de l’application. Le AZURE_CLIENT_ID, AZURE_TENANT_IDet AZURE_CLIENT_SECRET est stocké en tant que variables d’environnement à lire par l’application au moment de l’exécution et autoriser l’application à s’authentifier auprès d’Azure à l’aide du principal du service d’application. En savoir plus sur l’authentification à partir d’applications hébergées en dehors d’Azure

Authentification pendant le développement local

Lorsqu’une application s’exécute sur la station de travail d’un développeur pendant le développement local, elle doit toujours s’authentifier auprès des services Azure utilisés par l’application. Il existe deux stratégies principales pour l’authentification des applications auprès d’Azure lors du développement local :

Méthode d'authentification	Description
Créez des objets principaux de service d’application dédiés à utiliser pendant le développement local.	Dans cette méthode, les objets principaux du service d’application dédiés sont configurés à l’aide du processus d’inscription d’application à utiliser pendant le développement local. L’identité du principal de service est ensuite stockée en tant que variable d’environnement à laquelle l’application accède lorsqu’elle est exécutée dans le développement local. Cette méthode vous permet d’affecter les autorisations de ressources nécessaires à l’application aux objets de principal de service qui sont utilisés par les développeurs pendant le développement local. Cette pratique garantit que l’application a uniquement accès aux ressources spécifiques dont elle a besoin et réplique les autorisations que l’application aura en production. L’inconvénient de cette approche est la nécessité de créer des objets de principal de service distincts pour chaque développeur qui travaille sur une application. En savoir plus sur l’authentification à l’aide de principaux de service de développement
Authentifiez l’application auprès d’Azure à l’aide des informations d’identification du développeur pendant le développement local.	Dans cette méthode, un développeur doit être connecté à Azure à partir d’Azure CLI, d’Azure PowerShell ou d’Azure Developer CLI sur leur station de travail locale. L’application peut ensuite accéder aux informations d’identification du développeur à partir du magasin d’informations d’identification et utiliser celles-ci pour accéder aux ressources Azure. Cette méthode présente l’avantage de faciliter la configuration, car un développeur doit uniquement se connecter à son compte Azure via l’un des outils de développement mentionnés ci-dessus. L’inconvénient de cette approche est que le compte du développeur dispose probablement de plus d’autorisations que n’en nécessite l’application. L’application ne réplique donc pas avec précision les autorisations avec lesquelles elle va s’exécuter en production. En savoir plus sur l’authentification à l’aide de comptes de développeur

Utiliser DefaultAzureCredential dans une application

Pour utiliser DefaultAzureCredential dans une application Python, ajoutez le package azure.identity à votre application.

pip install azure-identity

L’exemple de code suivant montre comment instancier un DefaultAzureCredential objet et l’utiliser avec une classe cliente du Kit de développement logiciel (SDK) Azure. Dans ce cas, il s’agit d’un BlobServiceClient objet utilisé pour accéder à Stockage Blob Azure.

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

# Acquire a credential object
credential = DefaultAzureCredential()

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

L’objet DefaultAzureCredential détecte automatiquement le mécanisme d’authentification configuré pour l’application et obtient les jetons nécessaires pour authentifier l’application auprès d’Azure. Si une application utilise plusieurs clients sdk, vous pouvez utiliser le même objet d’informations d’identification avec chaque objet client sdk.

Séquence de méthodes d’authentification lorsque vous utilisez DefaultAzureCredential

En interne, DefaultAzureCredential implémente une chaîne de fournisseurs d’informations d’identification pour l’authentification des applications auprès des ressources Azure. Chaque fournisseur d’informations d’identification peut détecter si les informations d’identification de ce type sont configurées pour l’application. L’objet DefaultAzureCredential case activée séquentiellement chaque fournisseur dans l’ordre et utilise les informations d’identification du premier fournisseur qui a configuré les informations d’identification.

L’ordre dans lequel DefaultAzureCredential recherche les informations d’identification s’affiche dans le diagramme et le tableau suivants :

Type d'informations d'identification	Description
Environnement	L’objet DefaultAzureCredential lit un ensemble de variables d’environnement pour déterminer si un principal de service d’application (utilisateur d’application) a été défini pour l’application. Si c’est le cas, DefaultAzureCredential utilise ces valeurs pour authentifier l’application auprès d’Azure. Cette méthode est la plus souvent utilisée dans les environnements serveur, mais vous pouvez également l’utiliser lorsque vous développez localement.
Identité de la charge de travail	Si l’application est déployée sur Azure Kubernetes Service (AKS) avec une identité managée activée, DefaultAzureCredential authentifie l’application auprès d’Azure à l’aide de cette identité managée. L’identité de charge de travail représente une relation d’approbation entre une identité managée affectée par l’utilisateur et un compte de service AKS. L’authentification à l’aide d’une identité de charge de travail est abordée dans l’article AKS Utiliser ID de charge de travail Microsoft Entra avec Azure Kubernetes Service.
Identité gérée	Si l’application est déployée sur un hôte Azure avec une identité managée activée, DefaultAzureCredential authentifie l’application auprès d’Azure à l’aide de cette identité managée. L’authentification à l’aide d’une identité managée est décrite dans la section Authentification dans les environnements serveur. Cette méthode est disponible uniquement lorsqu’une application est hébergée dans Azure à l’aide d’un service tel qu’Azure App Service, Azure Functions ou Azure Machines Virtuelles.
Azure CLI	Si vous vous êtes authentifié auprès d’Azure à l’aide de la az login commande dans Azure CLI, DefaultAzureCredential authentifie l’application auprès d’Azure à l’aide de ce même compte.
Azure PowerShell	Si vous vous êtes authentifié auprès d’Azure à l’aide de l’applet Connect-AzAccount de commande à partir d’Azure PowerShell, DefaultAzureCredential authentifie l’application auprès d’Azure à l’aide de ce même compte.
Azure Developer CLI	Si vous vous êtes authentifié auprès d’Azure à l’aide de la azd auth login commande dans Azure Developer CLI, DefaultAzureCredential authentifie l’application auprès d’Azure à l’aide de ce même compte.
Interactive	Si cette option est activée, DefaultAzureCredential vous authentifie de manière interactive via le navigateur par défaut du système actuel. Par défaut, cette option est désactivée.

Remarque

En raison d’un problème connu, VisualStudioCodeCredential a été supprimé de la DefaultAzureCredential chaîne de jetons. Lorsque le problème est résolu dans une version ultérieure, cette modification sera rétablie. Pour plus d’informations, consultez la bibliothèque de client Azure Identity pour Python.