Python-apps verifiëren bij Azure-services met behulp van de Azure SDK voor Python

Wanneer een toepassing toegang moet hebben tot een Azure-resource zoals Azure Storage, Azure Key Vault of Azure AI-services, moet de toepassing worden geverifieerd bij Azure. Deze vereiste geldt voor alle toepassingen, ongeacht of deze zijn geïmplementeerd in Azure, on-premises zijn geïmplementeerd of in ontwikkeling zijn op een lokaal ontwikkelwerkstation. In dit artikel worden de aanbevolen methoden beschreven voor het verifiëren van een app bij Azure wanneer u de Azure SDK voor Python gebruikt.

Aanbevolen methode voor app-verificatie

Gebruik verificatie op basis van tokens in plaats van verbindingsreeks s voor uw apps wanneer ze worden geverifieerd bij Azure-resources. De Azure SDK voor Python biedt klassen die ondersteuning bieden voor verificatie op basis van tokens. Apps kunnen naadloos worden geverifieerd bij Azure-resources, ongeacht of de app zich in lokale ontwikkeling bevindt, in Azure is geïmplementeerd of op een on-premises server is geïmplementeerd.

Het specifieke type verificatie op basis van tokens dat een app gebruikt om te verifiëren bij Azure-resources, is afhankelijk van waar de app wordt uitgevoerd. De typen verificatie op basis van tokens worden weergegeven in het volgende diagram.

• Wanneer een ontwikkelaar een app uitvoert tijdens lokale ontwikkeling: de app wordt geverifieerd bij Azure met behulp van een toepassingsservice-principal voor lokale ontwikkeling of de Azure-referenties van de ontwikkelaar. Deze opties worden besproken in de sectie Verificatie tijdens lokale ontwikkeling.
• Wanneer een app wordt gehost in Azure: de app wordt geverifieerd bij Azure-resources met behulp van een beheerde identiteit. Deze optie wordt besproken in de sectie Verificatie in serveromgevingen.
• Wanneer een app on-premises wordt gehost en geïmplementeerd: de app wordt geverifieerd bij Azure-resources met behulp van een service-principal voor toepassingen. Deze optie wordt besproken in de sectie Verificatie in serveromgevingen.

DefaultAzureCredential

Met de StandaardAzureCredential-klasse die door de Azure SDK wordt geleverd, kunnen apps verschillende verificatiemethoden gebruiken, afhankelijk van de omgeving waarin ze worden uitgevoerd. Op deze manier kunnen apps worden gepromoveerd van lokale ontwikkeling tot testomgevingen naar productie zonder codewijzigingen.

U configureert de juiste verificatiemethode voor elke omgeving en DefaultAzureCredential detecteert en gebruikt deze verificatiemethode automatisch. Het gebruik van is de voorkeur boven het handmatig coderen van DefaultAzureCredential voorwaardelijke logica of functievlagmen om verschillende verificatiemethoden in verschillende omgevingen te gebruiken.

Details over het gebruik van de DefaultAzureCredential klasse worden besproken in de sectie DefaultAzureCredential gebruiken in een toepassing.

Voordelen van verificatie op basis van tokens

Gebruik verificatie op basis van tokens in plaats van verbindingsreeks s wanneer u apps voor Azure bouwt. Verificatie op basis van tokens biedt de volgende voordelen ten opzichte van verificatie met verbindingsreeks s:

• Met de verificatiemethoden op basis van tokens die in dit artikel worden beschreven, kunt u de specifieke machtigingen instellen die nodig zijn voor de app in de Azure-resource. Deze praktijk volgt het principe van minimale bevoegdheden. Een verbindingsreeks verleent daarentegen volledige rechten aan de Azure-resource.
• Iedereen of elke app met een verbindingsreeks kan verbinding maken met een Azure-resource, maar verificatiemethoden op basis van tokens hebben alleen toegang tot de resource tot de apps die zijn bedoeld voor toegang tot de resource.
• Met een beheerde identiteit is er geen toepassingsgeheim om op te slaan. De app is veiliger omdat er geen verbindingsreeks of toepassingsgeheim is dat kan worden aangetast.
• Het pakket azure.identity in de Azure SDK beheert tokens voor u achter de schermen. Beheerde tokens maken het gebruik van verificatie op basis van tokens net zo eenvoudig als een verbindingsreeks.

Beperk het gebruik van verbindingsreeks tot initiële proof-of-concept-apps of ontwikkelprototypes die geen toegang hebben tot productie- of gevoelige gegevens. Anders hebben de verificatieklassen op basis van tokens die beschikbaar zijn in de Azure SDK altijd de voorkeur wanneer ze worden geverifieerd bij Azure-resources.

Verificatie in serveromgevingen

Wanneer u host in een serveromgeving, krijgt elke toepassing een unieke toepassingsidentiteit toegewezen per omgeving waarin de toepassing wordt uitgevoerd. In Azure wordt een app-identiteit vertegenwoordigd door een service-principal. Dit speciale type beveiligingsprincipaal identificeert en verifieert apps bij Azure. Het type service-principal dat voor uw app moet worden gebruikt, is afhankelijk van waar uw app wordt uitgevoerd:

Verificatiemethode	Beschrijving
Apps die worden gehost in Azure	Apps die worden gehost in Azure, moeten een service-principal voor beheerde identiteiten gebruiken. Beheerde identiteiten zijn ontworpen om de identiteit van een app te vertegenwoordigen die wordt gehost in Azure en kan alleen worden gebruikt met door Azure gehoste apps. Aan een Django-web-app die wordt gehost in Azure-app Service, wordt bijvoorbeeld een beheerde identiteit toegewezen. De beheerde identiteit die aan de app is toegewezen, wordt vervolgens gebruikt om de app te verifiëren bij andere Azure-services. Apps die worden uitgevoerd in Azure Kubernetes Service (AKS) kunnen een referentie voor de workloadidentiteit gebruiken. Deze referentie is gebaseerd op een beheerde identiteit met een vertrouwensrelatie met een AKS-serviceaccount. , Meer informatie over verificatie vanuit door Azure gehoste apps
Apps die buiten Azure worden gehost (bijvoorbeeld on-premises apps)	Apps die buiten Azure worden gehost (bijvoorbeeld on-premises apps) die verbinding moeten maken met Azure-services, moeten gebruikmaken van een service-principal voor toepassingen. Een toepassingsservice-principal vertegenwoordigt de identiteit van de app in Azure en wordt gemaakt via het registratieproces van de toepassing. Denk bijvoorbeeld aan een Django-web-app die on-premises wordt gehost en die gebruikmaakt van Azure Blob Storage. U maakt een toepassingsservice-principal voor de app met behulp van het app-registratieproces. De AZURE_CLIENT_ID, AZURE_TENANT_IDen AZURE_CLIENT_SECRET worden allemaal opgeslagen als omgevingsvariabelen die tijdens runtime door de toepassing moeten worden gelezen en toestaan dat de app wordt geverifieerd bij Azure met behulp van de service-principal van de toepassing. Meer informatie over verificatie van apps die buiten Azure worden gehost

Verificatie tijdens lokale ontwikkeling

Wanneer een toepassing wordt uitgevoerd op het werkstation van een ontwikkelaar tijdens de lokale ontwikkeling, moet deze nog steeds worden geverifieerd bij alle Azure-services die door de app worden gebruikt. Er zijn twee belangrijke strategieën voor het verifiëren van apps bij Azure tijdens lokale ontwikkeling:

Verificatiemethode	Beschrijving
Maak toegewezen service-principalobjecten voor toepassingen die moeten worden gebruikt tijdens lokale ontwikkeling.	In deze methode worden speciale service-principalobjecten voor toepassingen ingesteld met behulp van het app-registratieproces voor gebruik tijdens lokale ontwikkeling. De identiteit van de service-principal wordt vervolgens opgeslagen als omgevingsvariabelen die toegankelijk zijn voor de app wanneer deze wordt uitgevoerd in lokale ontwikkeling. Met deze methode kunt u de specifieke resourcemachtigingen die de app nodig heeft, toewijzen aan de service-principal-objecten die tijdens de lokale ontwikkeling door ontwikkelaars worden gebruikt. Deze procedure zorgt ervoor dat de toepassing alleen toegang heeft tot de specifieke resources die deze nodig heeft en repliceert de machtigingen die de app in productie heeft. Het nadeel van deze aanpak is dat er afzonderlijke service-principalobjecten moeten worden gemaakt voor elke ontwikkelaar die aan een toepassing werkt. Meer informatie over verificatie met behulp van service-principals voor ontwikkelaars
Verifieer de app bij Azure met behulp van de referenties van de ontwikkelaar tijdens de lokale ontwikkeling.	In deze methode moet een ontwikkelaar zijn aangemeld bij Azure vanuit de Azure CLI, Azure PowerShell of Azure Developer CLI op hun lokale werkstation. De toepassing heeft vervolgens toegang tot de referenties van de ontwikkelaar vanuit het referentiearchief en gebruikt deze referenties voor toegang tot Azure-resources vanuit de app. Deze methode heeft het voordeel van eenvoudigere installatie omdat een ontwikkelaar zich alleen hoeft aan te melden bij zijn Azure-account via een van de bovengenoemde ontwikkelhulpprogramma's. Het nadeel van deze benadering is dat het account van de ontwikkelaar waarschijnlijk meer machtigingen heeft dan vereist is voor de toepassing. Als gevolg hiervan repliceert de toepassing niet nauwkeurig de machtigingen waarmee deze wordt uitgevoerd in productie. Meer informatie over verificatie met ontwikkelaarsaccounts

DefaultAzureCredential gebruiken in een toepassing

Als u DefaultAzureCredential in een Python-app wilt gebruiken, voegt u het pakket azure.identity toe aan uw toepassing.

pip install azure-identity

In het volgende codevoorbeeld ziet u hoe u een DefaultAzureCredential object instantieert en gebruikt met een Azure SDK-clientklasse. In dit geval is het een BlobServiceClient object dat wordt gebruikt voor toegang tot 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)

Het DefaultAzureCredential object detecteert automatisch het verificatiemechanisme dat is geconfigureerd voor de app en haalt de benodigde tokens op om de app te verifiëren bij Azure. Als een toepassing gebruikmaakt van meer dan één SDK-client, kunt u hetzelfde referentieobject gebruiken voor elk SDK-clientobject.

Reeks verificatiemethoden wanneer u DefaultAzureCredential gebruikt

DefaultAzureCredential Implementeert intern een keten van referentieproviders voor het verifiëren van toepassingen bij Azure-resources. Elke referentieprovider kan detecteren of referenties van dat type zijn geconfigureerd voor de app. Het DefaultAzureCredential object controleert elke provider op volgorde en gebruikt de referenties van de eerste provider waarvoor referenties zijn geconfigureerd.

De volgorde waarin DefaultAzureCredential wordt gezocht naar referenties, wordt weergegeven in het volgende diagram en de volgende tabel:

Referentietype	Beschrijving
Omgeving	Het DefaultAzureCredential object leest een set omgevingsvariabelen om te bepalen of een toepassingsservice-principal (toepassingsgebruiker) is ingesteld voor de app. Als dat het zo is, DefaultAzureCredential gebruikt u deze waarden om de app te verifiëren bij Azure. Deze methode wordt meestal gebruikt in serveromgevingen, maar u kunt deze ook gebruiken wanneer u lokaal ontwikkelt.
Workload-identiteit	Als de toepassing is geïmplementeerd in Azure Kubernetes Service (AKS) waarvoor beheerde identiteit is ingeschakeld, verifieert u DefaultAzureCredential de app bij Azure met behulp van die beheerde identiteit. Workloadidentiteit vertegenwoordigt een vertrouwensrelatie tussen een door de gebruiker toegewezen beheerde identiteit en een AKS-serviceaccount. Verificatie met behulp van een workloadidentiteit wordt besproken in het AKS-artikel Gebruik Microsoft Entra Workload-ID met Azure Kubernetes Service.
Beheerde identiteit	Als de toepassing wordt geïmplementeerd op een Azure-host waarvoor beheerde identiteit is ingeschakeld, DefaultAzureCredential verifieert u de app bij Azure met behulp van die beheerde identiteit. Verificatie met behulp van een beheerde identiteit wordt besproken in de sectie Verificatie in serveromgevingen. Deze methode is alleen beschikbaar wanneer een toepassing wordt gehost in Azure met behulp van een service zoals Azure-app Service, Azure Functions of Azure Virtual Machines.
Azure-CLI	Als u bent geverifieerd bij Azure met behulp van de az login opdracht in de Azure CLI, DefaultAzureCredential verifieert u de app bij Azure met behulp van datzelfde account.
Azure PowerShell	Als u bent geverifieerd bij Azure met behulp van de Connect-AzAccount cmdlet van Azure PowerShell, DefaultAzureCredential verifieert u de app bij Azure met hetzelfde account.
Azure Developer CLI	Als u bent geverifieerd bij Azure met behulp van de azd auth login opdracht in de Azure Developer CLI, DefaultAzureCredential verifieert u de app bij Azure met behulp van hetzelfde account.
Interactief	Indien ingeschakeld, DefaultAzureCredential wordt u interactief geverifieerd via de standaardbrowser van het huidige systeem. Deze optie is standaard uitgeschakeld.

Notitie

Vanwege een bekend probleem, VisualStudioCodeCredential is verwijderd uit de DefaultAzureCredential tokenketen. Wanneer het probleem in een toekomstige release wordt opgelost, wordt deze wijziging teruggedraaid. Zie de Azure Identity-clientbibliotheek voor Python voor meer informatie.