GitHub Actions naar Azure met OIDC zonder deploygeheim

Een bestaande GitHub Actions-workflow kan zonder langdurig Azure-deploygeheim naar Azure Functions publiceren. Maak een door de gebruiker toegewezen managed identity, verbind die via een federatieve credential met de juiste GitHub-job en laat de job via azure/login aanmelden. Microsofts handleiding voor Azure Functions beschrijft deze route met een rol op de function app en een deploy via Azure/functions-action.

Werk in deze volgorde: achterhaal de bestaande credential, maak de Azure-identiteit met beperkte rechten, stel het vertrouwde OIDC-subject in, wijzig de workflow en controleer een deploy. Trek pas daarna de oude credential in. De client-ID, tenant-ID en subscription-ID sturen de login naar de juiste identiteit en subscription; het zijn identificatoren, geen nieuwe langdurige Azure-inloggegevens.

Breng de bestaande deploy in kaart

Bekijk in .github/workflows welke job zich bij Azure aanmeldt en welke stap de applicatie publiceert. Een serviceprincipal kan daarvoor een client secret gebruiken. Bij Azure Functions kan de deployactie ook rechtstreeks een publish profile uit GitHub Secrets ontvangen. Noteer de naam van die secret en zoek waar zij nog meer wordt gebruikt voordat je haar verwijdert of de achterliggende credential intrekt.

Leg vervolgens de doelresource vast. Voor het Functions-voorbeeld is dat de betreffende function app; een rol op de hele subscription is daarvoor doorgaans een te ruime keuze. Kijk ook of de workflow afzonderlijke build- en deployjobs heeft. Alleen de job die zich bij Azure aanmeldt, heeft straks toegang tot een OIDC-token nodig. Als die job een GitHub Environment gebruikt, moet de federatieve credential op die context aansluiten.

Maak een managed identity met beperkte Azure-rechten

Maak in Azure een door de gebruiker toegewezen managed identity voor de deploy en noteer haar client-ID en tenant-ID. Noteer ook de ID van de subscription waarin de function app staat. Ken de identiteit via Azure RBAC de rol Website Contributor toe op de function app zelf. Daarmee begrens je de Azure-kant van de koppeling tot de resource die de job moet publiceren.

Een containerdeploy uit een private Azure Container Registry kan daarnaast een afzonderlijke AcrPull-rol op die registry vereisen. Gebruik je een andere Azure-dienst, bepaal dan de rol vanuit de deploymethode van die dienst; Website Contributor is hier het concrete Functions-voorbeeld. Controleer bestaande roltoewijzingen op dezelfde managed identity, want een passende federatieve credential beperkt wie mag inloggen, terwijl RBAC bepaalt wat de ingelogde identiteit vervolgens kan doen.

Sla de drie ID’s op als GitHub Actions-variabelen, of als secrets wanneer het repositorybeleid dat voorschrijft. Hun opslag als secret maakt ze niet tot een wachtwoord. De federatieve credential en het door GitHub uitgegeven token leveren het bewijs dat de aanmeldende job bij de ingestelde repositorycontext hoort.

Laat de federatieve credential bij de job passen

Een federatieve Azure-credential laat alleen een GitHub Actions-job met een passend OIDC-subject toe.

Voeg aan de managed identity een federatieve credential toe met issuer https://token.actions.githubusercontent.com en audience api://AzureADTokenExchange. Stel het subject in op de context van de deployjob. Voor een job op branch main zonder Environment kan de naamgebaseerde vorm bijvoorbeeld repo:ORG/REPO:ref:refs/heads/main zijn. Kopieer zo’n voorbeeld niet blind: de waarde in Azure moet overeenkomen met de subject-claim die GitHub voor jouw job uitgeeft.

Bij een job met een GitHub Environment zoals production gebruikt het standaard-subject de Environment-naam in plaats van de branch: repo:ORG/REPO:environment:production. Beperk in dat Environment welke branches mogen deployen en voeg zo nodig vereiste reviewers toe. Daarmee blijft de branchbeperking ook werken wanneer het federatieve subject zelf de branch niet noemt.

Volgens GitHubs OIDC-referentie bevatten standaard-subjects van repositories die na 15 juli 2026 zijn aangemaakt ook de owner-ID en repository-ID; oudere repositories behouden de naamgebaseerde vorm tenzij zij overstappen. Ook een hernoeming of overdracht kan de gebruikte vorm veranderen. Controleer daarom de werkelijke subject-vorm van het repository voordat je de Azure-credential vastlegt en pas beide kanten samen aan bij een latere wijziging van branch, repository of Environment.

Geef de deployjob OIDC-recht en wijzig de login

Een GitHub Actions-deployjob meldt zich via OIDC aan en publiceert een pakket naar Azure Functions.

Zet bij de job die azure/login uitvoert permissions op id-token: write. Gebruikt die job actions/checkout, geef haar ook contents: read. Plaats deze rechten bij voorkeur op jobniveau als een afzonderlijke buildjob geen Azure-toegang nodig heeft. id-token: write geeft de job toestemming een GitHub OIDC-token aan te vragen; de Azure-rol geeft pas rechten op de doelresource.

Plaats azure/login vóór Azure/functions-action en geef aan de loginstap client-id, tenant-id en subscription-id door vanuit de opgeslagen GitHub-waarden. De loginstap gebruikt het OIDC-token om een Azure-toegangstoken te verkrijgen. Laat de daaropvolgende Functions-actie de juiste app-name en het juiste package gebruiken. Verwijder het oude publish-profile-veld uit die actie of de eerdere login die nog een client secret gebruikt: anders kan een geslaagde run op de oude aanmeldroute blijven steunen.

Behoud de bestaande buildstappen voor zover zij bij het project passen, maar controleer actie-instellingen die uit een publish-profile-template komen. Microsofts OIDC-migratievoorbeeld laat ook scm-do-build-during-deployment en enable-oryx-build weg. Staat azure/login in een andere job dan de beoogde deployjob, of krijgt de job later een Environment, dan kan het aangevraagde subject afwijken van de federatieve credential in Azure.

Controleer de deploy en trek de oude credential in

Start een run via de bedoelde branch of het bedoelde Environment. Controleer achtereenvolgens of azure/login slaagt, of Azure/functions-action de juiste function app en het juiste pakket gebruikt, en of de publicatie slaagt. Een geslaagde deploy toont dat deze route werkt; bekijk daarnaast de federatieve credentials en RBAC-toewijzingen op de managed identity om te zien welke andere jobs toegang zouden kunnen krijgen. Zet het ruwe OIDC-token of Azure-toegangstoken niet in de logs.

Verwijder na die controle de oude GitHub-secret en trek de oorspronkelijke credential bij Azure in. Verwijder een ongebruikte client secret uit de betreffende Entra-appregistratie. Kwam de deploy uit een publish profile, reset dan de bijbehorende publicatiegegevens van de app: Microsofts uitleg over publicatiegegevens beschrijft dat een reset bestaande automatisering met dat profiel onderbreekt. Ga daarom eerst na of een andere workflow of integratie dezelfde gegevens gebruikt. Alleen de GitHub-secret wissen maakt een eerder gekopieerd geheim niet ongeldig.