Authentifier les applications Python aux services Azure à l’aide de la bibliothèque Azure Identity

Les applications peuvent utiliser la bibliothèque d’identités Azure pour s’authentifier auprès de Microsoft Entra ID, ce qui permet aux applications d’accéder aux services et ressources Azure. Cette exigence d’authentification s’applique si l’application est déployée sur Azure, hébergée localement ou exécutée localement sur une station de travail de développeur. Les sections qui suivent décrivent les approches recommandées pour authentifier une application pour Microsoft Entra ID dans différents environnements lors de l’utilisation des bibliothèques clientes Azure SDK.

Approche recommandée pour l’authentification des applications

L’authentification basée sur les jetons via Microsoft Entra ID est l’approche recommandée pour l’authentification des applications à Azure, au lieu d’utiliser des chaînes de connexion ou des options basées sur des clés. La bibliothèque d’identités Azure fournit des classes qui prennent en charge l’authentification basée sur des jetons et permettent aux applications de s’authentifier auprès de Azure ressources que l’application s’exécute localement, sur Azure ou sur un serveur local.

Avantages de l’authentification par jeton

L’authentification basée sur des jetons offre les avantages suivants par rapport aux chaînes de connexion :

• L’authentification basée sur un jeton garantit que seules les applications spécifiques destinées à accéder à la ressource Azure sont en mesure de le faire, tandis que toute personne ou n’importe quelle application disposant d’un connection string peut se connecter à une ressource Azure.
• L’authentification basée sur les jetons vous permet de limiter davantage l’accès aux ressources Azure aux autorisations spécifiques requises par l’application. Cette approche suit le principe du moindre privilège. En revanche, une connection string accorde des droits complets à la ressource Azure.
• Lorsque vous utilisez une identité managed identity pour l'authentification basée sur les jetons, Azure gère les fonctions d'administration pour vous. Vous n'avez donc pas à vous soucier des tâches telles que la sécurisation ou la rotation des secrets. Cela rend l'application plus sécurisée, car il n'existe aucun connection string ou secret d'application qui peut être compromis.
• La bibliothèque d’identités Azure acquiert et gère les jetons Microsoft Entra pour vous.

L’utilisation de chaînes de connexion doit être limitée aux scénarios où l’authentification basée sur des jetons n’est pas une option, des applications de preuve de concept initiales ou des prototypes de développement qui n’accèdent pas à la production ou aux données sensibles. Si possible, utilisez les classes d’authentification basées sur des jetons disponibles dans la bibliothèque d’identités Azure pour s’authentifier auprès de Azure ressources.

Authentification dans différents environnements

Le type spécifique d’authentification basée sur les jetons qu’une application doit utiliser pour s’authentifier auprès de Azure ressources dépend de l’emplacement d’exécution de l’application. Le diagramme suivant fournit des conseils pour différents scénarios et environnements :

Lorsqu'une application est :

• Hosted sur Azure : l’application doit s’authentifier aux ressources Azure à l’aide d’une identité gérée. Cette option est décrite plus en détail dans l’authentification dans les environnements serveur.
• Exécution localement pendant le développement : l'application peut s'authentifier auprès d'Azure à l'aide d'un compte développeur, d'un intermédiaire (broker) ou d'un principal de service. Chaque option est discutée plus en détail lors de l'authentification au cours du développement local.
• Hébergé sur site : l’application doit s’authentifier auprès des ressources Azure à l’aide d’un principal de service d’application ou d’une identité managée dans le cadre de Azure Arc. Les flux de travail sur site sont abordés plus en détail dans Authentification pour les applications hébergées sur site.

Authentification pour les applications hébergées par Azure

Lorsque votre application est hébergée sur Azure, elle peut utiliser des identités managées pour s’authentifier auprès de Azure ressources sans avoir à gérer les informations d’identification. Il existe deux types d’identités managées : attribuées par l’utilisateur et affectées par le système.

Utiliser une identité managée attribuée par l'utilisateur

Une identité managée affectée par l’utilisateur est créée en tant que ressource Azure autonome. Il peut être affecté à une ou plusieurs ressources Azure, ce qui permet à ces ressources de partager la même identité et les mêmes autorisations. Pour vous authentifier à l’aide d’une identité managée affectée par l’utilisateur, créez-la, affectez-la à votre ressource Azure, puis configurez votre application pour utiliser cette identité pour l’authentification en spécifiant son ID client, son ID de ressource ou son ID d’objet.

Utiliser une identité managée affectée par le système

Une identité managée affectée par le système est activée directement sur une ressource Azure. L’identité est liée au cycle de vie de cette ressource et est automatiquement supprimée lorsque la ressource est supprimée. Pour vous authentifier à l’aide d’une identité managée affectée par le système, activez l’identité sur votre ressource de Azure, puis configurez votre application pour utiliser cette identité pour l’authentification.

Authentification pendant le développement local

Pendant le développement local, vous pouvez vous authentifier auprès de Azure ressources à l’aide de vos informations d’identification de développeur ou d’un principal de service. Cela vous permet de tester la logique d'authentification de votre application sans la déployer sur Azure.

Utiliser les informations d’identification du développeur

Vous pouvez utiliser vos propres informations d’identification Azure pour vous authentifier auprès de Azure ressources pendant le développement local. Cela est généralement effectué à l’aide d’un outil de développement, tel que Azure CLI ou Visual Studio Code, qui peut fournir à votre application les jetons nécessaires pour accéder aux services Azure. Cette méthode est pratique, mais ne doit être utilisée qu’à des fins de développement.

Utiliser un répartiteur

L’authentification répartie collecte les informations d’identification de l’utilisateur à l’aide du répartiteur d’authentification système pour authentifier une application. Un courtier d’authentification système s’exécute sur l’ordinateur d’un utilisateur et gère les échanges d’authentification et la maintenance des jetons pour tous les comptes connectés.

Utiliser un principal de service

Un principal de service est créé dans une instance Microsoft Entra pour représenter une application et être utilisé pour s'authentifier auprès des ressources Azure. Vous pouvez configurer votre application pour utiliser les informations d’identification du principal de service pendant le développement local. Cette méthode est plus sécurisée que l’utilisation des informations d’identification du développeur et est plus proche de la façon dont votre application s’authentifie en production. Toutefois, il est toujours moins idéal que d’utiliser une identité managée en raison de la nécessité de secrets.

Authentification pour les applications hébergées localement

Pour les applications hébergées localement, vous pouvez utiliser un principal de service pour vous authentifier auprès de Azure ressources. Cela implique la création d’un principal de service dans Microsoft Entra ID, l’affectation des autorisations nécessaires et la configuration de votre application pour utiliser ses informations d’identification. Cette méthode permet à votre application locale d’accéder en toute sécurité aux services Azure.