Azure-gehoste toepassingen verifiëren voor Azure-resources met de Azure SDK voor Python

Wanneer u een app in Azure host met behulp van services zoals Azure-app Service, Azure Virtual Machines of Azure Container Instances, is de aanbevolen methode voor het verifiëren van een app voor Azure-resources met beheerde identiteit.

Een beheerde identiteit biedt een identiteit voor uw app, zodat deze verbinding kan maken met andere Azure-resources zonder dat u een geheime sleutel of een ander toepassingsgeheim hoeft te gebruiken. Intern kent Azure de identiteit van uw app en met welke resources deze verbinding kan maken. Azure gebruikt deze informatie om automatisch Microsoft Entra-tokens voor de app te verkrijgen, zodat deze verbinding kan maken met andere Azure-resources, allemaal zonder dat u toepassingsgeheimen hoeft te beheren.

Notitie

Apps die worden uitgevoerd op Azure Kubernetes Service (AKS) kunnen een workloadidentiteit gebruiken om te verifiëren met Azure-resources. In AKS vertegenwoordigt een workloadidentiteit een vertrouwensrelatie tussen een beheerde identiteit en een Kubernetes-serviceaccount. Als een toepassing die is geïmplementeerd in AKS is geconfigureerd met een Kubernetes-serviceaccount in een dergelijke relatie, DefaultAzureCredential verifieert u de app bij Azure met behulp van de beheerde identiteit. Verificatie met behulp van een workloadidentiteit wordt besproken in Use Microsoft Entra Workload-ID met Azure Kubernetes Service. Zie Workloadidentiteit implementeren en configureren in een AKS-cluster (Azure Kubernetes Service) voor stappen voor het configureren van workloadidentiteit.

Typen beheerde identiteiten

Er zijn twee typen beheerde identiteit:

• Door het systeem toegewezen beheerde identiteiten : dit type beheerde identiteit wordt geleverd door en rechtstreeks gekoppeld aan een Azure-resource. Wanneer u beheerde identiteit inschakelt voor een Azure-resource, krijgt u een door het systeem toegewezen beheerde identiteit voor die resource. Een door het systeem toegewezen beheerde identiteit is gekoppeld aan de levenscyclus van de bijbehorende Azure-resource. Wanneer de resource wordt verwijderd, verwijdert Azure de identiteit automatisch voor u. Omdat u alleen beheerde identiteit moet inschakelen voor de Azure-resource die als host fungeert voor uw code, is deze benadering het eenvoudigste type beheerde identiteit dat moet worden gebruikt.
• Door de gebruiker toegewezen beheerde identiteiten : u kunt ook een beheerde identiteit maken als een zelfstandige Azure-resource. Deze benadering wordt het vaakst gebruikt wanneer uw oplossing meerdere workloads heeft die worden uitgevoerd op meerdere Azure-resources die allemaal dezelfde identiteit en dezelfde machtigingen moeten delen. Als uw oplossing bijvoorbeeld onderdelen had die worden uitgevoerd op meerdere App Service- en virtuele-machine-exemplaren die allemaal toegang nodig hebben tot dezelfde set Azure-resources, is een door de gebruiker toegewezen beheerde identiteit die in deze resources wordt gebruikt logisch.

In dit artikel worden de stappen beschreven voor het inschakelen en gebruiken van een door het systeem toegewezen beheerde identiteit voor een app. Als u een door de gebruiker toegewezen beheerde identiteit wilt gebruiken, raadpleegt u het artikel Door de gebruiker toegewezen beheerde identiteiten beheren om te zien hoe u een door de gebruiker toegewezen beheerde identiteit maakt.

Beheerde identiteit inschakelen in de Azure-resource die als host fungeert voor de app

De eerste stap is het inschakelen van een beheerde identiteit in Azure-resource die als host fungeert voor uw app. Als u bijvoorbeeld een Django-toepassing host met behulp van Azure App Service, moet u beheerde identiteit inschakelen voor de App Service-web-app die als host fungeert voor uw app. Als u een virtuele machine gebruikt om uw app te hosten, stelt u uw VIRTUELE machine in staat om beheerde identiteit te gebruiken.

U kunt een beheerde identiteit inschakelen voor een Azure-resource met behulp van De Azure-portal of de Azure CLI.

Azure-CLI

Azure CLI-opdrachten kunnen worden uitgevoerd in Azure Cloud Shell of op een werkstation waarop de Azure CLI is geïnstalleerd.

De Azure CLI-opdrachten die worden gebruikt om beheerde identiteit voor een Azure-resource in te schakelen, zijn van het formulier az <command-group> identity --resource-group <resource-group-name> --name <resource-name>. Zie de volgende opdrachten voor populaire Azure-services.

Azure App Service

az webapp identity assign --resource-group <resource-group-name> --name <web-app-name>

Azure Virtuele Machines

az vm identity assign --resource-group <resource-group-name> --name <virtual-machine-name>

De uitvoer ziet er als volgt uit.

{
  "principalId": "aaaaaaaa-bbbb-cccc-1111-222222222222",
  "tenantId": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "type": "SystemAssigned",
  "userAssignedIdentities": null
}

De principalId waarde is de unieke id van de beheerde identiteit. Bewaar een kopie van deze uitvoer omdat u deze waarden nodig hebt in de volgende stap.

Azure-portal

Instructies	Schermafbeelding
Navigeer naar de resource die als host fungeert voor uw toepassingscode in Azure Portal. U kunt bijvoorbeeld de naam van uw resource typen in het zoekvak boven aan de pagina en ernaar navigeren door deze te selecteren in het dialoogvenster.
Selecteer op de pagina voor uw resource het menu-item Identiteit in het linkermenu. Alle Azure-resources die beheerde identiteit kunnen ondersteunen, hebben een menu-item Identiteit , ook al kan de indeling van het menu enigszins variëren.
Op de pagina Identiteit : Wijzig de schuifregelaar Status naar Aan. Selecteer Opslaan. In een bevestigingsvenster wordt gecontroleerd of u beheerde identiteit voor uw service wilt inschakelen. Antwoord Ja om beheerde identiteit voor de Azure-resource in te schakelen.

Rollen toewijzen aan de beheerde identiteit

Vervolgens moet u bepalen welke rollen (machtigingen) uw app nodig heeft en de beheerde identiteit toewijzen aan die rollen in Azure. Aan een beheerde identiteit kunnen rollen worden toegewezen voor een resource, resourcegroep of abonnementsbereik. In dit voorbeeld ziet u hoe u rollen toewijst aan het bereik van de resourcegroep, omdat de meeste toepassingen al hun Azure-resources groeperen in één resourcegroep.

Azure-CLI

Met de opdracht az role assignment create wordt een rol toegewezen aan een beheerde identiteit. Gebruik voor de toegewezen gebruiker de principalId die u in stap 1 hebt gekopieerd.

az role assignment create --assignee <managedIdentityprincipalId> \
    --scope /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName> \
    --role "<roleName>" 

Gebruik de opdracht az role definition list om de rolnamen op te halen waaraan een service-principal kan worden toegewezen.

az role definition list \
    --query "sort_by([].{roleName:roleName, description:description}, &roleName)" \
    --output table

Als u bijvoorbeeld de beheerde identiteit wilt toestaan met de id van aaaaaaaa-bbbb-cccc-1111-222222222222 lees-, schrijf- en verwijdertoegang tot Azure Storage-blobcontainers en -gegevens in alle opslagaccounts in de resourcegroep msdocs-python-sdk-auth-auth-example in het abonnement met id aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e, wijst u de service-principal van de toepassing toe aan de rol Inzender voor opslagblobgegevens met behulp van de volgende opdracht.

az role assignment create --assignee aaaaaaaa-bbbb-cccc-1111-222222222222 \
    --scope /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/msdocs-python-sdk-auth-example \
    --role "Storage Blob Data Contributor"

Zie het artikel Azure-rollen toewijzen met behulp van de Azure CLI voor informatie over het toewijzen van machtigingen op resource- of abonnementsniveau met behulp van de Azure CLI.

Azure-portal

Instructies	Schermafbeelding
Zoek de resourcegroep voor uw toepassing door te zoeken naar de naam van de resourcegroep met behulp van het zoekvak boven aan Azure Portal. Navigeer naar uw resourcegroep door de naam van de resourcegroep te selecteren onder de kop Resourcegroepen in het dialoogvenster.
Ga op de pagina voor de resourcegroep in het menu aan de linkerkant naar Toegangsbeheer (IAM).
Op de pagina Toegangsbeheer (IAM): Selecteer het tabblad Roltoewijzingen. Selecteer + Toevoegen in het bovenste menu en voeg vervolgens roltoewijzing toe in de resulterende vervolgkeuzelijst.
De pagina Roltoewijzing toevoegen bevat alle rollen die kunnen worden toegewezen voor de resourcegroep. Gebruik het zoekvak om de lijst te filteren op een beter beheerbare grootte. In dit voorbeeld ziet u hoe u filtert op Storage Blob-rollen. Selecteer de rol die u wilt toewijzen. Selecteer Volgende om naar het volgende scherm te gaan.
Op de volgende pagina Roltoewijzing toevoegen kunt u opgeven aan welke gebruiker de rol moet toewijzen. Selecteer Beheerde identiteit onder Toegang toewijzen aan. Selecteer + Leden selecteren onder Leden Aan de rechterkant van Azure Portal wordt een dialoogvenster geopend.
In het dialoogvenster Beheerde identiteiten selecteren : De vervolgkeuzelijst Beheerde identiteit en het tekstvak Selecteren kunnen worden gebruikt om de lijst met beheerde identiteiten in uw abonnement te filteren. In dit voorbeeld worden alleen beheerde identiteiten weergegeven die zijn gekoppeld aan een App Service door App Service te selecteren. Selecteer de beheerde identiteit voor de Azure-resource die als host fungeert voor uw toepassing. Kies Selecteren onderaan het dialoogvenster om door te gaan.
De beheerde identiteit wordt als geselecteerd weergegeven op het scherm Roltoewijzing toevoegen. Selecteer Beoordelen + toewijzen om naar de laatste pagina te gaan en vervolgens opnieuw beoordelen en toewijzen om het proces te voltooien.

DefaultAzureCredential implementeren in uw toepassing

Wanneer uw code wordt uitgevoerd in Azure en beheerde identiteit is ingeschakeld op de Azure-resource die als host fungeert voor uw app, bepaalt de DefaultAzureCredential referenties die moeten worden gebruikt in de volgende volgorde:

1. Controleer de omgeving op een service-principal zoals gedefinieerd door de omgevingsvariabelen AZURE_CLIENT_ID, AZURE_TENANT_ID, en AZURE_CLIENT_SECRET of AZURE_CLIENT_CERTIFICATE_PATH, en (optioneel) AZURE_CLIENT_CERTIFICATE_PASSWORD.
2. Controleer trefwoordparameters voor een door de gebruiker toegewezen beheerde identiteit. U kunt een door de gebruiker toegewezen beheerde identiteit doorgeven door de client-id in de managed_identity_client_id parameter op te geven.
3. Controleer de AZURE_CLIENT_ID omgevingsvariabele voor de client-id van een door de gebruiker toegewezen beheerde identiteit.
4. Als beheerde identiteit is ingeschakeld voor de Azure-resource, gebruikt u de door het systeem toegewezen beheerde identiteit.

U kunt beheerde identiteiten uitsluiten van de referentie door de exclude_managed_identity_credential parameter Truevoor trefwoorden in te stellen.

In dit artikel wordt de door het systeem toegewezen beheerde identiteit gebruikt voor een Azure App Service-web-app. Met deze methode hoeft u geen beheerde identiteit in de omgeving te configureren of deze als parameter door te geven. De volgende stappen laten zien hoe u deze kunt gebruiken DefaultAzureCredential.

Voeg eerst het azure.identity pakket toe aan uw toepassing.

pip install azure-identity

Vervolgens voor python-code waarmee een Azure SDK-clientobject in uw app wordt gemaakt:

1. Importeer de DefaultAzureCredential klasse uit de azure.identity module.
2. Maak een DefaultAzureCredential object.
3. Geef het DefaultAzureCredential object door aan de objectconstructor van de Azure SDK-client.

Een voorbeeld van deze stappen wordt weergegeven in het volgende codesegment.

from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

# Acquire a credential object
token_credential = DefaultAzureCredential()

blob_service_client = BlobServiceClient(
        account_url="https://<my_account_name>.blob.core.windows.net",
        credential=token_credential)

Zoals beschreven in het overzichtsartikel over Azure SDK voor Python-verificatie, DefaultAzureCredential ondersteunt u meerdere verificatiemethoden en bepaalt u de verificatiemethode die tijdens runtime wordt gebruikt. Het voordeel van deze aanpak is dat uw app verschillende verificatiemethoden in verschillende omgevingen kan gebruiken zonder omgevingsspecifieke code te implementeren. Wanneer de voorgaande code wordt uitgevoerd op uw werkstation tijdens lokale ontwikkeling, DefaultAzureCredential gebruikt ofwel een toepassingsservice-principal, zoals wordt bepaald door de omgevingsinstellingen, of de referenties van ontwikkelaarshulpprogramma's om zich te authenticeren met andere Azure-resources. Daarom kan dezelfde code worden gebruikt om uw app te verifiëren bij Azure-resources tijdens zowel lokale ontwikkeling als wanneer deze wordt geïmplementeerd in Azure.