Tildel en tjenesteprincipal adgang til Azure

  • 6 minutter

En tjenesteprincipal kan i sig selv ikke gøre noget i dit Azure-miljø. Det er 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 giver tjenesteprincipaler tilladelse til at udrulle og konfigurere Azure-ressourcer, samtidig med at du undgår at tildele unødvendige tilladelser.

Seddel

Kommandoerne i dette undermodul vises for at illustrere begreber. Kør ikke kommandoerne endnu. Du skal snart øve dig i det, du lærer her.

Godkendelse af tjenesteprincipal

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

Når Microsoft Entra ID har godkendt en tjenesteprincipal, bliver det næste spørgsmål: Hvad kan denne tjenesteprincipal 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 tjenesteprincipal adgang 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, 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 tjenesteprincipaler til at administrere Microsoft Entra-id. I dette modul beskrives dette emne ikke detaljeret, men vær opmærksom på, at begrebet rolle kan bruges til begge situationer i nogle dokumentationssituationer.

Vælg den rette rolletildeling til din pipeline

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 tjenesteprincipal, tildeler du roller for den pågældende tjenesteprincipal. Du kan bruge tjenesteprincipalens program-id til at identificere den korrekte tjenesteprincipal for den pågældende bruger.

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, som gør det muligt for modtageren at læse oplysninger om ressourcer, men ikke redigere eller slette dem.
  • Bidragyder, som 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, som giver fuld kontrol over ressourcer, herunder tildeling af andre hovedprincipaler adgang.

Forsigtighed

Du bør kun give tjenesteprincipaler de minimumtilladelser, de skal bruge for at udføre deres job. For det meste er rollen Ejer for eftergivende til en udrulningspipeline.

Der er også mange specifikke roller, der kun giver adgang til en delmængde af funktionalitet. Du kan også 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, og du kan ved et uheld gøre rolledefinitionerne for restriktive eller for tilladte. Hvis du ikke er sikker på, hvad du skal gøre, er det bedst at bruge en af de indbyggede rolledefinitioner i stedet. 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 tjenesteprincipalen kan ændre. Almindelige områder omfatter:

  • enkelt ressource: Du kan kun give adgang til en bestemt ressource. Udrulningspipelines bruger normalt ikke dette område, fordi en pipeline 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 udrulningspipelines.
  • 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 udrulningspipeline. Du bør i stedet overveje at tilpasse dine rolletildelinger til ressourcegrupper, medmindre selve udrulningsarbejdsprocessen 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 pipeline kun skal udrulle grundlæggende Bicep-skabeloner og ikke administrere rolletildelinger, skal du ikke bruge rollen Ejer.
  • Brug det snævreste område, du kan. De fleste pipelines behøver kun at udrulle ressourcer til en ressourcegruppe, så de bør ikke tildeles rolletildelinger, der er begrænset til abonnementer.
  • For mange pipelines er en god standardindstilling for en rolletildeling rollen Bidragyder i ressourcegruppens område.
  • Overvej alt, hvad din pipeline gør, og alt, hvad den kan gøre i fremtiden. Du kan f.eks. overveje at oprette en brugerdefineret rolledefinition for dit websteds udrulningspipeline 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 pipelinen 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 tjenesteprincipal rollen Læser med et omfang af hele abonnementet og derefter separat tildele den samme tjenesteprincipal rollen Bidragyder for en bestemt ressourcegruppe. Når tjenesteprincipalen 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 tjenesteprincipaler for hvert miljø og tildele hver tjenesteprincipal det minimumsæt af tilladelser, der skal bruges til udrulningerne. 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 tjenesteprincipal

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

az role assignment create \
  --assignee 00001111-aaaa-2222-bbbb-3333cccc4444 \
  --role Contributor \
  --scope "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyWebsite" \
  --description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

Lad os se på hvert argument:

  • --assignee angiver tjenesteprincipalen. For at undgå flertydighed er det en god idé at bruge program-id'et.
  • --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 tjenesteprincipal, skal du bruge cmdlet'en New-AzRoleAssignment. Du skal angive modtageren, rollen og omfanget:

New-AzRoleAssignment `
  -ApplicationId 00001111-aaaa-2222-bbbb-3333cccc4444 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyWebsite' `
  -Description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

Lad os se på hvert argument:

  • -ApplicationId angiver tjenesteprincipalens 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.

Opret en tjenesteprincipal og rolletildeling i én handling

Du kan også oprette en rolletildeling på samme tid, som du opretter en tjenesteprincipal. Koden svarer til den kommando, du brugte til at oprette en tjenesteprincipal i de forrige enheder, men med nogle yderligere argumenter:

az ad sp create-for-rbac \
  --name MyPipeline \
  --role Contributor \
  --scopes "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite"

$servicePrincipal = New-AzADServicePrincipal `
  -DisplayName MyPipeline `
  -Role Contributor `
  -Scope '/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite'

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 tjenesteprincipal. Her er et eksempel på Bicep-definitionen for rolletildelingen ovenfor:

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2023-04-01-preview' = {
  name: guid(principalId, roleDefinitionId, resourceGroup().id)
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
    principalId: principalId
    description: 'The deployment pipeline 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 entydigt id for rolletildelingen. Dette skal være i form af et GUID (Globally Unique Identifier). Det er en god idé at bruge funktionen guid() i Bicep til at oprette et GUID og bruge hoved-id'et, rolledefinitions-id'et og området som basisargumenter for funktionen for at sikre, at du opretter et navn, der er entydigt for hver rolletildeling.
  • principalType skal angives til ServicePrincipal.
  • roleDefinitionId er det fuldt kvalificerede ressource-id for den rolledefinition, du tildeler. Du arbejder hovedsageligt med indbyggede roller, og 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 det i din Bicep-fil, skal du udtrykke dette ved hjælp af et fuldt kvalificeret ressource-id, f.eks. /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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.