Der Zugangsschlüssel für die Cloud liegt als Secret im Repository, ist seit zwei Jahren derselbe, und niemand weiß mehr genau, wer ihn damals erzeugt hat. Er funktioniert — und genau das ist das Problem.
Ein Token, das nur diesem Lauf gehört
Über OpenID Connect stellt GitHub dem Job ein signiertes Token aus, das Repository, Branch, Environment und Workflow beschreibt. Der Cloud-Anbieter prüft diese Angaben gegen eine hinterlegte Vertrauensbeziehung und gibt dafür ein kurzlebiges Zugangstoken aus. Gespeichert wird nichts: Minuten später ist es wertlos, und es gibt kein Geheimnis mehr, das jemand versehentlich ins Log schreiben könnte.
Der Claim entscheidet, wer hereindarf
Die Sicherheit steckt nicht im Token, sondern im Zuschnitt der
Vertrauensbeziehung. Der Claim sub bindet den Zugang an Repository und
Branch oder Environment — ein Muster für genau die Hauptlinie schließt alle
anderen aus. Wer stattdessen das ganze Repository erlaubt, hat jedem Branch den
Weg in die Produktion geöffnet.
Der häufigste Fehler sieht aus wie ein Cloud-Problem
Ohne id-token: write in den permissions kann der Job das Token gar nicht
erst anfordern. Der Lauf scheitert an der Anmeldung, und die Suche beginnt
prompt bei der Rolle im Cloud-Konto — dabei fehlt eine Zeile im Workflow. Der
zweite Klassiker: Nach dem Umstieg bleibt der alte Schlüssel als Secret liegen
und ist weiter gültig.
Mehr dazu im Seminar
Von der Frage, wo ein Wert überhaupt hingehört, über Least Privilege für das
GITHUB_TOKEN bis zum Umstieg auf OIDC führt das Modul
Secrets, Tokens und OIDC.