Door Azure gehoste apps verifiëren bij Azure-resources met de Azure SDK voor .NET

Wanneer een app wordt gehost in Azure met behulp van een service zoals Azure-app Service, Azure Virtual Machines of Azure Container Instances, is de aanbevolen benadering voor het verifiëren van een app voor Azure-resources het gebruik van een 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 verbinding mag worden gemaakt. 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.

Typen beheerde identiteiten

Er zijn twee typen beheerde identiteit:

• Door het systeem toegewezen : 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 Azure-resource waaraan deze is gekoppeld. Als de resource wordt verwijderd, wordt de identiteit automatisch verwijderd. Omdat u alleen beheerde identiteit moet inschakelen voor de Azure-resource die als host fungeert voor uw code, is dit het eenvoudigste type beheerde identiteit dat u kunt gebruiken.
• Door de gebruiker toegewezen : u kunt ook een beheerde identiteit maken als een zelfstandige Azure-resource. Dit wordt het meest 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 zijn uitgevoerd op meerdere Exemplaren van App Service en virtuele machines die allemaal toegang nodig hadden tot dezelfde set Azure-resources, zou het maken en gebruiken van een door de gebruiker toegewezen beheerde identiteit voor deze resources zinvol zijn.

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.

1 - 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 .NET-app 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, zou u uw VM in staat stellen 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-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 in Aan. Selecteer Opslaan. In een bevestigingsvenster wordt gecontroleerd of u beheerde identiteit voor uw service wilt inschakelen. Antwoord Ja en beheerde identiteit worden ingeschakeld voor de Azure-resource.

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>. Hieronder ziet u specifieke opdrachten voor populaire Azure-services.

Azure App Service

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

Azure Virtual Machines

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

De uitvoer ziet er als volgt uit.

{
  "principalId": "99999999-9999-9999-9999-999999999999",
  "tenantId": "33333333-3333-3333-3333-333333333333",
  "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 in de volgende stap nodig hebt.

2 - Rollen toewijzen aan de beheerde identiteit

Bepaal vervolgens welke rollen (machtigingen) uw app nodig heeft en wijs de beheerde identiteit toe 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 binnen het bereik van de resourcegroep, omdat de meeste toepassingen al hun Azure-resources groeperen in één resourcegroep.

Azure-portal

Instructies	Schermafbeelding
Zoek de resourcegroep voor uw app 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.
Selecteer op de pagina voor de resourcegroep toegangsbeheer (IAM) in het menu aan de linkerkant.
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 app. Selecteer Selecteren onderaan het dialoogvenster om door te gaan.
De beheerde identiteit wordt nu weergegeven als geselecteerd in 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.

Azure-CLI

Aan een beheerde identiteit wordt een rol in Azure toegewezen met behulp van de opdracht az role assignment create :

az role assignment create \
    --assignee "{managedIdentityId}" \
    --role "{roleName}" \
    --scope "{scope}"

Als u de rolnamen wilt ophalen waaraan een service-principal kan worden toegewezen, gebruikt u de opdracht az role definition list :

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 99999999-9999-9999-9999-999999999999 lees-, schrijf- en verwijdertoegang tot Azure Storage-blobcontainers en -gegevens voor alle opslagaccounts in de resourcegroep msdocs-dotnet-sdk-auth-auth-example , 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 99999999-9999-9999-9999-999999999999 \
    --role "Storage Blob Data Contributor" \
    --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/msdocs-dotnet-sdk-auth-example"

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.

3 - DefaultAzureCredential implementeren in uw toepassing

DefaultAzureCredential is een geordende volgorde van mechanismen voor verificatie bij Microsoft Entra. Elk verificatiemechanisme is een klasse die is afgeleid van de TokenCredential-klasse en wordt een referentie genoemd. Tijdens runtime DefaultAzureCredential wordt geprobeerd om te verifiëren met behulp van de eerste referentie. Als deze referentie geen toegangstoken kan verkrijgen, wordt de volgende referentie in de reeks geprobeerd, enzovoort, totdat een toegangstoken is verkregen. Op deze manier kan uw app verschillende referenties in verschillende omgevingen gebruiken zonder omgevingsspecifieke code te schrijven.

De volgorde en locaties waarin DefaultAzureCredential wordt gezocht naar referenties, vindt u op DefaultAzureCredential.

Als u dit wilt gebruiken DefaultAzureCredential, voegt u de Azure.Identity en eventueel de Microsoft.Extensions.Azure-pakketten toe aan uw toepassing:

Opdrachtregel

Navigeer in een terminal van uw keuze naar de projectmap van de toepassing en voer de volgende opdrachten uit:

dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure

NuGet Package Manager

Klik met de rechtermuisknop op uw project in het Venster Solution Explorer van Visual Studio en selecteer NuGet-pakketten beheren. Zoek naar Azure.Identity en installeer het overeenkomende pakket. Herhaal dit proces voor het Pakket Microsoft.Extensions.Azure .

Azure-services worden geopend met behulp van gespecialiseerde clientklassen uit de verschillende Azure SDK-clientbibliotheken. Deze klassen en uw eigen aangepaste services moeten worden geregistreerd, zodat ze kunnen worden geopend via afhankelijkheidsinjectie in uw app. Voer Program.csin de volgende stappen de volgende stappen uit om een clientklasse te registreren en DefaultAzureCredential:

1. Neem de Azure.Identity en Microsoft.Extensions.Azure naamruimten op via using instructies.
2. Registreer de Azure-serviceclient met behulp van de bijbehorende Add-voorvoegselextensiemethode.
3. Geef een exemplaar van DefaultAzureCredential de UseCredential methode door.

Voorbeeld:

using Microsoft.Extensions.Azure;
using Azure.Identity;

builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddBlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"));
    clientBuilder.UseCredential(new DefaultAzureCredential());
});

Een alternatief UseCredential is om rechtstreeks te instantiëren DefaultAzureCredential :

using Azure.Identity;

builder.Services.AddSingleton<BlobServiceClient>(_ =>
    new BlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"),
        new DefaultAzureCredential()));

Wanneer de voorgaande code wordt uitgevoerd op uw lokale ontwikkelwerkstation, wordt er gezocht in de omgevingsvariabelen voor een toepassingsservice-principal of in lokaal geïnstalleerde ontwikkelhulpprogramma's, zoals Visual Studio, voor een set ontwikkelaarsreferenties. Beide benaderingen kunnen worden gebruikt om de app te verifiëren bij Azure-resources tijdens lokale ontwikkeling.

Wanneer deze code wordt geïmplementeerd in Azure, kan dezelfde code uw app ook verifiëren bij andere Azure-resources. DefaultAzureCredential kan omgevingsinstellingen en beheerde identiteitsconfiguraties ophalen om automatisch te verifiëren bij andere services.