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 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 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 beheerde identiteiten : 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-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, 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.
2 - 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 binnen het bereik van de resourcegroep, omdat de meeste toepassingen al hun Azure-resources groeperen in één resourcegroep.
3 - DefaultAzureCredential implementeren in uw toepassing
DefaultAzureCredential
ondersteunt meerdere verificatiemethoden en bepaalt de verificatiemethode die tijdens runtime wordt gebruikt. Op deze manier kan uw app verschillende verificatiemethoden in verschillende omgevingen gebruiken zonder omgevingsspecifieke code te implementeren.
De volgorde en locaties waarin DefaultAzureCredential
wordt gezocht naar referenties, vindt u op DefaultAzureCredential.
Als u wilt implementeren DefaultAzureCredential
, voegt u eerst de Azure.Identity
en eventueel de Microsoft.Extensions.Azure
pakketten toe aan uw toepassing. U kunt dit doen met behulp van de opdrachtregel of de NuGet-Pakketbeheer.
Open een terminalomgeving naar keuze in de projectmap van de toepassing en voer de onderstaande opdracht in.
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure
Azure-services worden over het algemeen geopend met behulp van bijbehorende clientklassen van de SDK. Deze klassen en uw eigen aangepaste services moeten worden geregistreerd in het Program.cs
bestand, zodat ze kunnen worden geopend via afhankelijkheidsinjectie in uw app. Program.cs
Volg de onderstaande stappen om uw service en DefaultAzureCredential
.
- Neem de
Azure.Identity
enMicrosoft.Extensions.Azure
naamruimten op met eenusing
instructie. - Registreer de Azure-service met behulp van relevante helpermethoden.
- Geef een exemplaar van het
DefaultAzureCredential
object door aan deUseCredential
methode.
Een voorbeeld hiervan wordt weergegeven in het volgende codesegment.
using Microsoft.Extensions.Azure;
using Azure.Identity;
// Inside of Program.cs
builder.Services.AddAzureClients(x =>
{
x.AddBlobServiceClient(new Uri("https://<account-name>.blob.core.windows.net"));
x.UseCredential(new DefaultAzureCredential());
});
U kunt ook rechtstreeks in uw services gebruikmaken DefaultAzureCredential
zonder de hulp van aanvullende Azure-registratiemethoden, zoals hieronder wordt weergegeven.
using Azure.Identity;
// Inside of Program.cs
builder.Services.AddSingleton<BlobServiceClient>(x =>
new BlobServiceClient(
new Uri("https://<account-name>.blob.core.windows.net"),
new DefaultAzureCredential()));
Wanneer de bovenstaande code wordt uitgevoerd op uw lokale werkstation tijdens de lokale ontwikkeling, wordt er gezocht in de omgevingsvariabelen voor een toepassingsservice-principal of in Visual Studio, VS Code, de Azure CLI of Azure PowerShell voor een set ontwikkelaarsreferenties, die beide kunnen worden gebruikt om de app tijdens lokale ontwikkeling te verifiëren bij Azure-resources.
Wanneer deze code in Azure wordt geïmplementeerd, kan uw app ook worden geverifieerd bij andere Azure-resources. DefaultAzureCredential
kan omgevingsinstellingen en beheerde identiteitsconfiguraties ophalen om automatisch te verifiëren bij andere services.
Feedback
https://aka.ms/ContentUserFeedback.
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie:Feedback verzenden en weergeven voor