Implementing OIDC federation for UczSięWNecie

1. Potrzeba wdrożenia

Projekt „UczSięWNecie” miał dostarczyć nowoczesną infrastrukturę CI/CD w Azure, opartą na Terraformie i GitHub Actions.

Kluczowym wymaganiem było zwiększenie bezpieczeństwa i wyeliminowanie statycznych sekretów, takich jak ARM_CLIENT_SECRET czy hasło Service Principala.

Zamiast przekazywać hasła w GitHub Secrets, postanowiłem wdrożyć federację OIDC – GitHub Actions uwierzytelnia się tokenem JWT wystawionym przez GitHub i zweryfikowanym przez Entra ID.

2. Pierwsze podejście — automatyzacja z Terraformem

Pierwszy pomysł zakładał pełną automatyzację w module Terraform github_oidc. Miał on:

• utworzyć rejestrację aplikacji w Azure AD,
• dodać Federated Identity Credential pomiędzy GitHub i Azure,
• przypisać role Contributor oraz Storage Blob Data Contributor.

Wystarczyć miał pojedynczy terraform apply, aby całość zadziałała end-to-end.

Na przeszkodzie stanęły jednak trzy błędy:

1. Authorization_RequestDenied (403) – konto wykonujące Terraform nie miało ról Application Administrator / Global Administrator w Entra ID.
2. Niezgodność atrybutów (application_id vs application_object_id) między wersjami providera azuread – API zwracało samo {id}, a moduł oczekiwał ścieżki /applications/{id}.
3. Błędny subject w konfiguracji federacji – dopiero dokładny ciąg repo:Tobisof/uczsiewnecie:ref:refs/heads/main pozwala GitHub Actions na autoryzację.

Logicznie moduł był poprawny, ale bez dodatkowych uprawnień i właściwych claimów automatyzacja nie doszła do skutku.

3. Drugie podejście — nauka i konfiguracja przez GUI

Po analizie błędów przeszedłem do portalu Azure, żeby zrozumieć każdy element federacji i zbudować go ręcznie:

1. App Registration w Entra ID – utworzenie aplikacji gha-uczsiewnecie i zapisanie identyfikatorów klienta oraz dzierżawy.
2. Dodanie Federated Credential w zakładce Certificates & secrets → Federated credentials z issuerem https://token.actions.githubusercontent.com, subjectem repo:Tobisof/uczsiewnecie:ref:refs/heads/main i audience api://AzureADTokenExchange.
3. Nadanie ról w Azure: Contributor na poziomie subskrypcji oraz Storage Blob Data Contributor dla grupy zasobów z backendem Terraform.
4. (Opcjonalnie) Udzielenie zgody administratora w Enterprise Applications, jeśli tenant tego wymagał.

4. Działanie po konfiguracji

• Każdy pipeline GitHub Actions otrzymuje token OIDC z token.actions.githubusercontent.com.
• azure/login@v2 wymienia token na tymczasowy access token w Entra ID.
• Terraform loguje się z parametrem use_oidc=true, więc plan/apply/destroy działają bez sekretów.
• Operacje – w tym zapis tfstate – wykonują się automatycznie i bez błędów.

Wnioski praktyczne

• Konfiguracja w GUI pomaga zrozumieć strukturę OIDC, którą później odzwierciedla Terraform.
• Skoro federacja już istnieje, Terraform może ją tylko odczytywać zamiast tworzyć ponownie.
• W module warto dodać logikę warunkową: jeśli aplikacja istnieje – wykorzystaj ją, nie twórz kolejnej.

Podsumowanie

Projekt przeszedł pełną ścieżkę nauki i wdrożenia OIDC:

1. od próby pełnej automatyzacji Terraformem,
2. przez błędy autoryzacji i ograniczenia Entra ID,
3. po ręczną konfigurację federacji w portalu.

Dziś pipeline GitHub Actions loguje się do Azure bez sekretów – bezpiecznie, automatycznie i zgodnie z zasadą „zero secrets in CI/CD”.