Workload Identity Federation: Deploya till Azure från GitHub Actions utan hemligheter

Problemet med klienthemligheter i CI/CD

Det traditionella sättet att autentisera GitHub Actions mot Azure innebär att skapa en service principal, generera en klienthemlighet och lagra den i GitHub Secrets. Det fungerar, men det har verkliga problem:

• Klienthemligheter förfaller (standard 2 år, ofta satt till 1 år). När de förfaller slutar dina pipelines att fungera tyst vid nästa körning.
• Hemligheten finns som en statisk sträng i GitHub. Alla med repo admin-åtkomst kan läsa den.
• Om hemligheten läcker kan en angripare autentisera som din service principal från var som helst tills du upptäcker det och återkallar.

Workload identity federation löser allt detta. Istället för en lagrad hemlighet presenterar GitHub Actions en kortlivad OIDC-token som Azure verifierar direkt. Inga hemligheter lagras någonstans.

Hur OIDC-federation fungerar

Flödet har tre deltagare:

• GitHub utfärdar en signerad OIDC-token för varje workflow-körning. Token innehåller claims om repository, branch och workflow.
• Entra ID har en federerad credential konfigurerad på appregistreringen som litar på tokens från GitHubs OIDC-provider, men bara för ditt specifika repo och branch.
• azure/login-actionen växlar GitHub-token mot en Azure access token med den federerade credentialen. Ditt workflow kan sedan anropa Azure-API:er.

Token är kortlivad (giltig under workflow-jobbets längd), begränsad till det specifika repot/branchen, och lagras aldrig någonstans.

Steg 1: Skapa appregistrering och federerad credential

Du kan konfigurera detta med Azure CLI:

Subject-claimet styr vilka workflows som kan autentisera. Några vanliga mönster:

• repo:org/repo:ref:refs/heads/main tillåter bara main-branchen
• repo:org/repo:environment:production tillåter bara GitHub Environment "production"
• repo:org/repo:pull_request tillåter pull request-workflows (användbart för plan/preview-steg)

Steg 2: Tilldela Azure-roller

Begränsa rollen till så smal nivå som möjligt. Contributor på en specifik resursgrupp är bättre än Contributor på hela prenumerationen.

Steg 3: Konfigurera GitHub Actions-workflowet

Lägg till tre secrets i ditt GitHub-repository (Settings > Secrets > Actions): AZURE_CLIENT_ID, AZURE_TENANT_ID och AZURE_SUBSCRIPTION_ID. Observera: ingen av dessa är faktiska hemligheter. De är bara identifierare.

De viktigaste delarna:

• permissions.id-token: write talar om för GitHub att generera en OIDC-token för detta workflow
• Inget client-secret-fält i azure/login-steget. Actionen upptäcker OIDC-läge automatiskt när bara client-id, tenant-id och subscription-id anges.

Terraform med OIDC

Om du föredrar att hantera appregistreringen och den federerade credentialen som infrastruktur, här är Terraform-motsvarigheten:

Gamla sättet vs nya sättet

Här är vad du kan ta bort från din uppsattning efter migrering till OIDC:

• Före: Appregistrering + klienthemlighet + AZURE_CREDENTIALS JSON i GitHub Secrets + process för hemligrotation + övervakning av utgångsdatum
• Efter: Appregistrering + federerad credential + tre icke-hemliga ID:n i GitHub. Inget utgångsdatum, ingen rotation, inga lagrade autentiseringsuppgifter.

Migreringen är enkel: skapa den federerade credentialen, uppdatera workflow-filen, ta bort den gamla AZURE_CREDENTIALS-hemligheten från GitHub och radera klienthemligheten från appregistreringen.

Vidare läsning

För mer detaljer, se dokumentationen för workload identity federation och GitHub Actions OIDC med Azure.