JavaScript-apps verifiëren bij Azure-services tijdens lokale ontwikkeling met behulp van service-principals
Wanneer u cloudtoepassingen maakt, 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. Met deze methode voorkomt u 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. Met deze methode maakt u afzonderlijke toepassingsservice-principals voor elke ontwikkelaar die moet worden gebruikt tijdens 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 JavaScript 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 service-principals maken met behulp van Azure Portal of Azure CLI.
Meld u aan bij Azure Portal en volg deze stappen.
2 - Een Microsoft Entra-beveiligingsgroep maken voor lokale ontwikkeling
Aangezien er doorgaans meerdere ontwikkelaars zijn die aan een toepassing werken, is het raadzaam om een Microsoft Entra-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 Microsoft Entra-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 Microsoft Entra-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 aan het bereik van de resourcegroep, omdat de meeste toepassingen al hun Azure-resources groeperen in één resourcegroep.
4 - Omgevingsvariabelen voor lokale ontwikkeling instellen
Het DefaultAzureCredential
object zoekt tijdens runtime naar de informatie van de service-principal in een set omgevingsvariabelen. Omdat de meeste ontwikkelaars aan meerdere toepassingen werken, is het raadzaam om een pakket zoals dotenv te gebruiken voor toegang tot de omgeving vanuit een .env
bestand dat tijdens de ontwikkeling in de map van de toepassing is opgeslagen. Dit is het bereik van de omgevingsvariabelen die worden gebruikt voor het verifiëren van de toepassing bij Azure, zodat ze alleen door deze toepassing kunnen worden gebruikt.
Het .env
bestand wordt nooit ingecheckt bij broncodebeheer omdat het de geheime sleutel van de toepassing voor Azure bevat. Het standaard .gitignore-bestand voor JavaScript sluit het .env
bestand automatisch uit van het inchecken.
Als u het dotenv
pakket wilt gebruiken, installeert u eerst het pakket in uw toepassing.
npm install dotenv
Maak vervolgens een .env
bestand in de hoofdmap van uw toepassing. Stel de omgevingsvariabelewaarden als volgt in met waarden die zijn verkregen uit het app-registratieproces:
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.
AZURE_CLIENT_ID=00001111-aaaa-2222-bbbb-3333cccc4444
AZURE_TENANT_ID=ffffaaaa-5555-bbbb-6666-cccc7777dddd
AZURE_CLIENT_SECRET=Aa1Bb~2Cc3.-Dd4Ee5Ff6Gg7Hh8Ii9_Jj0Kk1Ll2
Gebruik ten slotte in de opstartcode voor uw toepassing de dotenv
bibliotheek om de omgevingsvariabelen uit het bestand bij het .env
opstarten te lezen.
import 'dotenv/config'
5 - DefaultAzureCredential implementeren in uw toepassing
Als u Azure SDK-clientobjecten wilt verifiëren bij Azure, moet uw toepassing de DefaultAzureCredential
klasse van het @azure/identity
pakket gebruiken. In dit scenario DefaultAzureCredential
detecteert u de omgevingsvariabelen AZURE_CLIENT_ID
en AZURE_CLIENT_SECRET
AZURE_TENANT_ID
worden deze variabelen ingesteld en gelezen om de service-principalgegevens van de toepassing op te halen om verbinding te maken met Azure.
Begin met het toevoegen van het @azure/identiteitspakket aan uw toepassing.
npm install @azure/identity
Voor elke JavaScript-code waarmee een Azure SDK-clientobject in uw app wordt gemaakt, wilt u het volgende doen:
- Importeer de
DefaultAzureCredential
klasse uit de@azure/identity
module. - Maak een
DefaultAzureCredential
object. - Geef het
DefaultAzureCredential
object door aan de objectconstructor van de Azure SDK-client.
Een voorbeeld hiervan wordt weergegeven in het volgende codesegment.
// Azure authentication dependency
import { DefaultAzureCredential } from '@azure/identity';
// Azure resource management dependency
import { SubscriptionClient } from "@azure/arm-subscriptions";
// Acquire credential
const tokenCredential = new DefaultAzureCredential();
async function listSubscriptions() {
try {
// use credential to authenticate with Azure SDKs
const client = new SubscriptionClient(tokenCredential);
// get details of each subscription
for await (const item of client.subscriptions.list()) {
const subscriptionDetails = await client.subscriptions.get(
item.subscriptionId
);
/*
Each item looks like:
{
id: '/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e',
subscriptionId: 'aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e',
displayName: 'YOUR-SUBSCRIPTION-NAME',
state: 'Enabled',
subscriptionPolicies: {
locationPlacementId: 'Internal_2014-09-01',
quotaId: 'Internal_2014-09-01',
spendingLimit: 'Off'
},
authorizationSource: 'RoleBased'
},
*/
console.log(subscriptionDetails);
}
} catch (err) {
console.error(JSON.stringify(err));
}
}
listSubscriptions()
.then(() => {
console.log("done");
})
.catch((ex) => {
console.log(ex);
});
DefaultAzureCredential
detecteert automatisch het verificatiemechanisme dat is geconfigureerd voor de app en haalt de benodigde tokens op om de app bij Azure te verifiëren. Als een toepassing gebruikmaakt van meer dan één SDK-client, kan hetzelfde referentieobject worden gebruikt voor elk SDK-clientobject.