Die meisten Deployment-Pipelines hängen an einem langlebigen Token. Ein Cloud-Schlüssel liegt als Secret im Repository, GitHub Actions liest ihn beim Build und schiebt damit Artefakte in AWS, Azure oder GCP. Das funktioniert, bis der Token leakt. Dann hat ein Angreifer dauerhaft Zugriff, oft monatelang unbemerkt. OIDC löst dieses Problem, indem es gespeicherte Tokens komplett überflüssig macht.
Das Problem mit langlebigen Tokens
Ein statischer Cloud-Schlüssel hat zwei Schwächen. Er ist lange gültig, oft ohne Ablaufdatum, und er liegt an mehreren Stellen: im Secret-Store von GitHub, in Backups, manchmal in Logs. Jeder mit Schreibrechten auf die Pipeline kann ihn indirekt nutzen. Wird das Repository kompromittiert oder schleust jemand eine bösartige Action ein, ist der Schlüssel weg. Rotation hilft nur begrenzt, weil sie manuell passiert und in der Praxis selten konsequent durchgezogen wird.
Wie OIDC funktioniert
OIDC steht für OpenID Connect. Statt einen gespeicherten Schlüssel zu verwenden, stellt GitHub zur Laufzeit ein kurzlebiges, signiertes Token aus. Dieses Token beschreibt, wer den Job ausführt: welches Repository, welcher Branch, welcher Workflow. Die Cloud-Plattform prüft die Signatur gegen GitHubs öffentlichen Schlüssel und tauscht das Token gegen temporäre Zugangsdaten ein, die nach wenigen Minuten verfallen.
Der entscheidende Unterschied: Es gibt keinen Schlüssel mehr, der gestohlen werden kann. Das Vertrauen entsteht aus der Identität des Workflows selbst, nicht aus einem geteilten Geheimnis. Ein geleaktes Token ist nach Minuten wertlos.
Was die Einrichtung konkret braucht
Auf der Cloud-Seite legt man eine Vertrauensbeziehung an. Bei AWS ist das ein IAM-OIDC-Provider plus eine Rolle mit einer Trust Policy, die genau festlegt, welches Repository und welcher Branch die Rolle annehmen dürfen. Bei Azure und GCP läuft es analog über Federated Credentials beziehungsweise Workload Identity Federation.
Im Workflow setzt man die Berechtigung id-token: write und nutzt die offizielle Login-Action der jeweiligen Cloud. Diese fordert das OIDC-Token an und tauscht es ein. Aus dem Workflow verschwinden die secrets-Referenzen für die Cloud-Anmeldung vollständig.
Die Trust Policy ist der eigentliche Sicherheitsgewinn
Der häufigste Fehler bei OIDC ist eine zu weit gefasste Trust Policy. Wer die Bedingung nur auf das Repository einschränkt, erlaubt jedem Branch und jedem Pull Request, die Produktionsrolle anzunehmen. Ein Fork oder ein manipulierter Feature-Branch kann dann deployen.
Die Bedingung sollte deshalb auf den konkreten Branch oder das Environment zielen, etwa ref:refs/heads/main oder ein geschütztes Deployment-Environment. So bekommt nur der Pfad Produktionszugriff, der durch Branch Protection und Reviews abgesichert ist. Genau hier entscheidet sich, ob OIDC tatsächlich sicherer ist oder nur die Tokens durch eine offene Tür ersetzt.
Wann sich der Umstieg lohnt
Für jede Pipeline, die in eine der großen Clouds deployt, ist OIDC heute der Standardweg. Der Aufwand liegt bei einer einmaligen Einrichtung pro Cloud-Konto, danach entfällt die Token-Rotation komplett. Schwieriger wird es bei Zielen ohne OIDC-Unterstützung, etwa älteren On-Prem-Systemen. Dort bleibt ein Secret nötig, das man dann wenigstens eng begrenzt und regelmäßig rotiert.
Wer den Umstieg plant, sollte mit einem unkritischen Service beginnen, die Trust Policy eng fassen und erst danach Produktion umstellen. Der Sicherheitsgewinn ist real: Ein ganzer Angriffsvektor verschwindet, ohne dass laufende Deployments langsamer werden.
Sie wollen wissen, wo in Ihrer Pipeline noch langlebige Secrets liegen und welche Berechtigungen zu weit gefasst sind? Der GitSecOps QuickCheck prüft genau das: 1.990 Euro netto, Ergebnis in 3 Werktagen. Kontakt: mm@crank.zone
Dein Blog zum Thema digitales Business 
Hinterlasse einen Kommentar