OIDC w CI/CD: bezpieczna tożsamość workloadów

OIDC w CI/CD pozwala pipeline’owi otrzymać krótkotrwałe poświadczenie chmurowe bez zapisywania wieloletniego klucza w sekretach repozytorium. Nie jest to jednak automatyczna gwarancja bezpieczeństwa. Źle zdefiniowana relacja zaufania może pozwolić dowolnemu repozytorium, gałęzi albo środowisku tego samego emitenta uzyskać rolę produkcyjną. Skuteczny projekt wiąże token z konkretnym emitentem, odbiorcą, organizacją, repozytorium, refem lub chronionym środowiskiem, a następnie ogranicza uprawnienia sesji po stronie chmury.

Ten przewodnik pokazuje, jak zaprojektować i przetestować federację GitHub Actions lub innego systemu CI z AWS, Microsoft Entra ID i Google Cloud. Celem nie jest tylko usunięcie sekretu, lecz zbudowanie weryfikowalnej granicy zaufania, którą da się monitorować, rotować i bezpiecznie odwołać.

Co faktycznie zmienia OIDC w pipeline

W klasycznym modelu pipeline odczytuje z magazynu sekretów klucz dostępu albo sekret aplikacji. Poświadczenie może być ważne przez miesiące, a jego skopiowanie często wystarcza do użycia poza CI. W modelu federacyjnym job prosi dostawcę CI o podpisany token OIDC. Chmura weryfikuje podpis i claims, a następnie wydaje własne, krótkotrwałe poświadczenie sesyjne.

Przepływ ma cztery granice:

workflow otrzymuje prawo do żądania tokenu OIDC;
emitent CI podpisuje token opisujący bieżący job;
dostawca chmury porównuje iss, aud, sub i dodatkowe claims z polityką zaufania;
usługa tokenowa wydaje sesję ograniczoną rolą, zakresem i czasem życia.

OIDC usuwa sekret długoterminowy, ale nie usuwa ryzyka przejęcia workflow. Jeżeli atakujący może zmienić plik pipeline’u, uruchomić job w zaufanym kontekście i spełnić warunki federacji, otrzyma legalny token. Dlatego federacja musi działać razem z ochroną gałęzi, review plików CI, kontrolą środowisk oraz bezpieczeństwem łańcucha dostaw oprogramowania.

Claims, które muszą znaleźć się w modelu zagrożeń

Token GitHub Actions zawiera standardowe claims OIDC i dane opisujące repozytorium oraz wykonanie. Trzy pola tworzą rdzeń decyzji:

Claim	Pytanie kontrolne	Typowy błąd
`iss`	Kto wydał token?	zaufanie do niewłaściwego lub dodatkowego emitenta
`aud`	Dla jakiej usługi token został wystawiony?	brak walidacji odbiorcy albo zbyt szeroka lista
`sub`	Jaki workload reprezentuje token?	wildcard obejmujący dowolne repozytorium lub ref

GitHub dokumentuje format subject zależny od kontekstu. Job powiązany ze środowiskiem może mieć sub odpowiadający organizacji, repozytorium i nazwie environment; bez environment subject może wskazywać branch, tag albo pull_request. Nie wolno zakładać formatu z pamięci. Najpierw przechwyć claims z kontrolnego wykonania, porównaj je z aktualną dokumentacją emitenta i dopiero wtedy buduj warunek.

Claims są danymi bezpieczeństwa, ale ich obecność nie oznacza, że chmura automatycznie je egzekwuje. Polityka federacyjna musi jawnie zawężać dozwolone wartości. Sama zgodność podpisu dowodzi tylko, że token wydał zaufany issuer.

Minimalna polityka zaufania

Bezpieczna polityka dla produkcji odpowiada na pięć pytań:

czy issuer jest dokładnie tym, którego skonfigurowano;
czy audience odpowiada usłudze wymiany tokenu;
czy właściciel i repozytorium są właściwe;
czy job pochodzi z chronionego środowiska lub dozwolonego refu;
czy rola i czas życia sesji są minimalne dla tego etapu.

Nie używaj jednego trustu dla build, test, staging i production. Kompilacja zwykle potrzebuje dostępu do rejestru zależności, ale nie prawa do wdrożenia. Job publikujący artefakt nie musi administrować siecią. Migracja bazy danych zasługuje na osobną tożsamość. Podział ogranicza skutki kompromitacji i upraszcza analizę zdarzeń.

Wildcard może być uzasadniony dla kontrolowanej rodziny gałęzi deweloperskich, lecz nie dla roli produkcyjnej. Wzorzec obejmujący wszystkie repozytoria organizacji sprawia, że najsłabiej chronione repo staje się wejściem do chmury. Wzorzec obejmujący każdy branch pozwala ominąć review przez własny ref. To klasyczny przykład różnicy między poprawną integracją a bezpieczną integracją.

GitHub Actions: uprawnienie do tokenu to przywilej

W GitHub Actions job potrzebujący federacji otrzymuje permissions: id-token: write. To pozwala żądać tokenu OIDC; nie nadaje samo w sobie uprawnień zapisu do zasobów chmurowych. Mimo to prawo powinno występować tylko w konkretnym jobie wdrożeniowym, nie globalnie dla całego workflow.

Ustaw pozostałe uprawnienia GITHUB_TOKEN jawnie i minimalnie. Akcja pobierająca kod zazwyczaj potrzebuje contents: read, natomiast packages: write, pull-requests: write czy administracja repozytorium nie powinny pojawiać się „na zapas”. Przypinaj zewnętrzne akcje do niezmiennego identyfikatora commita, ponieważ przejęta akcja działająca w jobie z id-token: write może poprosić o token w jego kontekście.

Produkcję powiąż z GitHub Environment. Zastosuj wymaganych reviewerów, ograniczenie gałęzi i tagów wdrożeniowych oraz osobne reguły dla sekretów środowiska. Następnie zaufanie w chmurze zawęź do subject tego environment. Kontrola tylko po jednej stronie jest słabsza: sama ochrona environment nie naprawi zbyt szerokiej roli, a sam warunek sub nie zastąpi review zmian workflow.

AWS: rola, provider i warunki STS

W AWS GitHub Actions wymienia token na poświadczenie przez rolę IAM i OIDC identity provider. Dokumentacja IAM wymaga, aby polityka zaufania dla GitHub ograniczała sub; warunek nie może być wyłącznie pusty albo uniwersalny. Dla typowej integracji aud odpowiada sts.amazonaws.com, a sub powinien wskazywać konkretną organizację i repozytorium, dalej branch, tag albo environment.

Trust policy rozstrzyga, kto może wejść w rolę. Permission policy roli rozstrzyga, co sesja może zrobić. Obie warstwy muszą być ograniczone. Nawet idealny sub nie usprawiedliwia Action: * i Resource: *. Dla wdrożenia aplikacji rozdziel zapis obrazu, aktualizację usługi i odczyt parametrów. Jeżeli usługa wspiera resource-level permissions i conditions, egzekwuj je.

W audycie sprawdź również maksymalny czas sesji, możliwość przekazywania ról (iam:PassRole), uprawnienia do modyfikacji własnej trust policy oraz ścieżki eskalacji opisane szerzej w pentestach AWS, Azure i GCP. Rola wdrożeniowa nie powinna móc sama rozszerzyć zasad, które ją ograniczają.

Microsoft Entra ID: federated identity credentials

W Entra ID federated identity credential tworzy relację między zewnętrznym issuerem a aplikacją lub managed identity. Decyzja opiera się na zgodności issuer, subject i audiences. Zasada pozostaje ta sama: osobna tożsamość dla środowiska, precyzyjny subject i minimalne role Azure RBAC.

Nie łącz wielu niezależnych pipeline’ów z jedną aplikacją mającą szerokie uprawnienia do subskrypcji. To utrudnia atrybucję i sprawia, że kompromitacja jednego repozytorium dotyka każdego wdrożenia. Preferuj osobne identity per aplikacja i etap, scope roli na resource group lub konkretny zasób oraz kontrolę, kto może modyfikować federated credentials.

Microsoft udostępnia także elastyczne reguły dopasowania claims. Elastyczność nie powinna prowadzić do reguły akceptującej cały issuer. Testuj wartości graniczne, kodowanie znaków, zmianę nazwy repozytorium i różnice między branch, tag, pull request oraz environment.

Google Cloud: Workload Identity Federation

Google Cloud Workload Identity Federation mapuje claims z zewnętrznego tokenu na atrybuty Google i pozwala nałożyć attribute condition. Projekt powinien ograniczać nie tylko provider, ale też organizację, repozytorium i kontekst wdrożenia. Google ostrzega, że claims o nazwach opartych na nazwach organizacji lub repozytorium mogą być ponownie użyte po usunięciu i ponownej rejestracji nazwy; gdy emitent udostępnia stabilne identyfikatory, warto włączyć je do warunków.

Rozdziel service accounts i bindingi dla środowisk. Kontroluj możliwość impersonacji konta usługi, bo prawo workloadIdentityUser albo równoważne wiązanie jest częścią granicy. Nie pozostawiaj starego klucza JSON „awaryjnie” w sekretach — utrzymywałby dokładnie tę klasę ryzyka, którą federacja ma usunąć.

Model zagrożeń dla OIDC w CI/CD

Dobry pentest nie ogranicza się do sprawdzenia, czy logowanie działa. Ocenia, czy atakujący może uzyskać zaufany kontekst inną drogą. Najważniejsze scenariusze to:

modyfikacja workflow przez pull request lub przejęte konto maintainera;
użycie zewnętrznej akcji, skryptu instalacyjnego albo zależności do kradzieży tokenu w czasie joba;
uruchomienie workflow z nieoczekiwanego branchu, tagu, forka lub reusable workflow;
pomylenie pull_request i pull_request_target oraz uruchomienie niezaufanego kodu z uprzywilejowanym kontekstem;
zbyt szeroki sub, brak właściwego aud albo dodatkowy federated credential;
przejęcie artefaktu między jobem build i deploy;
nadmierne uprawnienia roli albo możliwość samodzielnej eskalacji;
brak telemetrii łączącej sesję chmurową z workflow, repozytorium i commitem.

Szczególnie niebezpieczne jest mieszanie niezaufanego kodu z uprzywilejowanym jobem. Workflow obsługujący pull request z forka nie powinien wykonywać kodu autora z prawem do tokenu produkcyjnego. Artefakt przechodzący z mniej zaufanego joba do wdrożenia musi mieć jednoznaczną tożsamość, integralność i provenance. Więcej warstw dla takiego procesu opisuje bezpieczeństwo agentów w CI/CD oraz ochrona łańcucha dostaw kodu.

Metodyka pentestu federacji workload identity

Test powinien być uzgodniony z właścicielem chmury i repozytorium. Nie próbuj realnego wdrożenia na produkcję, jeśli można potwierdzić lukę przez bezpieczny odczyt tożsamości albo kontrolowany zasób testowy.

1. Inwentaryzacja relacji

Zbierz issuerów, providerów, federated credentials, role, service accounts, audience, subject patterns, attribute mappings i maksymalny czas sesji. Połącz każdą relację z konkretnym workflow oraz właścicielem biznesowym. Osierocony trust jest podatnością nawet wtedy, gdy bieżący pipeline go nie używa.

2. Odczyt efektywnych claims

Uruchom kontrolny job bez sekretów produkcyjnych i zarejestruj bezpieczny zestaw claims — nigdy cały token. Porównaj subject dla branchu, tagu, environment, pull requestu i reusable workflow. Sprawdź percent-encoding oraz zmianę wartości po rename repozytorium.

3. Testy negatywne

Spróbuj uzyskać sesję z niezaufanego branchu, niezatwierdzonego environment, innego repozytorium testowego i niepoprawnego audience. Oczekiwanym wynikiem jest odmowa po stronie usługi tokenowej. Każda akceptacja ujawnia, który warunek jest za szeroki.

4. Analiza uprawnień po wymianie

Po otrzymaniu kontrolowanej sesji określ efektywne prawa, granice permission boundary, SCP lub odpowiedników oraz ścieżki PassRole i impersonacji. Zweryfikuj, czy tożsamość może zmienić własne zaufanie, polityki, logowanie albo ochronę zasobów.

5. Integralność ścieżki build–deploy

Ustal, czy job wdrożeniowy buduje ponownie kod, czy pobiera artefakt. Powiąż digest artefaktu z zatwierdzonym commitem, testami i attestation. Token OIDC identyfikuje workload, lecz nie dowodzi, że wdrażany plik jest właściwy.

6. Monitoring i odwołanie

Sprawdź logi wydawania sesji w chmurze, historię workflow oraz możliwość korelacji. Przećwicz unieważnienie przez usunięcie credential, zmianę trust policy i blokadę environment. Krótki czas życia ogranicza okno, ale nie zastępuje procedury reakcji.

Telemetria, która wykrywa nadużycie

Rejestruj co najmniej: identyfikator roli lub service account, issuer, subject, audience, repozytorium, workflow, branch lub environment, commit SHA, run ID, aktora uruchamiającego, adresację sieciową usługi tokenowej i operacje wykonane po wymianie. Nie zapisuj surowego JWT w logach.

Alertuj na pierwsze użycie nowego subject, sesję poza zwykłym workflow, wydanie poświadczenia dla produkcji bez odpowiadającego deployment approval, zmianę federated credential, zwiększenie uprawnień roli oraz aktywność geograficznie lub czasowo niespójną z runnerami. Dla self-hosted runnerów dodaj kontrolę integralności hosta i sieci egress.

Monitoring musi widzieć zarówno płaszczyznę CI, jak i cloud control plane. Sam log AssumeRoleWithWebIdentity nie wyjaśni, kto zmienił workflow; sam audit GitHub nie pokaże operacji wykonanych później w chmurze. Korelację można wdrożyć w ramach SIEM, XDR lub EDR oraz programu monitoringu bezpieczeństwa.

Checklista bezpiecznego wdrożenia

Usuń stałe klucze dopiero po potwierdzeniu działania federacji i przeszukaniu historii repozytorium.
Utwórz oddzielne tożsamości dla build, staging i production.
Ogranicz issuer, audience, repozytorium oraz branch, tag lub environment.
Nadaj id-token: write tylko jobom, które naprawdę wymieniają token.
Ogranicz GITHUB_TOKEN i przypnij zewnętrzne akcje do commit SHA.
Chroń pliki workflow przez CODEOWNERS, branch protection i wymagane review.
Nie wykonuj niezaufanego kodu PR w jobie posiadającym federację produkcyjną.
Ogranicz rolę chmurową do konkretnych akcji i zasobów.
Monitoruj zmiany providerów, credentials, trust policies i bindingów.
Testuj przypadki negatywne po każdej zmianie formatu claims lub pipeline’u.
Utrzymuj procedurę odwołania relacji oraz plan awaryjnego wdrożenia bez stałego klucza.

Najczęstsze pytania o OIDC w CI/CD

Czy OIDC całkowicie zastępuje sekrety w pipeline?

Zastępuje długoterminowe poświadczenia chmurowe w obsługiwanym przepływie. Pipeline może nadal potrzebować innych sekretów, na przykład do usługi bez federacji. Każdy z nich wymaga osobnej oceny i rotacji.

Czy krótki czas życia tokenu wystarczy?

Nie. Skraca czas wykorzystania skradzionej sesji, ale zbyt szeroka polityka pozwala atakującemu żądać kolejnych tokenów. Najważniejsze są precyzyjne warunki i ochrona kontekstu workflow.

Czy jedna rola dla całej organizacji jest prostsza?

Operacyjnie tak, lecz znacząco zwiększa blast radius i utrudnia atrybucję. Osobne role lub tożsamości per aplikacja i środowisko są łatwiejsze do audytu oraz odwołania.

Jak często audytować federację?

Po zmianie workflow, providera, nazw repozytoriów, modelu środowisk lub uprawnień, a ponadto cyklicznie. Trusty osierocone i wyjątki narastają podobnie jak stare klucze.

Audyt OIDC musi objąć CI i chmurę

Najlepszy rezultat to nie komunikat „nie mamy kluczy”, lecz dowód, że tylko zatwierdzony workload może uzyskać minimalną sesję i że każdą wymianę da się powiązać z kodem oraz decyzją wdrożeniową. Breachroad łączy testy penetracyjne chmury, przegląd pipeline’u i analizę IAM, dzięki czemu raport wskazuje zarówno błędny trust, jak i realną ścieżkę wpływu.