Authentifizieren von Python-Apps für Azure-Dienste mithilfe des Azure SDK für Python

Wenn eine Anwendung auf eine Azure-Ressource wie Azure Storage, Azure Key Vault oder Azure AI-Dienste zugreifen muss, muss die Anwendung bei Azure authentifiziert werden. Diese Anforderung gilt für alle Anwendungen, unabhängig davon, ob sie in Azure bereitgestellt, lokal oder in der Entwicklung auf einer lokalen Entwicklerarbeitsstation bereitgestellt werden. In diesem Artikel werden die empfohlenen Ansätze zum Authentifizieren einer App bei Azure beschrieben, wenn Sie das Azure SDK für Python verwenden.

Empfohlener App-Authentifizierungsansatz

Verwenden Sie die tokenbasierte Authentifizierung anstelle von Verbindungszeichenfolge für Ihre Apps, wenn sie sich bei Azure-Ressourcen authentifizieren. Das Azure SDK für Python stellt Klassen bereit, die die tokenbasierte Authentifizierung unterstützen. Apps können sich nahtlos bei Azure-Ressourcen authentifizieren, unabhängig davon, ob sich die App in der lokalen Entwicklung befindet, in Azure bereitgestellt oder auf einem lokalen Server bereitgestellt wird.

Die spezifische Art der tokenbasierten Authentifizierung, die eine App für die Authentifizierung bei Azure-Ressourcen verwendet, hängt davon ab, wo die App ausgeführt wird. Die Typen der tokenbasierten Authentifizierung werden im folgenden Diagramm gezeigt.

• Wenn ein Entwickler während der lokalen Entwicklung eine App ausführt: Die App authentifiziert sich bei Azure, indem sie entweder einen Anwendungsdienstprinzipal für die lokale Entwicklung oder die Azure-Anmeldeinformationen des Entwicklers verwendet. Diese Optionen werden im Abschnitt Authentifizierung während der lokalen Entwicklung erläutert.
• Wenn eine App in Azure gehostet wird: Die App authentifiziert sich mit einer verwalteten Identität bei Azure-Ressourcen. Diese Option wird im Abschnitt "Authentifizierung in Serverumgebungen" erläutert.
• Wenn eine App lokal gehostet und bereitgestellt wird: Die App authentifiziert sich mit einem Anwendungsdienstprinzipal bei Azure-Ressourcen. Diese Option wird im Abschnitt "Authentifizierung in Serverumgebungen" erläutert.

DefaultAzureCredential

Die vom Azure SDK bereitgestellte DefaultAzureCredential-Klasse ermöglicht Apps die Verwendung verschiedener Authentifizierungsmethoden abhängig von der Umgebung, in der sie ausgeführt werden. Auf diese Weise können Apps von der lokalen Entwicklung zu Testumgebungen in die Produktion ohne Codeänderungen heraufgestuft werden.

Sie konfigurieren die entsprechende Authentifizierungsmethode für jede Umgebung und DefaultAzureCredential erkennen und verwenden diese Authentifizierungsmethode automatisch. Die Verwendung wird DefaultAzureCredential bevorzugt, um bedingte Logik oder Featurekennzeichnungen manuell zu codieren, um unterschiedliche Authentifizierungsmethoden in verschiedenen Umgebungen zu verwenden.

Details zur Verwendung der DefaultAzureCredential Klasse werden im Abschnitt "DefaultAzureCredential" in einer Anwendung erläutert.

Vorteile der tokenbasierten Authentifizierung

Verwenden Sie die tokenbasierte Authentifizierung, anstatt Verbindungszeichenfolge zu verwenden, wenn Sie Apps für Azure erstellen. Die tokenbasierte Authentifizierung bietet die folgenden Vorteile gegenüber der Authentifizierung mit Verbindungszeichenfolge s:

• Mit den in diesem Artikel beschriebenen tokenbasierten Authentifizierungsmethoden können Sie die spezifischen Berechtigungen einrichten, die von der App für die Azure-Ressource benötigt werden. Diese Praxis folgt dem Prinzip der geringsten Rechte. Im Gegensatz dazu gewährt eine Verbindungszeichenfolge vollständige Rechte für die Azure-Ressource.
• Jeder oder jede App mit einem Verbindungszeichenfolge kann eine Verbindung mit einer Azure-Ressource herstellen, aber tokenbasierte Authentifizierungsmethoden beschränken den Zugriff auf die Ressource auf die App, die auf die Ressource zugreifen sollen.
• Bei einer verwalteten Identität gibt es keinen geheimen Anwendungsschlüssel zum Speichern. Die App ist sicherer, da keine Verbindungszeichenfolge oder kein geheimer Anwendungsschlüssel vorhanden ist, der kompromittiert werden kann.
• Das azure.identity-Paket im Azure SDK verwaltet Token für Sie im Hintergrund. Verwaltete Token machen die Verwendung der tokenbasierten Authentifizierung so einfach wie eine Verbindungszeichenfolge.

Beschränken Sie die Verwendung von Verbindungszeichenfolge s auf anfängliche Machbarkeits-Apps oder Entwicklungsprototypen, die nicht auf Produktionsdaten oder vertrauliche Daten zugreifen. Andernfalls werden die tokenbasierten Authentifizierungsklassen, die im Azure SDK verfügbar sind, immer bevorzugt, wenn sie sich bei Azure-Ressourcen authentifizieren.

Authentifizierung in Serverumgebungen

Wenn Sie in einer Serverumgebung hosten, wird jeder Anwendung eine eindeutige Anwendungsidentität pro Umgebung zugewiesen, in der die Anwendung ausgeführt wird. In Azure wird eine App-Identität durch einen Dienstprinzipal dargestellt. Dieser spezielle Sicherheitsprinzipaltyp identifiziert und authentifiziert Apps bei Azure. Der Dienstprinzipaltyp, der für Ihre App verwendet werden soll, hängt davon ab, wo Ihre App ausgeführt wird:

Authentifizierungsmethode	BESCHREIBUNG
In Azure gehostete Apps	In Azure gehostete Apps sollten einen Dienstprinzipal für verwaltete Identitäten verwenden. Verwaltete Identitäten sind so konzipiert, dass sie die Identität einer in Azure gehosteten App darstellen und nur mit in Azure gehosteten Apps verwendet werden können. Beispielsweise würde eine django-Web-App, die in Azure-App Dienst gehostet wird, einer verwalteten Identität zugewiesen. Dann wird die der App zugewiesene verwaltete Identität verwendet, um die App bei anderen Azure-Diensten zu authentifizieren. Apps, die in Azure Kubernetes Service (AKS) ausgeführt werden, können eine Workload-Identitätsanmeldeinformationen verwenden. Diese Anmeldeinformationen basieren auf einer verwalteten Identität, die eine Vertrauensstellung mit einem AKS-Dienstkonto aufweist. , Erfahren Sie mehr über die Authentifizierung aus von Azure gehosteten Apps
Außerhalb von Azure gehostete Apps (z. B. lokale Apps)	Apps, die außerhalb von Azure gehostet werden (z. B. lokale Apps), die eine Verbindung mit Azure-Diensten herstellen müssen, sollten einen Anwendungsdienstprinzipal verwenden. Ein Anwendungsdienstprinzipal stellt die Identität der App in Azure dar und wird über den App-Registrierungsprozess erstellt. Betrachten Sie beispielsweise eine lokal gehostete Django-Web-App, die Azure Blob Storage verwendet. Sie erstellen einen Anwendungsdienstprinzipal für die App mithilfe des App-Registrierungsprozesses. Das AZURE_CLIENT_ID, AZURE_TENANT_IDund AZURE_CLIENT_SECRET würde alle als Umgebungsvariablen gespeichert werden, die von der Anwendung zur Laufzeit gelesen werden sollen und der App erlauben, sich bei Azure mithilfe des Anwendungsdienstprinzipals zu authentifizieren. Erfahren Sie mehr über die Authentifizierung von Apps, die außerhalb von Azure gehostet werden.

Authentifizierung während der lokalen Entwicklung

Wenn eine Anwendung während der lokalen Entwicklung auf der Arbeitsstation eines Entwicklers ausgeführt wird, muss sie sich dennoch bei allen von der App verwendeten Azure-Diensten authentifizieren. Es gibt zwei Standard Strategien für die Authentifizierung von Apps für Azure während der lokalen Entwicklung:

Authentifizierungsmethode	Beschreibung
Erstellen Sie dedizierte Anwendungsdienstprinzipalobjekte, die während der lokalen Entwicklung verwendet werden sollen.	In dieser Methode werden dedizierte Anwendungsdienstprinzipalobjekte mithilfe des App-Registrierungsprozesses für die Verwendung während der lokalen Entwicklung eingerichtet. Die Identität des Dienstprinzipals wird dann in Form von Umgebungsvariablen gespeichert, auf die die App zugreifen kann, wenn sie in der lokalen Entwicklung ausgeführt wird. Mithilfe dieser Methode können Sie den Dienstprinzipalobjekten, die von Entwicklern während der lokalen Entwicklung verwendet werden, die von der App benötigten spezifischen Ressourcenberechtigungen zuweisen. In dieser Übung wird sichergestellt, dass die Anwendung nur Zugriff auf die benötigten Ressourcen hat und die Berechtigungen repliziert, die die App in der Produktion haben wird. Der Nachteil dieses Ansatzes ist die Notwendigkeit, separate Dienstprinzipalobjekte für jeden Entwickler zu erstellen, der an einer Anwendung arbeitet. Informationen zur Authentifizierung mithilfe von Entwicklerdienstprinzipale
Authentifizieren Sie die App bei Azure mithilfe der Anmeldeinformationen des Entwicklers während der lokalen Entwicklung.	Bei dieser Methode muss ein Entwickler von der Azure CLI, Azure PowerShell oder azure Developer CLI auf seiner lokalen Arbeitsstation bei Azure angemeldet sein. Die Anwendung kann dann über den Anmeldeinformationsspeicher auf die Anmeldeinformationen des Entwicklers zugreifen und diese Informationen verwenden, um aus der App auf Azure-Ressourcen zuzugreifen. Diese Methode hat den Vorteil der einfacheren Einrichtung, da sich ein Entwickler nur über eine der folgenden Erwähnung Entwicklertools bei ihrem Azure-Konto anmelden muss. Der Nachteil bei diesem Ansatz: Das Konto des Entwicklers hat wahrscheinlich mehr Berechtigungen, als von der Anwendung benötigt werden. Deshalb repliziert die Anwendung die Berechtigungen, mit denen sie in der Produktion ausgeführt wird, nicht genau. Informationen zur Authentifizierung mithilfe von Entwicklerkonten

Verwenden von DefaultAzureCredential in einer Anwendung

Um DefaultAzureCredential in einer Python-App zu verwenden, fügen Sie Das Azure.Identity-Paket zu Ihrer Anwendung hinzu.

pip install azure-identity

Das folgende Codebeispiel zeigt, wie Sie ein DefaultAzureCredential Objekt instanziieren und mit einer Azure SDK-Clientklasse verwenden. In diesem Fall ist es ein BlobServiceClient Objekt, das für den Zugriff auf Azure Blob Storage verwendet wird.

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)

Das DefaultAzureCredential Objekt erkennt automatisch den für die App konfigurierten Authentifizierungsmechanismus und ruft die erforderlichen Token ab, um die App bei Azure zu authentifizieren. Wenn eine Anwendung mehrere SDK-Clients verwendet, können Sie dasselbe Anmeldeinformationsobjekt mit jedem SDK-Clientobjekt verwenden.

Sequenz von Authentifizierungsmethoden bei Verwendung von DefaultAzureCredential

DefaultAzureCredential implementiert intern eine Kette von Anmeldeinformationsanbietern für die Authentifizierung von Anwendungen bei Azure-Ressourcen. Jeder Anmeldeinformationsanbieter kann erkennen, ob Anmeldeinformationen dieses Typs für die App konfiguriert sind. Das DefaultAzureCredential Objekt überprüft jeden Anbieter sequenziell und verwendet die Anmeldeinformationen des ersten Anbieters, der Anmeldeinformationen konfiguriert hat.

Die Reihenfolge, in der nach Anmeldeinformationen gesucht wird, DefaultAzureCredential wird im folgenden Diagramm und in der folgenden Tabelle gezeigt:

Anmeldeinformationstyp	Beschreibung
Environment	Das DefaultAzureCredential Objekt liest eine Reihe von Umgebungsvariablen, um zu ermitteln, ob ein Anwendungsdienstprinzipal (Anwendungsbenutzer) für die App festgelegt wurde. Wenn ja, verwendet DefaultAzureCredential diese Werte, um die App bei Azure zu authentifizieren. Diese Methode wird am häufigsten in Serverumgebungen verwendet, aber Sie können sie auch verwenden, wenn Sie lokal entwickeln.
Workloadidentität	Wenn die Anwendung für Azure Kubernetes Service (AKS) mit aktivierter verwalteter Identität bereitgestellt wird, DefaultAzureCredential authentifiziert sie die App mit dieser verwalteten Identität bei Azure. Die Workload-Identität stellt eine Vertrauensbeziehung zwischen einer vom Benutzer zugewiesenen verwalteten Identität und einem AKS-Dienstkonto dar. Die Authentifizierung mithilfe einer Workloadidentität wird im AKS-Artikel "Verwenden der Microsoft Entra Workload ID mit Azure Kubernetes Service" erläutert.
Verwaltete Identität	Wenn die Anwendung auf einem Azure-Host mit aktivierter verwalteter Identität bereitgestellt wird, DefaultAzureCredential authentifiziert sie die App mit dieser verwalteten Identität bei Azure. Die Authentifizierung mithilfe einer verwalteten Identität wird im Abschnitt "Authentifizierung in Serverumgebungen" erläutert. Diese Methode ist nur verfügbar, wenn eine Anwendung in Azure mithilfe eines Diensts wie Azure-App Service, Azure Functions oder Azure Virtual Machines gehostet wird.
Azure CLI	Wenn Sie sich mit dem az login Befehl in der Azure CLI bei Azure authentifiziert haben, DefaultAzureCredential authentifiziert sie die App mit demselben Konto bei Azure.
Azure PowerShell	Wenn Sie sich mit dem Connect-AzAccount Cmdlet von Azure PowerShell bei Azure authentifiziert haben, DefaultAzureCredential authentifiziert sie die App mit demselben Konto bei Azure.
Azure Developer CLI	Wenn Sie sich mit dem azd auth login Befehl in der Azure Developer CLI bei Azure authentifiziert haben, DefaultAzureCredential authentifiziert sie die App mit demselben Konto bei Azure.
Interactive	Wenn diese Option aktiviert ist, DefaultAzureCredential authentifiziert Sie interaktiv über den Standardbrowser des aktuellen Systems. Diese Option ist standardmäßig deaktiviert.

Hinweis

Aufgrund eines bekannten ProblemsVisualStudioCodeCredential wurde die DefaultAzureCredential Tokenkette entfernt. Wenn das Problem in einer zukünftigen Version behoben wird, wird diese Änderung rückgängig machen. Weitere Informationen finden Sie in der Azure Identity-Clientbibliothek für Python.