Autentisera Python-appar till Azure-tjänster med hjälp av Azure SDK för Python

När ett program behöver åtkomst till en Azure-resurs som Azure Storage, Azure Key Vault eller Azure AI-tjänster måste programmet autentiseras till Azure. Det här kravet gäller för alla program, oavsett om de distribueras till Azure, distribueras lokalt eller under utveckling på en lokal arbetsstation för utvecklare. I den här artikeln beskrivs de rekommenderade metoderna för att autentisera en app till Azure när du använder Azure SDK för Python.

Rekommenderad appautentiseringsmetod

Använd tokenbaserad autentisering i stället för anslutningssträng för dina appar när de autentiserar till Azure-resurser. Azure SDK för Python innehåller klasser som stöder tokenbaserad autentisering. Appar kan smidigt autentisera till Azure-resurser oavsett om appen är i lokal utveckling, distribueras till Azure eller distribueras till en lokal server.

Den specifika typen av tokenbaserad autentisering som en app använder för att autentisera till Azure-resurser beror på var appen körs. Typerna av tokenbaserad autentisering visas i följande diagram.

• När en utvecklare kör en app under lokal utveckling: Appen autentiserar till Azure med hjälp av antingen ett huvudnamn för programtjänsten för lokal utveckling eller utvecklarens Azure-autentiseringsuppgifter. De här alternativen beskrivs i avsnittet Autentisering under lokal utveckling.
• När en app finns i Azure: Appen autentiserar till Azure-resurser med hjälp av en hanterad identitet. Det här alternativet beskrivs i avsnittet Autentisering i servermiljöer.
• När en app finns och distribueras lokalt: Appen autentiserar till Azure-resurser med hjälp av ett huvudnamn för programtjänsten. Det här alternativet beskrivs i avsnittet Autentisering i servermiljöer.

StandardAzureCredential

Klassen DefaultAzureCredential som tillhandahålls av Azure SDK gör att appar kan använda olika autentiseringsmetoder beroende på vilken miljö de körs i. På så sätt kan appar höjas upp från lokal utveckling till att testa miljöer till produktion utan kodändringar.

Du konfigurerar lämplig autentiseringsmetod för varje miljö och DefaultAzureCredential identifierar och använder autentiseringsmetoden automatiskt. Användning av DefaultAzureCredential är att föredra framför att manuellt koda villkorslogik eller funktionsflaggor för att använda olika autentiseringsmetoder i olika miljöer.

Information om hur du använder DefaultAzureCredential klassen beskrivs i avsnittet Använd StandardAzureCredential i ett program.

Fördelar med tokenbaserad autentisering

Använd tokenbaserad autentisering i stället för att använda anslutningssträng när du skapar appar för Azure. Tokenbaserad autentisering ger följande fördelar jämfört med autentisering med anslutningssträng:

• Med de tokenbaserade autentiseringsmetoder som beskrivs i den här artikeln kan du upprätta de specifika behörigheter som krävs av appen för Azure-resursen. Den här metoden följer principen om lägsta behörighet. Däremot ger en anslutningssträng fullständiga rättigheter till Azure-resursen.
• Alla eller appar med en anslutningssträng kan ansluta till en Azure-resurs, men tokenbaserade autentiseringsmetoder omfattar åtkomst till resursen till endast de appar som är avsedda att komma åt resursen.
• Med en hanterad identitet finns det ingen programhemlighet att lagra. Appen är säkrare eftersom det inte finns någon anslutningssträng eller programhemlighet som kan komprometteras.
• Azure.identity-paketet i Azure SDK hanterar token åt dig i bakgrunden. Hanterade token gör det lika enkelt att använda tokenbaserad autentisering som en anslutningssträng.

Begränsa användningen av anslutningssträng till inledande koncepttestappar eller utvecklingsprototyper som inte har åtkomst till produktion eller känsliga data. Annars är de tokenbaserade autentiseringsklasserna som är tillgängliga i Azure SDK alltid att föredra när de autentiserar till Azure-resurser.

Autentisering i servermiljöer

När du är värd för en servermiljö tilldelas varje program en unik programidentitet per miljö där programmet körs. I Azure representeras en appidentitet av ett huvudnamn för tjänsten. Den här särskilda typen av säkerhetsobjekt identifierar och autentiserar appar till Azure. Vilken typ av tjänsthuvudnamn som ska användas för din app beror på var appen körs:

Autentiseringsmetod	beskrivning
Appar som finns i Azure	Appar som finns i Azure bör använda tjänstens huvudnamn för hanterad identitet. Hanterade identiteter är utformade för att representera identiteten för en app som finns i Azure och kan endast användas med Azure-värdbaserade appar. Till exempel skulle en Django-webbapp som finns i Azure App Service tilldelas en hanterad identitet. Den hanterade identitet som tilldelats appen används sedan för att autentisera appen till andra Azure-tjänster. Appar som körs i Azure Kubernetes Service (AKS) kan använda autentiseringsuppgifter för arbetsbelastningsidentitet. Den här autentiseringsuppgiften baseras på en hanterad identitet som har en förtroenderelation med ett AKS-tjänstkonto. , Lär dig mer om autentisering från Azure-värdbaserade appar
Appar som finns utanför Azure (till exempel lokala appar)	Appar som finns utanför Azure (till exempel lokala appar) som behöver ansluta till Azure-tjänster bör använda ett huvudnamn för programtjänsten. Ett huvudnamn för programtjänsten representerar appens identitet i Azure och skapas genom programregistreringsprocessen. Tänk dig till exempel en Django-webbapp som finns lokalt och som använder Azure Blob Storage. Du skapar ett huvudnamn för programtjänsten för appen med hjälp av appregistreringsprocessen. Alla AZURE_CLIENT_ID, AZURE_TENANT_IDoch AZURE_CLIENT_SECRET lagras som miljövariabler som ska läsas av programmet vid körning och göra det möjligt för appen att autentisera till Azure med hjälp av programtjänstens huvudnamn. Lär dig mer om autentisering från appar som finns utanför Azure

Autentisering under lokal utveckling

När ett program körs på en utvecklares arbetsstation under den lokala utvecklingen måste det fortfarande autentiseras mot alla Azure-tjänster som används av appen. Det finns två huvudsakliga strategier för att autentisera appar till Azure under lokal utveckling:

Autentiseringsmetod	beskrivning
Skapa dedikerade programtjänstobjekt som ska användas under lokal utveckling.	I den här metoden konfigureras dedikerade huvudobjekt för programtjänsten med hjälp av appregistreringsprocessen för användning under lokal utveckling. Identiteten för tjänstens huvudnamn lagras sedan som miljövariabler som ska användas av appen när den körs i lokal utveckling. Med den här metoden kan du tilldela de specifika resursbehörigheter som krävs av appen till de objekt för tjänstens huvudnamn som används av utvecklare under den lokala utvecklingen. Den här metoden säkerställer att programmet bara har åtkomst till de specifika resurser som behövs och replikerar de behörigheter som appen kommer att ha i produktion. Nackdelen med den här metoden är behovet av att skapa separata objekt för tjänstens huvudnamn för varje utvecklare som arbetar med ett program. Lär dig mer om autentisering med utvecklartjänstens huvudnamn
Autentisera appen till Azure med hjälp av utvecklarens autentiseringsuppgifter under den lokala utvecklingen.	I den här metoden måste en utvecklare loggas in på Azure från Azure CLI, Azure PowerShell eller Azure Developer CLI på sin lokala arbetsstation. Programmet kan sedan komma åt utvecklarens autentiseringsuppgifter från autentiseringsarkivet och använda dessa autentiseringsuppgifter för att komma åt Azure-resurser från appen. Den här metoden har fördelen med enklare konfiguration eftersom en utvecklare bara behöver logga in på sitt Azure-konto via något av de ovan nämnda utvecklarverktygen. Nackdelen med den här metoden är att utvecklarkontot sannolikt har fler behörigheter än vad som krävs av programmet. Därför replikerar programmet inte korrekt de behörigheter som det kommer att köras med i produktion. Lär dig mer om autentisering med hjälp av utvecklarkonton

Använda DefaultAzureCredential i ett program

Om du vill använda DefaultAzureCredential i en Python-app lägger du till paketet azure.identity i ditt program.

pip install azure-identity

I följande kodexempel visas hur du instansierar ett DefaultAzureCredential objekt och använder det med en Azure SDK-klientklass. I det här fallet är det ett BlobServiceClient objekt som används för att komma åt Azure Blob Storage.

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)

Objektet DefaultAzureCredential identifierar automatiskt den autentiseringsmekanism som konfigurerats för appen och hämtar nödvändiga token för att autentisera appen till Azure. Om ett program använder mer än en SDK-klient kan du använda samma autentiseringsobjekt med varje SDK-klientobjekt.

Sekvens med autentiseringsmetoder när du använder DefaultAzureCredential

Implementerar internt en kedja med autentiseringsprovidrar för att autentisera DefaultAzureCredential program till Azure-resurser. Varje autentiseringsprovider kan identifiera om autentiseringsuppgifter av den typen har konfigurerats för appen. Objektet DefaultAzureCredential kontrollerar varje provider sekventiellt i ordning och använder autentiseringsuppgifterna från den första providern som har konfigurerat autentiseringsuppgifter.

Den ordning som DefaultAzureCredential söker efter autentiseringsuppgifter visas i följande diagram och tabell:

Typ av autentiseringsuppgifter	beskrivning
Environment	Objektet DefaultAzureCredential läser en uppsättning miljövariabler för att avgöra om ett programtjänsthuvudnamn (programanvändare) har angetts för appen. I så fall DefaultAzureCredential använder du dessa värden för att autentisera appen till Azure. Den här metoden används oftast i servermiljöer, men du kan också använda den när du utvecklar lokalt.
Arbetsbelastningsidentitet	Om programmet distribueras till Azure Kubernetes Service (AKS) med hanterad identitet aktiverad autentiserar DefaultAzureCredential du appen till Azure med hjälp av den hanterade identiteten. Arbetsbelastningsidentitet representerar en förtroenderelation mellan en användartilldelad hanterad identitet och ett AKS-tjänstkonto. Autentisering med hjälp av en arbetsbelastningsidentitet beskrivs i AKS-artikeln Använda Microsoft Entra-arbetsbelastnings-ID med Azure Kubernetes Service.
Hanterad identitet	Om programmet distribueras till en Azure-värd med hanterad identitet aktiverad DefaultAzureCredential autentiserar du appen till Azure med hjälp av den hanterade identiteten. Autentisering med hjälp av en hanterad identitet beskrivs i avsnittet Autentisering i servermiljöer. Den här metoden är endast tillgänglig när ett program finns i Azure med hjälp av en tjänst som Azure App Service, Azure Functions eller Azure Virtual Machines.
Azure CLI	Om du har autentiserat az login till Azure med hjälp av kommandot i Azure CLI autentiserar DefaultAzureCredential du appen till Azure med hjälp av samma konto.
Azure PowerShell	Om du har autentiserat till Azure med hjälp av cmdleten Connect-AzAccount från Azure PowerShell autentiserar DefaultAzureCredential du appen till Azure med samma konto.
Azure Developer CLI	Om du har autentiserat azd auth login till Azure med hjälp av kommandot i Azure Developer CLI autentiserar DefaultAzureCredential du appen till Azure med samma konto.
Interaktivt	Om det är aktiverat DefaultAzureCredential autentiserar du dig interaktivt via det aktuella systemets standardwebbläsare. Det här alternativet är inaktiverat som standard.

Kommentar

På grund av ett känt problem VisualStudioCodeCredentialhar tagits bort från DefaultAzureCredential tokenkedjan. När problemet löses i en framtida version återställs den här ändringen. Mer information finns i Azure Identity-klientbiblioteket för Python.