Bildquelle: extern
OIDC statt Langzeit-Secrets in CI/CD: Welche 5 Umstellungen DevOps-Teams 2026 jetzt sauber durchziehen sollten
In vielen Delivery-Pipelines steckt noch immer ein erstaunlich altes Sicherheitsmuster: Ein Cloud-Schlüssel, ein Service-Principal-Secret oder ein Vault-Token wird einmal erzeugt, als CI/CD-Secret abgelegt und dann monatelang von Build- und Deploy-Jobs mitgeschleppt. Solange nichts sichtbar kaputtgeht, wirkt das bequem. In der Praxis ist es aber einer der unnötigsten Risikotreiber im modernen DevOps-Betrieb. Wer Zugriff auf Repository, Pipeline-Konfiguration, Runner oder geloggte Umgebungsvariablen bekommt, sitzt schnell auf weitreichenden Zugangsdaten.
Die Gegenbewegung ist inzwischen klar erkennbar. GitHub Actions setzt für Cloud-Zugriffe auf OpenID Connect, GitLab stellt ID-Tokens für OIDC-basierte Authentifizierung bereit, Microsoft Entra Workload ID Federation ersetzt Secrets und Zertifikate für externe Workloads, und Google positioniert Workload Identity Federation ausdrücklich als Alternative zu Service-Account-Keys. Auch AWS verlangt bei OIDC-Föderation eine sauber eingeschränkte Trust Policy statt blind wiederverwendbarer Dauer-Credentials.
Für DevOps-Teams ist das nicht nur ein Sicherheitsthema, sondern ein Betriebshebel. OIDC reduziert Secret-Rotation, senkt den Schaden kompromittierter Pipelines und macht Deployments besser an Branches, Umgebungen und Freigaben bindbar. Damit der Umstieg wirklich trägt, reichen ein paar YAML-Zeilen aber nicht. Fünf Umstellungen sind in der Praxis entscheidend.
1. Zuerst das Secret-Inventar der Pipeline offenlegen, nicht sofort am Login-Mechanismus schrauben
Der typische Fehler beim Einstieg ist Aktionismus. Ein Team aktiviert OIDC in GitHub oder GitLab, ersetzt ein einzelnes Cloud-Login und erklärt das Thema für erledigt. Tatsächlich bleibt oft der Großteil des Risikos unangetastet, weil in derselben Pipeline weiter langlebige Container-Registry-Credentials, Terraform-Keys, alte Service-Accounts oder manuell gepflegte API-Tokens liegen.
Der erste sinnvolle Schritt ist deshalb ein Inventar aller maschinellen Zugänge in Build-, Test- und Deploy-Jobs. Pro Secret sollten vier Fragen beantwortet werden: Wofür wird es verwendet, wer ist der technische Owner, welche Rechte hängen daran, und kann dieser Zugriff durch föderierte Identität ersetzt werden? Genau an dieser Stelle wird oft sichtbar, dass ein vermeintliches Deployment-Secret in Wahrheit deutlich mehr darf als nur ein Artefakt ausrollen, etwa Storage lesen, Logs löschen oder Infrastruktur ändern.
Dieses Inventar trennt auch die wirklich geeigneten OIDC-Kandidaten von Sonderfällen. Cloud-Deployments, Vault-Zugriffe und temporäre Registry-Logins lassen sich meist gut föderieren. Alt-Tools ohne OIDC-Unterstützung brauchen dagegen oft Übergangslösungen. Wer das nicht sauber trennt, landet in halb migrierten Pipelines mit neuen und alten Risiken nebeneinander.
2. Die Vertrauenskette hart an Repository, Branch, Tag und Umgebung binden
OIDC bringt nur dann echten Sicherheitsgewinn, wenn die Trust-Beziehung eng gefasst ist. GitHub beschreibt in seinen OIDC-Unterlagen ausdrücklich, dass Token Claims wie sub, ref, repository oder environment enthalten. GitLab liefert in ID-Tokens unter anderem Claims zu Projekt, Ref, Protected-Status und Zielumgebung. Genau diese Informationen müssen in Cloud- und Vault-Rollen ausgewertet werden.
Praktisch heißt das: Eine Produktionsrolle darf nicht einfach jedem Job aus einem Repository offenstehen. Sie sollte an eine geschützte Branch oder einen signierten Release-Tag gebunden sein, idealerweise zusätzlich an eine explizite Deployment-Umgebung. In AWS gehört das in die Trust Policy über präzise Condition-Einschränkungen. In Google Cloud werden dafür Attribute gemappt und anschließend gezielt Rollen an diese föderierten Principals gebunden. In Microsoft Entra wird die Vertrauensbeziehung zwischen externer Identität und verwalteter Identität oder App-Registrierung definiert.
Viele Teams machen die Trust-Definition anfangs zu breit, weil der Rollout dann schneller funktioniert. Genau das rächt sich später. Wenn ein Pull-Request-Job, ein Test-Workflow und ein Produktions-Deploy dieselbe föderierte Rolle annehmen können, wurde nur das Format des Secrets modernisiert, nicht das Zugriffsmodell.
3. Produktionsfreigaben in der Delivery-Logik abbilden, nicht nur im Cloud-IAM
Ein sauberer OIDC-Umstieg zwingt Teams dazu, Freigabelogik endlich explizit zu machen. Denn föderierte Identität kann nur so gut sein wie die Pipeline, die den Token anfordert. Wenn Produktionsdeployments aus ungeschützten Branches, aus Forks oder ohne Vier-Augen-Freigabe starten dürfen, hilft auch das eleganteste Token nichts.
Darum sollten OIDC-Rollen immer zusammen mit den Schutzmechanismen der Delivery-Plattform geplant werden. In GitHub gehören dazu geschützte Environments, Review-Gates und saubere Rechte auf Workflow-Dateien. In GitLab sind geschützte Refs und geschützte Umgebungen zentral, weil sich ihre Eigenschaften direkt in Token-Claims niederschlagen können. Entscheidend ist die Kopplung: Nur ein Job, der aus dem richtigen Repository-Kontext kommt und die vorgesehenen Freigaben durchlaufen hat, darf die Produktionsidentität überhaupt anfordern.
Das ist mehr als Formalität. In vielen Vorfällen war nicht der Cloud-Provider das Problem, sondern die fehlende Trennung zwischen Build, Test und Deploy. Wer OIDC einführt, sollte deshalb nicht nur die Anmeldung umbauen, sondern die Delivery-Stufen sichtbar härten.
4. Rollen klein schneiden und Tokens pro Job zweckgebunden halten
Der zweite verbreitete Fehler ist die Übernahme alter Berechtigungsmodelle in die neue Welt. Ein statischer Schlüssel mit zu vielen Rechten wird dann einfach durch eine föderierte Rolle mit zu vielen Rechten ersetzt. Sicherheitsseitig ist das besser als vorher, aber noch lange nicht gut genug.
Short-lived Tokens entfalten ihren Vorteil erst, wenn auch die dahinterliegenden Rollen eng geschnitten sind. Ein Build-Job braucht andere Rechte als ein Infrastruktur-Plan, ein Staging-Deploy andere als ein Produktions-Rollout. GitLab weist beim Einsatz mehrerer ID-Tokens ausdrücklich darauf hin, dass unterschiedliche aud-Werte die Missbrauchsfläche reduzieren. Dasselbe Prinzip gilt plattformübergreifend: getrennte Vertrauenspfade, getrennte Rollen, getrennte Zielsysteme.
In der Praxis lohnt sich ein Dreischnitt. Erstens eine Build-Identität ohne Produktionsrechte. Zweitens eine Staging-Identität mit begrenztem Schreibzugriff. Drittens eine Produktionsidentität, die nur aus streng geschützten Deploy-Jobs erreichbar ist. Zusätzlich sollte jedes Team prüfen, ob direkte Rechte auf Ressourcen nötig sind oder ob eine nachgelagerte Service-Account-Impersonation beziehungsweise Rollenannahme mit engerem Scope sinnvoller ist. Gerade Google beschreibt beide Muster ausdrücklich und empfiehlt saubere Trennung pro Umgebung.
5. Audit, Fallbacks und Break-Glass bewusst regeln, bevor der erste Störfall kommt
OIDC-Projekte scheitern selten an der Grundfunktion. Sie scheitern im Störfall. Ein Provider ändert Claims, ein Runner verliert Zeitdrift, eine neue Umgebung wird angebunden, oder ein Team aktiviert aus Zeitdruck wieder ein statisches Secret „nur für heute“. Genau aus solchen Rückfällen entstehen später Schattenzugänge, die niemand mehr aktiv überwacht.
Deshalb braucht der Umstieg von Anfang an drei Betriebsregeln. Erstens: Token-Anforderung und Rollenannahme müssen im Logging auffindbar sein, damit Security und Plattformbetrieb nachvollziehen können, welcher Job wann welche Identität genutzt hat. Zweitens: statische Alt-Secrets dürfen nicht als stiller Fallback in denselben Pipelines liegen bleiben. Sonst weichen Teams bei jedem kleinen Fehler zurück, und die Migration bleibt kosmetisch. Drittens: Ein Break-Glass-Zugang für echte Notfälle kann sinnvoll sein, muss aber separat freigegeben, eng befristet und nach Nutzung überprüft werden.
Gerade hier lohnt sich der Blick auf OWASP. Die Top-10-Risiken für CI/CD betonen, wie attraktiv Build- und Delivery-Systeme für Angreifer sind, weil sich über sie weitreichende Unternehmenswerte erreichen lassen. Wer OIDC nur als bequemere Login-Methode behandelt, verschenkt den eigentlichen Nutzen. Es geht um kontrollierbare Maschinenidentitäten in einem der sensibelsten Teile der Lieferkette.
Fazit
OIDC in CI/CD ist 2026 kein Spezialthema mehr für Vorreiter, sondern der vernünftige Standard für moderne Deployments. Der eigentliche Gewinn entsteht aber nicht durch das Token selbst, sondern durch die Disziplin dahinter: Secret-Inventar, eng gebundene Trust Policies, sauber modellierte Freigaben, kleinteilige Rollen und ein Betrieb ohne heimliche Rückfälle auf Dauer-Credentials. DevOps-Teams, die diese fünf Umstellungen konsequent durchziehen, bekommen nicht nur weniger Secrets, sondern vor allem nachvollziehbarere und belastbarere Lieferketten.
