Opret en arbejdsbelastningsidentitet for en GitHub-handlingsarbejdsproces

  • 5 minutter

Nu, hvor du forstår begrebet arbejdsbelastningsidentitet, undrer du dig måske over, hvordan du opretter en og sammenkæder den med en arbejdsproces til udrulning af GitHub-handlinger. I dette undermodul kan du se de trin, du skal udføre for at opnå dette.

Opret et Microsoft Entra-program

I det foregående undermodul har du lært, at arbejdsbelastningsidentiteter kræver oprettelse af en programregistrering i Microsoft Entra ID.

Seddel

Oprettelse og ændring af programregistreringer kræver, at du har tilladelser i Microsoft Entra ID. I nogle organisationer skal du muligvis have en administrator til at udføre disse trin for dig.

Når du opretter en programregistrering, skal du angive et vist navn. Det viste navn er et navn, der kan læses af mennesker, og som beskriver programregistreringen.

Drikkepenge

Brug et klart, beskrivende vist navn til programregistreringen. Det er vigtigt at hjælpe dit team med at forstå, hvad programregistreringen er til, så ingen ved et uheld sletter den eller ændrer dens tilladelser.

Her er et eksempel på en Azure CLI-kommando til oprettelse af et nyt Microsoft Entra-program:

az ad app create --display-name $applicationRegistrationName

Her er et eksempel på en Azure PowerShell-kommando til oprettelse af et nyt Microsoft Entra-program:

New-AzADApplication -DisplayName $applicationRegistrationName

Outputtet af den foregående kommando indeholder vigtige oplysninger, herunder:

  • program-id: Programregistreringen har et entydigt id, ofte kaldet et program-id eller nogle gange et klient-id. Du bruger dette id, når din arbejdsproces skal logge på Azure.
  • objekt-id: Programregistreringen har et objekt-id, som er et entydigt id, som Microsoft Entra-id tildeler. Du får vist et eksempel på, hvordan du bruger et objekt-id senere i dette modul.

Når du opretter en programregistrering, angiver du normalt kun det viste navn. Azure tildeler automatisk de andre navne og id'er.

Forsigtighed

Et vist navn er ikke entydigt. Flere programregistreringer kan dele det samme viste navn. Vær forsigtig, når du tildeler tilladelser til en programregistrering ved hjælp af det viste navn til at identificere det. Du kan ved et uheld give tilladelser til forkerte programregistreringer. Det er en god idé at bruge en af de entydige id'er i stedet for.

Legitimationsoplysninger i organisationsnetværk

Når en identitet skal kommunikere med Azure, logger den på Microsoft Entra ID. En programregistrering tillader i sig selv ikke, at en arbejdsproces eller et program logger på Azure. Du skal først tildele nogle legitimationsoplysninger. legitimationsoplysninger i organisationsnetværket er én type legitimationsoplysninger for programmet. I modsætning til de fleste legitimationsoplysninger kræver legitimationsoplysninger i organisationsnetværket ikke, at du administrerer hemmeligheder som adgangskoder eller nøgler.

Når du opretter legitimationsoplysninger i organisationsnetværket for en udrulningsarbejdsproces, fortæller du effektivt Microsoft Entra ID og GitHub, at de skal have tillid til hinanden. Denne tillid kaldes en federation.

Når din arbejdsproces derefter forsøger at logge på, indeholder GitHub oplysninger om, at arbejdsprocessen kører, så Microsoft Entra ID kan beslutte, om logonforsøget skal tillades. De oplysninger, som GitHub leverer til Microsoft Entra ID under hvert logonforsøg, kan omfatte følgende felter:

  • GitHub-brugerens eller organisationens navn.
  • Navnet på GitHub-lageret.
  • Den gren af lageret, som arbejdsprocessen kører på.
  • Det miljø, som dit arbejdsprocesjob er rettet mod. Du får mere at vide om miljøer i et fremtidigt modul.
  • Angiver, om oprettelsen af en pullanmodning udløste arbejdsprocessen.

Du kan konfigurere Microsoft Entra ID til at tillade eller afvise et logonforsøg fra GitHub, afhængigt af værdierne for de egenskaber, der er angivet tidligere. Du kan f.eks. gennemtvinge følgende politikker:

  • Tillad kun logonforsøg, når en arbejdsproces kører fra et bestemt GitHub-lager i min organisation.
  • Tillad kun logonforsøg, når en arbejdsproces kører fra et bestemt GitHub-lager i min organisation, og forgreningsnavnet er hovednavnet.

Her er en illustration af, hvordan en udrulningsarbejdsproces kan logge på ved hjælp af en arbejdsbelastningsidentitet og legitimationsoplysninger i organisationsnetværket:

diagram, der viser logonprocessen for en arbejdsbelastningsidentitet og legitimationsoplysninger i organisationsnetværket.

De trin, der er involveret i logonprocessen, er:

  1. Når din arbejdsproces skal kommunikere med Azure, kontakter GitHub sikkert Microsoft Entra ID for at anmode om et adgangstoken. GitHub indeholder oplysninger om GitHub-organisationen (my-github-user), lageret (my-repo) og den forgrening, som arbejdsprocessen kører på (main). Det omfatter også dit lejer-id i Microsoft Entra ID, program-id'et for arbejdsprocesidentitetens programregistrering og det Azure-abonnements-id, som din arbejdsproces vil udrulle til.

  2. Microsoft Entra ID validerer program-id'et og kontrollerer, om der findes legitimationsoplysninger i organisationsnetværket i programmet for GitHub-organisationen, -lageret og -forgreningen.

  3. Når Microsoft Entra ID bestemmer, at anmodningen er gyldig, udsteder den et adgangstoken. Din arbejdsproces bruger adgangstokenet, når den kommunikerer med Azure Resource Manager.

Opret et organisationsnetværkslegitimationsoplysninger

Når du bruger Kommandolinjegrænsefladen i Azure, definerer du en legitimationsoplysninger i organisationsnetværket ved at oprette en JSON-fil eller -variabel. Se f.eks. følgende JSON-fil:

{
  "name": "MyFederatedCredential",
  "issuer": "https://token.actions.githubusercontent.com",
  "subject": "repo:my-github-user/my-repo:ref:refs/heads/main",
  "audiences": [
    "api://AzureADTokenExchange"
  ]
}

I denne fil angiver egenskaben subject, at legitimationsoplysningerne i organisationsnetværket kun skal være gyldige, når en arbejdsproces kører i følgende situationer:

Mark Værdi
GitHub-organisationsnavn my-github-user
Navn på GitHub-lager my-repo
Forgreningsnavn main

Når du har oprettet en politik i JSON og gemt den i en fil med navnet policy.json, kan du bruge kommandolinjegrænsefladen i Azure til at oprette legitimationsoplysningerne i organisationsnetværket:

az ad app federated-credential create \
  --id $applicationRegistrationObjectId \
  --parameters @policy.json

Når du bruger Azure PowerShell, definerer du legitimationsoplysninger i organisationsnetværket ved at oprette en streng, der ligner følgende:

$policy = "repo:my-github-user/my-repo:ref:refs/heads/main"

Den foregående streng angiver, at legitimationsoplysningerne i organisationsnetværket kun skal være gyldige, når en arbejdsproces kører i følgende situationer:

Mark Værdi
GitHub-organisationsnavn my-github-user
Navn på GitHub-lager my-repo
Forgreningsnavn main

Når du har oprettet en politikstreng, kan du bruge Azure PowerShell til at oprette legitimationsoplysningerne i organisationsnetværket:

New-AzADAppFederatedCredential `
  -Name 'MyFederatedCredential' `
  -ApplicationObjectId $applicationRegistrationObjectId `
  -Issuer 'https://token.actions.githubusercontent.com' `
  -Audience 'api://AzureADTokenExchange' `
  -Subject $policy

Administrer livscyklussen for din arbejdsbelastningsidentitet

Det er vigtigt at overveje hele livscyklussen for hver arbejdsbelastningsidentitet, du opretter. Når du opretter en arbejdsbelastningsidentitet for en udrulningsarbejdsproces, hvad sker der så, hvis arbejdsprocessen slettes eller ikke længere bruges?

Arbejdsbelastningsidentiteter og legitimationsoplysninger i organisationsnetværket fjernes ikke automatisk, så du skal overvåge og fjerne gamle. Selvom arbejdsbelastningsidentiteterne for din udrulningsarbejdsproces ikke har hemmelige legitimationsoplysninger, der kan genbruges, er det stadig bedst at fjerne dem, når de ikke længere er nødvendige. På den måde er der ingen chance for, at nogen kan oprette et andet GitHub-lager med det samme navn og uventet få adgang til dit Azure-miljø.

Det er en god idé at dokumentere dine arbejdsbelastningsidentiteter på et sted, som du og dit team nemt kan få adgang til. Medtag følgende oplysninger for hver arbejdsbelastningsidentitet:

  • Nøgleident identificerende oplysninger, f.eks. navn og program-id
  • Dens formål
  • Hvem har oprettet den, hvem der er ansvarlig for at administrere den, og hvem der kan have svar, hvis der er et problem
  • De tilladelser, den har brug for, og en klar begrundelse for, hvorfor den har brug for dem
  • Den forventede levetid

Du bør regelmæssigt overvåge dine arbejdsbelastningsidentiteter for at sikre, at de stadig bruges, og at de tilladelser, de er blevet tildelt, stadig er korrekte.