NET-apps verifiëren bij Azure-services tijdens lokale ontwikkeling met behulp van service-principals
Bij het maken van cloudtoepassingen moeten ontwikkelaars fouten opsporen en toepassingen testen op hun lokale werkstation. 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. In dit artikel wordt beschreven hoe u service-principalobjecten voor toegewezen toepassingen instelt die moeten worden gebruikt tijdens lokale ontwikkeling.
Met speciale toepassingsservice-principals voor lokale ontwikkeling kunt u het principe van minimale bevoegdheden tijdens het ontwikkelen van apps volgen. Omdat machtigingen zijn afgestemd op precies wat er nodig is voor de app tijdens de ontwikkeling, wordt voorkomen dat app-code per ongeluk toegang krijgt tot een Azure-resource die is bedoeld voor gebruik door een andere app. Dit voorkomt ook dat er fouten optreden wanneer de app naar productie wordt verplaatst, omdat de app te veel is gemachtigd in de ontwikkelomgeving.
Een toepassingsservice-principal wordt ingesteld voor de app wanneer de app is geregistreerd in Azure. Bij het registreren van apps voor lokale ontwikkeling is het raadzaam het volgende te doen:
- Maak afzonderlijke app-registraties voor elke ontwikkelaar die aan de app werkt. Hiermee maakt u afzonderlijke toepassingsservice-principals voor elke ontwikkelaar die moet worden gebruikt tijdens de lokale ontwikkeling en voorkomt u dat ontwikkelaars referenties voor één toepassingsservice-principal moeten delen.
- Afzonderlijke app-registraties per app maken. Hiermee worden de machtigingen van de app alleen bereikt voor wat de app nodig heeft.
Tijdens lokale ontwikkeling worden omgevingsvariabelen ingesteld met de identiteit van de toepassingsservice-principal. De Azure SDK voor NET leest deze omgevingsvariabelen en gebruikt deze informatie om de app te verifiëren bij de Azure-resources die nodig zijn.
1 - De toepassing registreren in Azure
Toepassingsservice-principalobjecten worden gemaakt met een app-registratie in Azure. U kunt dit doen met behulp van Azure Portal of Azure CLI.
Meld u aan bij Azure Portal en volg deze stappen.
2 - Een Azure AD-beveiligingsgroep maken voor lokale ontwikkeling
Aangezien er doorgaans meerdere ontwikkelaars zijn die aan een toepassing werken, is het raadzaam om een Azure AD-groep te maken om de rollen (machtigingen) die de app nodig heeft in lokale ontwikkeling in te kapselen in plaats van de rollen toe te wijzen aan afzonderlijke service-principal-objecten. Dit biedt de volgende voordelen.
- Elke ontwikkelaar weet zeker dat dezelfde rollen zijn toegewezen omdat rollen op groepsniveau worden toegewezen.
- Als er een nieuwe rol nodig is voor de app, hoeft deze alleen te worden toegevoegd aan de Azure AD-groep voor de app.
- Als een nieuwe ontwikkelaar lid wordt van het team, wordt er een nieuwe toepassingsservice-principal gemaakt voor de ontwikkelaar en toegevoegd aan de groep, zodat de ontwikkelaar over de juiste machtigingen beschikt om aan de app te werken.
3 - Rollen toewijzen aan de toepassing
Vervolgens moet u bepalen welke rollen (machtigingen) uw app nodig heeft voor welke resources en welke rollen aan uw app worden toegewezen. In dit voorbeeld worden de rollen toegewezen aan de Azure Active Directory-groep die in stap 2 is gemaakt. Rollen kunnen aan een resource, resourcegroep of abonnementsbereik worden toegewezen. 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.
4 - Omgevingsvariabelen voor toepassingen instellen
Het DefaultAzureCredential
object zoekt tijdens runtime naar de informatie van de service-principal in een set omgevingsvariabelen. Er zijn meerdere manieren om omgevingsvariabelen te configureren wanneer u met .NET werkt, afhankelijk van uw hulpprogramma's en omgeving.
Ongeacht welke benadering u kiest, moet u de volgende omgevingsvariabelen configureren wanneer u met een service-principal werkt.
AZURE_CLIENT_ID
→ de waarde van de app-id.AZURE_TENANT_ID
→ de waarde van de tenant-id.AZURE_CLIENT_SECRET
→ het wachtwoord/de referentie die voor de app is gegenereerd.
Wanneer u lokaal werkt met Visual Studio, kunnen omgevingsvariabelen worden ingesteld in het launchsettings.json
bestand in de Properties
map van uw project. Wanneer de app wordt gestart, worden deze waarden automatisch opgehaald. Houd er rekening mee dat deze configuraties niet met uw toepassing reizen wanneer deze wordt geïmplementeerd, dus u moet nog steeds omgevingsvariabelen instellen in uw doelhostingomgeving.
"profiles": {
"SampleProject": {
"commandName": "Project",
"dotnetRunMessages": true,
"launchBrowser": true,
"applicationUrl": "https://localhost:7177;http://localhost:5177",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development",
"AZURE_CLIENT_ID": "00000000-0000-0000-0000-000000000000",
"AZURE_TENANT_ID":"11111111-1111-1111-1111-111111111111",
"AZURE_CLIENT_SECRET": "=abcdefghijklmnopqrstuvwxyz"
}
},
"IIS Express": {
"commandName": "IISExpress",
"launchBrowser": true,
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development",
"AZURE_CLIENT_ID": "00000000-0000-0000-0000-000000000000",
"AZURE_TENANT_ID": "11111111-1111-1111-1111-111111111111",
"AZURE_CLIENT_SECRET": "=abcdefghijklmnopqrstuvwxyz"
}
}
}
5 - 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 een using-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