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

Microsoft Entra ID avec Azure Key Vault fournit un moyen complet et pratique pour les applications de s’authentifier auprès des services Azure et des services tiers où les clés d’accès sont impliquées.

Après avoir fourni des informations générales, cette procédure pas à pas décrit ces fonctionnalités d’authentification dans le contexte de l’exemple, github.com/Azure-Samples/python-integrated-authentication.

Partie 1 : Arrière-plan

Bien que de nombreux services Azure reposent uniquement sur le contrôle d’accès en fonction du rôle pour l’autorisation, certains services contrôlent l’accès à leurs ressources respectives à l’aide de secrets ou de clés. Ces services incluent Stockage Azure, les bases de données, les services Azure AI, Key Vault et Event Hubs.

Lorsque vous créez une application cloud qui accède à ces services, vous pouvez utiliser les Portail Azure, Azure CLI ou Azure PowerShell pour créer et configurer des clés pour votre application. Les clés que vous créez sont liées à des stratégies d’accès spécifiques et empêchent l’accès à ces ressources spécifiques à l’application par tout autre code non autorisé.

Dans cette conception générale, les applications cloud doivent généralement gérer ces clés et s’authentifier avec chaque service individuellement, un processus qui peut être à la fois fastidieux et sujet aux erreurs. La gestion des clés directement dans le code de l’application risque également d’exposer ces clés dans le contrôle de code source et les clés peuvent être stockées sur des stations de travail de développeur non sécurisées.

Heureusement, Azure fournit deux services spécifiques pour simplifier le processus et renforcer la sécurité :

• Azure Key Vault fournit un stockage sécurisé basé sur le cloud pour les clés d’accès (ainsi que les clés de chiffrement et les certificats, qui ne sont pas abordés dans cet article). En utilisant Key Vault, l’application accède à ces clés uniquement au moment de l’exécution de sorte qu’elles n’apparaissent jamais directement dans le code source.

• Avec les identités managées Microsoft Entra, une application doit s’authentifier une seule fois avec l’ID Microsoft Entra. L’application est ensuite automatiquement authentifiée auprès d’autres services Azure, dont Key Vault. Par conséquent, votre code ne doit jamais se préoccuper de clés ou d’autres informations d’identification pour ces services Azure. Mieux encore, vous pouvez exécuter le même code localement et dans le cloud avec des exigences de configuration minimales.

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.

Important

Cet article utilise le terme générique « clé » commun pour faire référence à ce qui est stocké en tant que « secrets » dans Azure Key Vault, comme 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 de façon plus approfondie le processus d’authentification d’Azure, envisagez le scénario suivant :

• Une application principale expose un point de terminaison d’API public (non authentifié) qui répond aux requêtes HTTP avec des données JSON. L’exemple de point de terminaison, comme indiqué dans cet article, est implémenté en tant qu’application Flask simple déployée sur Azure App Service.

• Pour générer sa réponse, l’API appelle une API tierce qui requiert une clé d’accès. L’application récupère cette clé d’accès auprès d’Azure Key Vault au moment de l’exécution.

• Avant que l’API retourne une réponse, elle écrit un message dans une file d’attente Stockage Azure pour un traitement ultérieur. (Le traitement spécifique de ces messages n’est pas pertinent pour le scénario principal.)

Remarque

Bien qu’un point de terminaison d’API public soit généralement protégé par sa propre clé d’accès, dans le cadre de cet article, nous partons du principe que le point de terminaison est ouvert et non authentifié. Cette hypothèse évite toute confusion entre les besoins d’authentification de l’application et ceux d’un appelant externe de ce point de terminaison. Ce scénario n’illustre pas un tel appelant externe.

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