Authentifier les applications Python auprès des services Azure en utilisant le SDK Azure pour Python
Lorsqu’une application doit accéder à une ressource Azure comme Azure Storage, Azure Key Vault ou des services Azure AI, elle doit être authentifiée auprès d’Azure. Cette exigence est valable pour toutes les applications, qu’elles soient déployées sur Azure, déployées sur site ou en cours de développement sur une station de travail locale pour développeurs. Cet article décrit les approches recommandées pour authentifier une application auprès d'Azure lorsque vous utilisez le SDK Azure pour Python.
Approche d’authentification d’application recommandée
Utilisez l’authentification basée sur des jetons plutôt que des chaînes de connexion pour vos applications lorsqu’elles s’authentifient auprès des ressources Azure. La bibliothèque cliente Azure Identity pour Python fournit des classes qui prennent en charge l’authentification basée sur les tokens et permettent aux applications de s’authentifier de manière transparente aux ressources Azure, que l’application soit en développement local, déployée sur Azure ou déployée sur un serveur sur site.
Le type spécifique d’authentification basée sur des jetons qu’une application utilise pour s’authentifier auprès des ressources Azure dépend de l’emplacement où l’application est exécutée. Les types d’authentification basée sur des 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 abordées dans la section Authentification lors du 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 abordée dans la section Authentification dans les environnements serveurs.
- Lorsqu’une application est hébergée et déployée en local : l’application s’authentifie auprès des ressources Azure à l’aide d’un principal de service d’application. Cette option est abordée dans la section Authentification dans les environnements serveurs.
DefaultAzureCredential
La classe DefaultAzureCredential fournie par la bibliothèque cliente Azure Identity 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 manière, les applications peuvent passer du développement local aux environnements de test et à 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 de DefaultAzureCredential est préférable au codage manuel de la logique conditionnelle ou des indicateurs de fonctionnalité pour utiliser différentes méthodes d’authentification dans différents environnements.
Les détails de l'utilisation de la classe DefaultAzureCredential sont abordés dans la section Utiliser DefaultAzureCredential dans une application.
Avantages de l’authentification par jeton
Utilisez l’authentification basée sur des jetons plutôt que des chaînes de connexion lorsque vous créez des applications pour Azure. L’authentification basée sur des jetons offre les avantages suivants par rapport aux chaînes de connexion :
- Les méthodes d’authentification basées sur des jetons décrites dans cet article vous permettent d’établir les autorisations spécifiques requises 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 toute application disposant d'une chaîne de connexion peut se connecter à une ressource Azure, alors que les méthodes d'authentification basées sur des jetons limitent l'accès aux seules applications censées y accéder.
- Avec une identité managée, il n’y a pas de secret d’application à stocker. L’application est davantage sécurisée car il n’y a pas de risque de compromission de la chaîne de connexion ou du secret de l'application.
- Le package azure-identity acquiert et gère pour vous les tokens Microsoft Entra. Cela rend l’utilisation de l’authentification basée sur les tokens aussi simple que l’utilisation d’une chaîne de connexion.
Limitez l’utilisation des chaînes 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 aux données sensibles. Sinon, les classes d’authentification basées sur les tokens disponibles dans la bibliothèque cliente Azure Identity sont toujours préférées lorsqu’elles authentifient des ressources Azure.
Authentification dans les environnements serveur
Lorsque vous hébergez dans un environnement serveur, chaque application se voit attribuer une identité d’application unique par environnement où l’application est exécutée. 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 où votre application est exécutée :
| 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 ne peuvent être utilisées qu’avec des applications hébergées par Azure. Par exemple, une application Web Django hébergée dans Azure App Service se verrait attribuer une identité géré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 des identités 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. , |
| 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 sur place qui fait appel à Azure Blob Storage. Vous devez créer un principal de service d’application pour l’application à l’aide du processus d’inscription des applications. AZURE_CLIENT_ID, AZURE_TENANT_ID et AZURE_CLIENT_SECRET seront stockés en tant que variables d'environnement qui seront lues par l'application au moment de l'exécution et qui permettront à l'application de s'authentifier auprès d'Azure en utilisant le principal du service d'application. |
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 de tous les services Azure utilisés par l’application. Il existe deux stratégies principales pour authentifier les applications auprès d’Azure pendant le développement local :
| Méthode d'authentification | Description |
|---|---|
| Créez des objets de principal de service d’application dédiés à utiliser pendant le développement local. | Dans cette méthode, les objets de principal de service d’application dédiés sont configurés à l’aide du processus d’inscription des applications pour une utilisation 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 permet de s'assurer que l'application n'a accès qu'aux ressources spécifiques dont elle a besoin et de répliquer les autorisations dont l'application disposera en production. L’inconvénient de cette approche est qu'il faut impérativement créer des objets de principal de service distincts pour chaque développeur qui travaille sur une application. |
| Authentifiez l'application auprès d'Azure en utilisant les informations d'identification du développeur pendant le développement local. | Dans cette méthode, un développeur doit être connecté à Azure depuis la CLI Azure, Azure PowerShell ou la CLI Azure Developer sur son poste de travail local. 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 d’être plus facile à configurer, car il suffit au développeur de se connecter à son compte Azure via l’un des outils de développement susmentionnés. 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. |
Utiliser DefaultAzureCredential dans une application
DefaultAzureCredential est une séquence ordonnée et fondée d’authentification auprès de Microsoft Entra ID. Chaque mécanisme d’authentification est une classe qui implémente le protocole TokenCredential et est connu sous le nom de identifiant. Au moment de l’exécution, DefaultAzureCredential tente de s’authentifier en utilisant les premières informations d’identification. Si ces informations d’identification ne parviennent pas à acquérir un jeton d’accès, les informations d’identification suivantes de la séquence sont utilisées, et ainsi de suite jusqu’à l’obtention d’un jeton d’accès. De cette façon, votre application peut utiliser différentes informations d’identification dans différents environnements sans qu’il soit nécessaire d’écrire du code propre à l’environnement.
Pour utiliser DefaultAzureCredential dans une application Python, ajoutez le package azure-identity à votre application.
pip install azure-identity
Les services Azure sont accessibles à l’aide de classes clientes spécialisées à partir des différentes bibliothèques de client du Kit de développement logiciel (SDK) Azure. L'exemple de code suivant montre comment instancier un objet DefaultAzureCredential et l'utiliser avec une classe client Azure SDK. Dans ce cas, il s'agit d'un objet BlobServiceClient utilisé pour accéder à Azure Blob Storage.
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)
Lorsque le code ci-dessus s’exécute sur votre station de travail de développement local, il recherche dans les variables d’environnement un principal de service d’application ou dans les outils de développement installés localement, tels que Azure CLI, un ensemble d’identifiants de développeur. Vous pouvez utiliser l’une ou l’autre de ces approches 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 des ressources Azure. DefaultAzureCredential peut récupérer automatiquement les paramètres d’environnement et les configurations d’identité gérée pour s’authentifier auprès des services Azure.