JavaScript-apps die door Azure worden gehost, authenticeren voor Azure-resources met behulp van de Azure Identity-bibliotheek
Wanneer een app wordt gehost in Azure (met behulp van een service zoals Azure App Service, Azure Functions of Azure Container Apps), kunt u een beheerde identiteit gebruiken om uw app veilig te verifiëren bij Azure-resources.
Een beheerde identiteit biedt een identiteit voor uw app, zodat deze verbinding kan maken met andere Azure-resources zonder dat u een geheim hoeft te gebruiken (zoals een verbindingsreeks of sleutel). Intern herkent Azure de identiteit van uw app en weet welke resources de app mag openen. Azure gebruikt deze informatie om automatisch Microsoft Entra-tokens voor de app te verkrijgen, zodat deze verbinding kan maken met andere Azure-resources zonder dat u de verificatiegeheimen hoeft te beheren (creëren of vernieuwen).
Typen beheerde identiteiten
Er zijn twee typen beheerde identiteit:
- Door het systeem toegewezen beheerde identiteiten - één Azure-resource
- Door de gebruiker toegewezen beheerde identiteiten - meerdere Azure-resources
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.
Door het systeem toegewezen beheerde identiteiten voor één resource
Door het systeem toegewezen beheerde identiteiten worden 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. De beheerde identiteit is gekoppeld aan de levenscyclus van de Azure-resource. 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 identiteitstype het eenvoudigste type beheerde identiteit dat moet worden gebruikt.
Door de gebruiker toegewezen beheerde identiteiten voor meerdere resources
Een door de gebruiker toegewezen beheerde identiteit is een zelfstandige Azure-resource. Dit identiteitstype 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. Stel dat uw oplossing toepassingen bevat die worden uitgevoerd op meerdere Exemplaren van App Service en virtuele machines. De toepassingen hebben allemaal toegang nodig tot dezelfde set Azure-resources. Het maken en gebruiken van een door de gebruiker toegewezen beheerde identiteit in deze resources is de beste ontwerpkeuze.
1 - Door het systeem toegewezen beheerde identiteit inschakelen in gehoste app
De eerste stap is het inschakelen van een beheerde identiteit in de Azure-resource die als host fungeert voor uw app. Als u bijvoorbeeld een Express.js-toepassing host met behulp van Azure App Service, moet u beheerde identiteit inschakelen voor die App Service-web-app. Als u een VIRTUELE machine gebruikt om uw app te hosten, stelt u uw VM 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.
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 aan het bereik van de resourcegroep, omdat de meeste toepassingen al hun Azure-resources groeperen in één resourcegroep.
3 - DefaultAzureCredential implementeren in uw toepassing
DefaultAzureCredential detecteert automatisch dat een beheerde identiteit wordt gebruikt en gebruikt de beheerde identiteit om te verifiëren bij andere Azure-resources. Zoals beschreven in de Azure Identity-bibliotheek voor JavaScript-verificatieoverzicht artikel, ondersteunt DefaultAzureCredential
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.
Voeg eerst het @azure/identiteitspakket toe 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 van deze stappen wordt weergegeven in het volgende codesegment.
// connect-with-default-azure-credential.js
import { BlobServiceClient } from '@azure/storage-blob';
import { DefaultAzureCredential } from '@azure/identity';
import 'dotenv/config'
const accountName = process.env.AZURE_STORAGE_ACCOUNT_NAME;
if (!accountName) throw Error('Azure Storage accountName not found');
const blobServiceClient = new BlobServiceClient(
`https://${accountName}.blob.core.windows.net`,
new DefaultAzureCredential()
);