Tildel en arbejdsbelastning identitetsadgang til Azure

  • 6 minutter

En arbejdsbelastningsidentitet kan i sig selv ikke gøre noget i dit Azure-miljø på samme måde, som når en bruger ikke kan arbejde med dine Azure-ressourcer, medmindre vedkommende er autoriseret til at gøre det. I dette undermodul lærer du, hvordan du godkender arbejdsbelastningsidentiteter for at udrulle og konfigurere Azure-ressourcer, samtidig med at du undgår at tildele unødvendige tilladelser.

Godkendelse af arbejdsbelastningsidentitet

Indtil nu har du fokuseret på, hvilke arbejdsbelastningsidentiteter der er, og hvordan de kan bruges til at bevise identiteten af en udrulningsarbejdsproces til Microsoft Entra ID. Det handler om godkendelse.

Når Microsoft Entra ID har godkendt en arbejdsbelastningsidentitet, bliver det næste spørgsmål: Hvad kan denne arbejdsbelastningsidentitet gøre? Dette er begrebet godkendelse. Det er ansvaret for RBAC-systemet (Azure Role Based Access Control), også kaldet IAM (Identity and Access Management). Ved hjælp af Azure RBAC kan du give en arbejdsbelastningsidentitetsadgang til en bestemt ressourcegruppe, et bestemt abonnement eller en bestemt administrationsgruppe.

Seddel

Alt, hvad du gør her, er at bruge Azure RBAC-systemet til at give adgang til at oprette og administrere Azure-ressourcer, f.eks. dine lagerkonti, Azure App Service-planen og virtuelle netværk. Microsoft Entra ID har også sit eget rollesystem, som nogle gange kaldes mapperoller. Du kan bruge disse roller til at tildele tilladelser til arbejdsbelastningsidentiteter til at administrere Microsoft Entra ID. I dette modul beskrives dette emne ikke i dybden, men vær opmærksom på, at udtrykket rolle bruges i begge situationer i visse dokumentationssituationer.

Vælg den rette rolletildeling til arbejdsprocessen

En rolletildeling har tre vigtige dele: hvem rollen er tildelt (den tildelt), hvad de kan gøre (den rolle), og hvilken ressource eller hvilke ressourcer rolletildelingen gælder for (det område).

Befuldmægtigede

Når du arbejder med en arbejdsbelastningsidentitet, tildeler du roller til den. Hvis du vil tildele en rolle, skal du først oprette en tjenesteprincipal, som giver dig mulighed for at tildele dine programroller i Azure. Når du har oprettet tjenesteprincipalen, kan du fortsætte med at arbejde med programregistreringens program-id.

Hvis du vil oprette en tjenesteprincipal, skal du bruge kommandoen az ad sp create og angive programregistreringens app-id:

az ad sp create --id A123b4567c-1234-1a2b-2b1a-1234abc12345

Hvis du vil oprette en tjenesteprincipal, skal du bruge cmdlet'en New-AzADServicePrincipal og angive programregistreringens app-id:

New-AzADServicePrincipal -AppId A123b4567c-1234-1a2b-2b1a-1234abc12345

Rolle

Det kan være lidt mere arbejde at finde ud af, hvilken rolle der skal tildeles. I Azure er der nogle få almindelige roller:

  • Reader: Gør det muligt for modtageren at læse oplysninger om ressourcer, men ikke redigere eller slette dem.
  • bidragyder: Gør det muligt for modtageren at oprette ressourcer og læse og redigere eksisterende ressourcer. Bidragydere kan dog ikke give andre principaler adgang til ressourcer.
  • Ejer: Giver fuld kontrol over ressourcer, herunder tildeling af andre hovedprincipaler adgang.

Forsigtighed

Tildel kun arbejdsbelastningsidentiteter de minimumtilladelser, de skal bruge for at udføre deres job. For det meste er rollen Ejer for eftergivende til en udrulningsarbejdsproces.

Der er også mange specifikke roller, der giver adgang til et undersæt af funktionalitet. Du kan endda oprette din egen brugerdefinerede rolledefinition for at angive den nøjagtige liste over tilladelser, du vil tildele.

Seddel

Brugerdefinerede rolledefinitioner kan være en effektiv måde at give tilladelser til dine Azure-ressourcer på, men de kan være svære at arbejde med. Det er ikke altid nemt at bestemme nøjagtigt, hvilke tilladelser du skal føje til en brugerdefineret rolledefinition. Du kan ved et uheld gøre rolledefinitionerne for restriktive eller for eftergivende.

Hvis du ikke er sikker på, hvad du skal gøre, er det bedst at bruge en af de indbyggede rolledefinitioner. Brugerdefinerede rolledefinitioner ligger uden for dette moduls område.

Omfanget

Du skal bestemme, hvor bredt du tildeler rollen. Denne beslutning påvirker antallet af ressourcer, som arbejdsbelastningsidentiteten kan ændre. Almindelige områder omfatter:

  • enkelt ressource: Du kan give adgang til en bestemt ressource. Udrulningsarbejdsprocesser bruger normalt ikke dette område, fordi en arbejdsproces opretter ressourcer, der ikke findes endnu, eller fordi den omkonfigurerer flere ressourcer.
  • ressourcegruppe: Du kan give adgang til alle ressourcer i en ressourcegruppe. Bidragydere og ejere kan også oprette ressourcer i gruppen. Dette er en god mulighed for mange udrulningsarbejdsprocesser.
  • abonnement: Du kan give adgang til alle ressourcer i et abonnement. Hvis du har flere programmer, arbejdsbelastninger eller miljøer i et enkelt abonnement, kan du tildele tilladelser til abonnementets omfang. Dette er dog normalt for eftergivende for en udrulningsarbejdsproces. Du bør i stedet overveje at tilpasse dine rolletildelinger til ressourcegrupper, medmindre din udrulningsarbejdsproces skal oprette ressourcegrupper.

Husk, at rolletildelinger nedarves. Hvis du tildeler en rolle i et abonnement, har modtageren adgang til hver ressourcegruppe og ressource i det pågældende abonnement.

Valg af den rette rolletildeling

Nu, hvor du forstår komponenterne i en rolletildeling, kan du bestemme de relevante værdier for dine scenarier. Her er nogle generelle retningslinjer, du skal overveje:

  • Brug den mindst tilladte rolle, du kan. Hvis din arbejdsproces kun skal installere grundlæggende Bicep-filer og ikke administrere rolletildelinger, skal du ikke bruge rollen Ejer.

  • Brug det snævreste område, du kan. De fleste arbejdsprocesser skal kun udrulle ressourcer til en ressourcegruppe, så de bør ikke tildeles rolletildelinger, der er begrænset til abonnementer.

  • For mange arbejdsprocesser er en god standardindstilling for en rolletildeling rollen Bidragyder i ressourcegruppens område.

  • Overvej alt, hvad din arbejdsproces gør, og alt, hvad den kan gøre i fremtiden. Du kan f.eks. overveje at oprette en brugerdefineret rolledefinition for dit websteds installationsarbejdsproces og kun tildele tilladelser til App Service og Application Insights. I næste måned skal du muligvis føje en Azure Cosmos DB-konto til din Bicep-fil, men den brugerdefinerede rolle blokerer Azure Cosmos DB-ressourcer fra at blive oprettet.

    I stedet er det ofte bedre at bruge en indbygget rolle eller en kombination af indbyggede roller for at undgå at skulle ændre dine rolledefinitioner gentagne gange. Overvej at bruge Azure Policy til at gennemtvinge dine styringskrav for tilladte tjenester, SKU'er og placeringer.

  • Test arbejdsprocessen for at bekræfte, at rolletildelingen fungerer.

Blanding og matchning af rolletildelinger

Du kan oprette flere rolletildelinger, der giver forskellige tilladelser i forskellige områder. Du kan f.eks. tildele en arbejdsbelastningsidentitet rollen læser med et omfang af hele abonnementet. Du kan tildele den samme arbejdsbelastningsidentitet som bidragyder for en bestemt ressourcegruppe separat. Når arbejdsbelastnings-id'et forsøger at arbejde med ressourcegruppen, anvendes den mere tilladte tildeling.

Arbejde med flere miljøer

Du arbejder sandsynligvis med flere miljøer, f.eks. udviklings-, test- og produktionsmiljøer til dine programmer. Ressourcerne for hvert miljø skal udrulles til forskellige ressourcegrupper eller abonnementer.

Du skal oprette separate arbejdsbelastningsidentiteter for hvert miljø. Tildel hver arbejdsbelastningsidentitet det mindste sæt tilladelser, som den skal bruge til sine udrulninger. Vær især omhyggelig med at undgå at blande tilladelser til produktionsinstallationer med tilladelser til udrulninger til ikke-produktionsmiljøer.

Opret en rolletildeling for en arbejdsbelastningsidentitet

Hvis du vil oprette en rolletildeling for en arbejdsbelastningsidentitet, skal du bruge kommandoen az role assignment create. Du skal angive modtageren, rollen og omfanget:

az role assignment create \
  --assignee A123b4567c-1234-1a2b-2b1a-1234abc12345 \
  --role Contributor \
  --scope "/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite" \
  --description "The deployment workflow for the company's website needs to be able to create resources within the resource group."

Lad os se på hvert argument:

  • --assignee angiver arbejdsbelastningsidentiteten. Du kan angive dette på flere måder, men det er en god idé at bruge program-id'et, da det undgår flertydighed.
  • --role angiver rollen. Hvis du bruger en indbygget rolle, kan du angive den efter navn. Hvis du bruger en brugerdefineret rolledefinition, skal du angive det fulde rolledefinitions-id.
  • --scope angiver området. Dette er normalt et ressource-id for en enkelt ressource, en ressourcegruppe eller et abonnement.
  • --description er en beskrivelse af rolletildelingen, der kan læses af mennesker.

Hvis du vil oprette en rolletildeling for en arbejdsbelastningsidentitet, skal du bruge cmdlet'en New-AzRoleAssignment. Angiv modtageren, rollen og omfanget:

New-AzRoleAssignment `
  -ApplicationId A123b4567c-1234-1a2b-2b1a-1234abc12345 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite' `
  -Description "The deployment workflow for the company's website needs to be able to create resources within the resource group."

Lad os se på hvert argument:

  • -ApplicationId angiver arbejdsbelastningsidentitetens programregistrerings-id.
  • -RoleDefinitionName angiver navnet på en indbygget rolle. Hvis du bruger en brugerdefineret rolledefinition, skal du i stedet angive det fulde rolledefinitions-id ved hjælp af argumentet -RoleDefinitionId.
  • -Scope angiver området. Dette er normalt et ressource-id for en enkelt ressource, en ressourcegruppe eller et abonnement.
  • -Description er en beskrivelse af rolletildelingen, der kan læses af mennesker.

Drikkepenge

Det er en god idé at angive en begrundelse for dine rolletildelinger ved at angive en beskrivelse. En beskrivelse hjælper alle, der gennemser rolletildelingerne senere, med at forstå deres formål og for at forstå, hvordan du har besluttet dig for modtageren, rollen og omfanget.

Seddel

Det kan tage et par minutter at aktivere rolletildelinger.

Tildel adgang ved hjælp af Bicep

Rolletildelinger er Azure-ressourcer. Det betyder, at du kan oprette en rolletildeling ved hjælp af Bicep. Det kan du gøre, hvis du initialiserer dine ressourcegrupper ved hjælp af Bicep og derefter udruller ressourcerne i ressourcegruppen ved hjælp af en arbejdsbelastningsidentitet. Her er et eksempel på Bicep-definition for den foregående rolletildeling:

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(principalId, roleDefinitionId, resourceGroup().id)
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
    principalId: principalId
    description: 'The deployment workflow for the company\'s website needs to be able to create resources within the resource group.'
  }
}

Lad os se på hvert argument:

  • name er et GUID (Globally Unique Identifier) for rolletildelingen. Det er en god idé at bruge funktionen guid() i Bicep til at oprette et GUID. Hvis du vil sikre dig, at du opretter et navn, der er entydigt for hver rolletildeling, skal du bruge hoved-id'et, rolledefinitions-id'et og området som basisargumenterne for funktionen.

  • principalType skal angives til ServicePrincipal.

  • roleDefinitionId er det fuldt kvalificerede ressource-id for den rolledefinition, du tildeler. Du arbejder hovedsageligt med indbyggede roller, så du finder rolledefinitions-id'et i dokumentationen indbyggede Roller i Azure.

    Rollen bidragyder har f.eks. rolledefinitions-id'et b24988ac-6180-42a0-ab88-20f7382dd24c. Når du angiver den i din Bicep-fil, bruger du et fuldt kvalificeret ressource-id, f.eks. /subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c.

  • principalId er tjenesteprincipalens objekt-id. Sørg for, at du ikke bruger program-id'et eller objekt-id'et for programregistreringen.

  • description er en beskrivelse af rolletildelingen, der kan læses af mennesker.