Procédure pas à pas : authentification intégrée pour les applications Python avec les services Azure

L’ID Microsoft Entra, lorsqu’il est utilisé avec Azure Key Vault, fournit une approche robuste et sécurisée pour l’authentification d’applications auprès des services Azure et des plateformes tierces qui nécessitent des clés d’accès ou des informations d’identification. Cette combinaison élimine la nécessité de coder en dur les secrets dans le code d’application, en s’appuyant plutôt sur les identités managées, le contrôle d’accès en fonction du rôle (RBAC) et la gestion centralisée des secrets via Key Vault. Cette approche simplifie la gestion des identités et améliore la posture de sécurité dans les environnements cloud.

Cette procédure pas à pas explore ces mécanismes d’authentification par le biais d’un exemple pratique fourni dans le référentiel GitHub : github.com/Azure-Samples/python-integrated-authentication.

L’exemple montre comment une application Python peut :

• S’authentifier auprès d’Azure à l’aide de DefaultAzureCredential

• Accéder aux secrets Azure Key Vault sans stocker les informations d’identification

• Communiquer en toute sécurité avec d’autres services Azure tels que Stockage Azure, Cosmos DB et bien plus encore

Cet article fait partie d'une série qui fournit un guide détaillé sur l'authentification d'une application Python avec Microsoft Entra ID, Azure Key Vault et Azure Queue Storage à l'aide de la bibliothèque Azure Python SDK azure-identity.

Partie 1 : Arrière-plan

Bien que de nombreux services Azure s’appuient exclusivement sur le contrôle d’accès en fonction du rôle (RBAC), tandis que d’autres nécessitent un accès via des secrets ou des clés. Ces services incluent Stockage Azure, bases de données, Outils Foundry, Key Vault et Event Hubs

Lors de la création d’applications cloud qui interagissent avec ces services, les développeurs peuvent utiliser le portail Azure, l’interface CLI ou PowerShell pour générer et configurer des clés d’accès spécifiques au service. Ces clés sont liées à des stratégies d’accès particulières pour empêcher l’accès non autorisé. Toutefois, ce modèle nécessite que votre application gère les clés de manière explicite et s'authentifie séparément avec chaque service, un processus à la fois fastidieux et propice aux erreurs.

Incorporer des secrets directement dans du code ou les stocker sur des machines de développement risque de les exposer dans :

• Gestion des sources
• Environnements locaux non sécurisés
• Exportations accidentelles de journaux ou de configuration

Azure offre deux services clés pour améliorer la sécurité et simplifier l’authentification :

• Azure Key Vault Azure Key Vault fournit un magasin sécurisé basé sur le cloud pour les secrets, notamment les clés d’accès, les chaînes de connexion et les certificats. En récupérant des secrets à partir de Key Vault uniquement lors de l’exécution, les applications évitent d’exposer des données sensibles dans le code source ou les fichiers de configuration.

• Avec les identités managées Microsoft Entra, votre application peut s’authentifier une fois avec l’ID Microsoft Entra. À partir de là, il peut accéder à d’autres services Azure, y compris Key Vault, sans gérer directement les informations d’identification.

Cette approche fournit les éléments suivants :

• Code sans informations d’identification (aucun secret dans le contrôle de code source)
• Intégration transparente avec les services Azure
• Cohérence de l’environnement : le même code s’exécute localement et dans le cloud avec une configuration minimale

Cette procédure pas à pas montre comment utiliser l’identité managée Microsoft Entra et Key Vault ensemble dans la même application. En utilisant l’ID Microsoft Entra et Key Vault ensemble, votre application n’a jamais besoin de s’authentifier auprès de services Azure individuels et peut facilement et en toute sécurité accéder à toutes les clés nécessaires pour les services tiers.

Importante

Cet article utilise le terme commun générique « clé » pour faire référence à ce qui est stocké en tant que « secrets » dans Azure Key Vault, tel qu’une clé d’accès pour une API REST. Cette utilisation ne doit pas être confondue avec la gestion des clés de chiffrement de Key Vault, qui est une fonctionnalité distincte des secrets de Key Vault.

Exemple de scénario d’application cloud

Pour comprendre plus en détail le processus d’authentification d’Azure, envisagez le scénario suivant : une application web Flask est déployée sur Azure App Service. Il expose un point de terminaison d’API public et non authentifié qui retourne des données JSON en réponse aux requêtes HTTP.

• Pour générer sa réponse, l’API appelle une API tierce qui nécessite une clé d’accès. Au lieu de stocker cette clé dans des fichiers de code ou de configuration, l’application la récupère en toute sécurité lors de l’exécution à partir d’Azure Key Vault à l’aide de l’identité managée Microsoft Entra.

• Avant de renvoyer sa réponse au client, l’application écrit un message dans une file d’attente stockage Azure pour un traitement asynchrone. Le message peut représenter une tâche, un journal ou un signal, bien que le traitement en aval ne soit pas le focus de ce scénario.

Remarque

Bien que les points de terminaison d’API publics soient généralement protégés par leurs propres clés d’accès ou mécanismes d’authentification, cette procédure pas à pas suppose que le point de terminaison est ouvert et non authentifié.

Cette simplification permet d’isoler les exigences d’authentification internes de l’application, telles que l’accès à Azure Key Vault et au stockage Azure, des problèmes d’authentification liés aux clients externes.

Le scénario se concentre uniquement sur le comportement de l’application et ne montre pas ou n’implique pas d’authentification d’appelant externe auprès du point de terminaison.

Partie 2 - Configuration requise pour l’authentification >>>