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

  • Artikel

Wenn eine App auf eine Azure-Ressource wie Azure Storage, Azure Key Vault oder Azure KI Services zugreifen muss, muss die App bei Azure authentifiziert werden. Diese Anforderung gilt für alle Apps, unabhängig davon, ob sie in Azure oder lokal bereitgestellt werden oder sich auf einer lokalen Entwicklerarbeitsstation in der Entwicklung befinden. In diesem Artikel werden die empfohlenen Vorgehensweisen für die Authentifizierung einer App bei Azure beschrieben, wenn Sie das Azure SDK für Python verwenden.

Verwenden Sie die tokenbasierte Authentifizierung anstelle von Verbindungszeichenfolgen für Ihre Apps, wenn sie sich bei Azure-Ressourcen authentifizieren. Die Azure Identity-Clientbibliothek für Python stellt Klassen bereit, die die tokenbasierte Authentifizierung unterstützen und Apps eine nahtlose Authentifizierung bei Azure-Ressourcen ermöglichen, unabhängig davon, ob sich die App in der lokalen Entwicklung, in Azure oder auf einem lokalen Server befindet.

Der spezifische Typ der tokenbasierten Authentifizierung, den 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:

Diagramm, das die empfohlenen tokenbasierten Authentifizierungsstrategien für eine App zeigt, je nachdem, wo sie ausgeführt wird

  • Wenn ein Entwickler eine App während der lokalen Entwicklung 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 bei Azure-Ressourcen mithilfe einer verwalteten Identität. Diese Option wird im Abschnitt Authentifizierung in Serverumgebungen erläutert.
  • Wenn eine App lokal gehostet und bereitgestellt wird: Die App authentifiziert sich bei Azure-Ressourcen mithilfe eines Anwendungsdienstprinzipals. Diese Option wird im Abschnitt Authentifizierung in Serverumgebungen erläutert.

DefaultAzureCredential

Die von der Azure Identity-Clientbibliothek bereitgestellte Klasse DefaultAzureCredential ermöglicht Apps die Verwendung unterschiedlicher Authentifizierungsverfahren, je nach der Umgebung, in der sie ausgeführt werden. Auf diese Weise können Apps ohne Codeänderungen aus der lokalen Entwicklung in Testumgebungen und in die Produktion hochgestuft werden.

Sie konfigurieren die entsprechende Authentifizierungsmethode für jede Umgebung, und DefaultAzureCredential erkennt und verwendet diese Authentifizierungsmethode automatisch. Die Verwendung von DefaultAzureCredential wird der manuellen Codierung von bedingter Logik oder Featureflags vorgezogen, um unterschiedliche Authentifizierungsmethoden in verschiedenen Umgebungen zu verwenden.

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

Vorteile der tokenbasierten Authentifizierung

Verwenden Sie beim Erstellen von Apps für Azure die tokenbasierte Authentifizierung anstelle von Verbindungszeichenfolgen. Die tokenbasierte Authentifizierung bietet die folgenden Vorteile gegenüber der Authentifizierung mit Verbindungszeichenfolgen:

  • Mit den in diesem Artikel beschriebenen tokenbasierten Authentifizierungsmethoden können Sie die spezifischen Berechtigungen festlegen, die von der App für die Azure-Ressource benötigt werden. Diese Vorgehensweise folgt dem Prinzip der geringsten Rechte. Im Gegensatz dazu gewährt eine Verbindungszeichenfolge vollständige Rechte für die Azure-Ressource.
  • Jeder Benutzer oder jede App mit einer Verbindungszeichenfolge kann eine Verbindung mit einer Azure-Ressource herstellen, aber tokenbasierte Authentifizierungsmethoden beschränken den Zugriff auf die Ressource nur auf die Apps, die für den Zugriff auf die Ressource vorgesehen sind.
  • Bei einer verwalteten Identität gibt es kein Anwendungsgeheimnis, das gespeichert werden muss. Die App ist sicherer, da es keine Verbindungszeichenfolge oder kein Anwendungsgeheimnis gibt, die bzw. das kompromittiert werden kann.
  • Das Azure-Identity-Paket erwirbt und verwaltet Microsoft Entra-Token für Sie. So kann die tokenbasierte Authentifizierung so einfach wie eine Verbindungszeichenfolge verwendet werden.

Beschränken Sie die Verwendung von Verbindungszeichenfolgen auf anfängliche Proof-of-Concept-Apps oder Entwicklungsprototypen, die nicht auf Produktionsdaten oder vertrauliche Daten zugreifen. Andernfalls werden bei der Authentifizierung bei Azure-Ressourcen immer die tokenbasierten Authentifizierungsklassen bevorzugt, die in der Azure Identity-Clientbibliothek verfügbar sind.

Authentifizierung in Serverumgebungen

Beim Hosten in einer Serverumgebung wird jeder App eine eindeutige Anwendungsidentität pro Umgebung zugewiesen, in der die App ausgeführt wird. In Azure wird eine Anwendungs-Identität durch einen Dienstprinzipal dargestellt. Dieser spezielle Sicherheitsprinzipaltyp identifiziert und authentifiziert Apps bei Azure. Welcher Dienstprinzipaltyp 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. Sie können nur bei von Azure gehosteten Apps verwendet werden.

Beispielsweise wird einer Django-Web-App, die in Azure App Service gehostet wird, eine verwaltete 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 Anmeldeinformationen für Workloadidentitäten verwenden. Diese Anmeldeinformationen basieren auf einer verwalteten Identität, die eine Vertrauensstellung mit einem AKS-Dienstkonto aufweist.
,

Erfahren Sie mehr über die Authentifizierung aus in 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) und 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.

Denken Sie etwa an eine lokal gehostete Django-Web-App, die Azure Blob Storage verwendet. Sie erstellen einen Anwendungsdienstprinzipal für die App, indem Sie den App-Registrierungsprozess verwenden. AZURE_CLIENT_ID, AZURE_TENANT_ID und AZURE_CLIENT_SECRET werden alle als Umgebungsvariablen gespeichert, die von der Anwendung zur Laufzeit gelesen werden und es der App ermöglichen, sich mithilfe des Anwendungsdienstprinzipals bei Azure 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 App während der lokalen Entwicklung auf der Arbeitsstation eines Entwicklers ausgeführt wird, muss sie sich weiterhin bei allen Azure-Diensten authentifizieren, die von der App verwendet werden. Es gibt zwei Hauptstrategien für die Authentifizierung von Apps bei Azure während der lokalen Entwicklung:

Authentifizierungsmethode Beschreibung
Erstellen dedizierter Anwendungsdienstprinzipalobjekte, die während der lokalen Entwicklung verwendet werden sollen Bei 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. Auf diese Weise wird sichergestellt, dass die Anwendung nur Zugriff auf die spezifischen Ressourcen hat, die sie benötigt, und die Berechtigungen repliziert, über die die App in der Produktion verfügt.

Der Nachteil dieses Ansatzes besteht darin, dass für jeden Entwickler, der an einer Anwendung arbeitet, separate Dienstprinzipalobjekte erstellt werden müssen.

Erfahren Sie mehr zur Authentifizierung mithilfe von Entwicklerdienstprinzipalen
Authentifizieren Sie während der lokalen Entwicklung die App bei Azure mithilfe der Anmeldeinformationen des Entwicklers. Bei dieser Methode muss ein Entwickler über die Azure-CLI, Azure PowerShell oder die 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 einer einfacheren Einrichtung, da sich ein Entwickler nur über eines der oben genannten Entwicklertools bei seinem 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.

Erfahren Sie mehr über die Authentifizierung mithilfe von Entwicklerkonten

Verwenden von DefaultAzureCredential in einer Anwendung

DefaultAzureCredential ist eine eigensinnige, geordnete Abfolge von Mechanismen für die Authentifizierung bei Microsoft Entra ID . Jeder Authentifizierungsmechanismus ist eine Klasse, die das TokenCredential-Protokoll implementiert und als Anmeldeinformationen bezeichnet wird. Zur Laufzeit versucht DefaultAzureCredential, sich mit den ersten Anmeldeinformationen zu authentifizieren. Wenn diese Anmeldeinformationen kein Zugriffstoken abrufen, werden die nächsten Anmeldeinformationen in der Sequenz ausprobiert usw., bis erfolgreich ein Zugriffstoken abgerufen wurde. Auf diese Weise kann Ihre App unterschiedliche Anmeldeinformationen in verschiedenen Umgebungen verwenden, ohne umgebungsspezifischen Code zu schreiben.

Um DefaultAzureCredential in einer Python-App zu verwenden, fügen Sie das Paket azure-identity zu Ihrer Anwendung hinzu.

pip install azure-identity

Auf Azure-Dienste wird mithilfe spezieller Clientklassen aus den verschiedenen Azure SDK-Clientbibliotheken zugegriffen. Das folgende Codebeispiel zeigt, wie Sie ein DefaultAzureCredential-Objekt instanziieren und mit einer Azure SDK-Clientklasse verwenden. In diesem Fall wird ein BlobServiceClient-Objekt für den Zugriff auf Azure Blob Storage verwendet.

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)

Wenn der obige Code auf Ihrer lokalen Entwicklungsarbeitsstation ausgeführt wird, sucht er in den Umgebungsvariablen nach einem Anwendungsdienstprinzipal oder in lokal installierten Entwicklertools, z. B. der Azure CLI, nach einer Reihe von Entwickleranmeldeinformationen. Beide Ansätze können verwendet werden, um die App während der lokalen Entwicklung bei Azure-Ressourcen zu authentifizieren.

Bei der Bereitstellung in Azure kann derselbe Code auch Ihre App bei Azure-Ressourcen authentifizieren. DefaultAzureCredential kann Umgebungseinstellungen und Konfigurationen für verwaltete Identitäten abrufen, um sich automatisch bei Azure-Diensten zu authentifizieren.

Zugehöriger Inhalt