Autentisera Python-appar till Azure-tjänster med hjälp av Azure SDK för Python
När en app behöver åtkomst till en Azure-resurs som Azure Storage, Azure Key Vault eller Azure AI-tjänster måste appen autentiseras till Azure. Det här kravet gäller för alla appar, 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 Identity-klientbiblioteket för Python innehåller klasser som stöder tokenbaserad autentisering och gör det möjligt för appar att 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 Identity-klientbiblioteket 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-identitetspaketet hämtar och hanterar Microsoft Entra-token åt dig. Detta gör det 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 föredras alltid de tokenbaserade autentiseringsklasserna som är tillgängliga i Azure Identity-klientbiblioteket när de autentiseras mot Azure-resurser.
Autentisering i servermiljöer
När du är värd för en servermiljö tilldelas varje app en unik programidentitet per miljö där appen körs. I Azure representeras en programidentitet 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. , |
| 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. |
Autentisering under lokal utveckling
När en app körs på en utvecklares arbetsstation under den lokala utvecklingen måste den 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. |
| 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. |
Använda DefaultAzureCredential i ett program
DefaultAzureCredential är en åsiktsbaserad, ordnad sekvens med mekanismer för autentisering till Microsoft Entra-ID. Varje autentiseringsmekanism är en klass som implementerar TokenCredential-protokollet och kallas för autentiseringsuppgifter. Vid körning DefaultAzureCredential försöker autentisera med hjälp av den första autentiseringsuppgiften. Om det inte går att hämta en åtkomsttoken görs nästa autentiseringsuppgifter i sekvensen och så vidare tills en åtkomsttoken har hämtats. På så sätt kan din app använda olika autentiseringsuppgifter i olika miljöer utan att skriva miljöspecifik kod.
Om du vill använda DefaultAzureCredential i en Python-app lägger du till azure-identity-paketet i ditt program.
pip install azure-identity
Azure-tjänster används med hjälp av specialiserade klientklasser från de olika Azure SDK-klientbiblioteken. 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)
När föregående kod körs på din lokala utvecklingsarbetsstation letar den i miljövariablerna efter ett programtjänsthuvudnamn eller lokalt installerade utvecklarverktyg, till exempel Azure CLI, för en uppsättning autentiseringsuppgifter för utvecklare. Endera metoden kan användas för att autentisera appen till Azure-resurser under lokal utveckling.
När den distribueras till Azure kan samma kod även autentisera din app till Azure-resurser. DefaultAzureCredential kan hämta miljöinställningar och hanterade identitetskonfigurationer för att autentisera till Azure-tjänster automatiskt.