Bildquelle: extern
Secrets im CI/CD: Welche 5 Betriebsregeln DevOps-Teams endlich verbindlich machen sollten
In vielen DevOps-Umgebungen ist das eigentliche Problem nicht mehr der fehlende Automatisierungsgrad, sondern der zu lockere Umgang mit Geheimnissen. API-Keys, Datenbank-Credentials, Cloud-Rollen, SSH-Schlüssel, Zertifikate oder Deploy-Tokens landen noch immer in Repository-Variablen, Container-Definitionen, Kubernetes-Manifests oder schlicht in zu vielen Build-Systemen gleichzeitig. Solange alles funktioniert, fällt das kaum auf. Sobald aber ein Repository gespiegelt wird, ein Runner kompromittiert ist, ein Log versehentlich zu viel ausgibt oder ein Team eine verwaiste Integration übersieht, wird aus Bequemlichkeit ein Sicherheits- und Betriebsproblem.
Genau deshalb ist Secrets Management längst kein Nischenthema für Security-Teams mehr. OWASP beschreibt in seinem Secrets Management Cheat Sheet sehr deutlich, dass Organisationen Storage, Bereitstellung, Rotation, Auditing und Zugriff auf Secrets zentral steuern müssen. GitHub empfiehlt für Deployments ausdrücklich den Umstieg auf OpenID Connect, damit Workflows statt langlebiger Geheimnisse kurzlebige Tokens vom Cloud-Provider beziehen. Und Kubernetes erinnert daran, dass Secrets zwar besser sind als Klartext in ConfigMaps oder Code, standardmäßig aber nicht automatisch sicher sind, wenn Zugriff, Speicherung und Laufzeitnutzung unsauber umgesetzt werden.
Für DevOps-Verantwortliche heißt das: Nicht jedes Team braucht sofort ein riesiges Vault-Programm. Aber jedes Team braucht verbindliche Betriebsregeln, die Missbrauchsfläche verkleinern und den Alltag beherrschbar machen.
1. Langlebige Zugangsdaten aus der Pipeline verbannen
Die wichtigste Regel ist zugleich die unbequemste: Ein CI/CD-System sollte möglichst keine langlebigen Cloud-Credentials mehr speichern. GitHub beschreibt bei OpenID Connect den sauberen Zielzustand sehr klar. Die Pipeline baut eine Vertrauensbeziehung zum Zielsystem auf und erhält pro Job ein kurzlebiges Token, das automatisch abläuft. Genau das reduziert gleich mehrere Risiken: keine doppelt gepflegten Secrets zwischen Cloud und CI-Plattform, weniger Rotationsaufwand und deutlich kleinere Folgen, falls ein Token doch einmal offengelegt wird.
In der Praxis ist das die richtige Priorität für alle Deployments auf AWS, Azure, GCP, Vault oder andere Systeme mit OIDC-Unterstützung. Wer 2026 noch dauerhaft gültige Cloud-Schlüssel in Build-Variablen liegen hat, schleppt eine Altlast mit, die weder sicher noch nötig ist. Die operative Leitfrage sollte deshalb lauten: Wo können wir statische Secrets durch föderierte, kurzlebige Identitäten ersetzen?
2. Secrets zentral verwalten, statt sie über Tools und Dateien zu verstreuen
OWASP empfiehlt ausdrücklich, Secrets Management zu zentralisieren und zu standardisieren. Das bedeutet nicht zwingend, dass im ganzen Unternehmen nur ein einziges Werkzeug erlaubt ist. Es bedeutet aber sehr wohl, dass klar geregelt sein muss, wo produktive Secrets erzeugt, abgelegt, versioniert, freigegeben und dokumentiert werden. Sobald Teams dasselbe Geheimnis parallel in GitHub, GitLab, Jenkins, Kubernetes, Terraform-Variablen und lokalen Passwortmanagern pflegen, verliert die Organisation jede belastbare Übersicht.
Besonders kritisch wird es, wenn sensible Werte in Manifeste oder Repositories wandern. Kubernetes weist ausdrücklich darauf hin, dass Base64-kodierte Secret-Manifeste keine Verschlüsselung darstellen. Wer solche Dateien teilt oder eincheckt, verbreitet das Geheimnis faktisch weiter. Für den Betrieb heißt das: Secret-Werte gehören nicht in Git, nicht in Wiki-Snippets und nicht in Copy-and-paste-Runbooks. In Git sollten höchstens Referenzen auf eine zentrale Secret-Quelle stehen.
3. Zugriff strikt nach Kontext begrenzen, nicht nach Bequemlichkeit
Der nächste Klassiker ist überbreiter Zugriff. OWASP fordert Least Privilege, GitHub empfiehlt minimale Berechtigungen für Tokens und Service-Identitäten, und Kubernetes warnt sogar davor, dass schon List-Zugriff auf Secrets faktisch das Auslesen sensibler Inhalte ermöglichen kann. Genau hier scheitern viele DevOps-Setups im Alltag: Ein Shared Runner darf zu viel, ein Deployment-Token gilt für mehrere Umgebungen gleichzeitig oder ein Namespace enthält mehr Secrets, als ein einzelner Workload eigentlich jemals sehen sollte.
Sauber ist eine andere Logik. Secrets werden nach Umgebung, Anwendung, Team und Zweck getrennt. Produktionswerte sind nicht in Test-Pipelines sichtbar. Ein einzelner Job erhält nur Zugriff auf das, was er in genau diesem Lauf benötigt. In Kubernetes sollten nur die Container innerhalb eines Pods Zugriff auf ein Secret haben, die es wirklich brauchen. Und im CI-System sollte jedes Environment eigene Freigaben, eigene Scopes und idealerweise eigene Genehmigungswege haben.
Die Faustregel ist simpel: Wenn der Ausfall oder Missbrauch eines einzelnen Tokens gleich mehrere Systeme, Umgebungen oder Produkte trifft, ist die Reichweite zu groß.
4. Rotation und Lebensdauer automatisieren, statt sie als Sonderprojekt zu behandeln
OWASP macht einen Punkt besonders klar: Manuelle Secret-Pflege erhöht sowohl das Leckagerisiko als auch die Fehlerquote. Deshalb sollten Teams Rotation nicht als seltene Sicherheitskampagne behandeln, sondern als normalen Betriebsprozess. Wo immer möglich, sind dynamische oder kurzlebige Secrets die bessere Wahl. Wo statische Secrets unvermeidbar bleiben, braucht es feste Rotationszyklen, technische Unterstützung und sichtbare Verantwortlichkeiten.
Für DevOps-Teams ist das mehr als Security-Hygiene. Es ist auch ein Verfügbarkeits- und Qualitätsfaktor. Wer Rotation nur halbautomatisch betreibt, kennt die typischen Folgen: vergessene Abhängigkeiten, nächtliche Störungen nach Passwortwechseln, aus Angst vor Ausfällen verschobene Erneuerungen oder dauerhafte Ausnahme-Accounts. Besser ist ein klarer Rotationspfad pro Secret-Klasse, inklusive Test, Rollout-Reihenfolge, Fallback und Auditspur.
Praktisch heißt das: Datenbank-Credentials, API-Tokens, Zertifikate und Deploy-Keys brauchen jeweils definierte Eigentümer, Ziel-Lebensdauer und einen technischen Erneuerungsweg. Ohne diese Zuordnung bleibt Rotation nur gute Absicht.
5. Laufzeit- und Betriebsrisiken mitdenken, nicht nur die Ablage
Viele Teams sichern heute den Speicherort von Secrets besser ab, übersehen aber die Laufzeit. Kubernetes weist darauf hin, dass Anwendungen Secret-Daten nach dem Einlesen weiter schützen müssen, also sie weder im Klartext loggen noch unkontrolliert an andere Stellen weiterreichen dürfen. Genau das ist im CI/CD-Alltag hochrelevant: Debug-Logs, fehlgeschlagene Scripts, Third-Party-Actions, Crash-Dumps und gemeinsam genutzte Build-Runner sind oft die eigentlichen Leckagepunkte.
Dazu kommt die Plattformseite. Kubernetes empfiehlt Verschlüsselung von Secrets at rest in etcd, restriktive RBAC-Regeln und bei Bedarf externe Secret Stores. Für Plattform- und DevOps-Teams ergibt sich daraus eine einfache Prüffolge: Wo liegen Secrets physisch? Wer kann sie lesen? Wo tauchen sie im Lauf eines Jobs oder Pods im Speicher, Log, Dateisystem oder Artefakt wieder auf? Und wie erkennen wir ungewöhnliche Zugriffe oder Massenabfragen?
Wer nur den Secret-Manager anschafft, aber Logging, Runner-Härtung, Namespace-Trennung und Auditing nicht nachzieht, baut einen schönen Tresor in ein offenes Haus.
Was DevOps-Teams jetzt konkret umsetzen sollten
- OIDC zuerst prüfen: Alle Cloud-Deployments darauf abklopfen, ob statische Zugangsdaten durch kurzlebige Tokens ersetzt werden können.
- Zentrale Secret-Quellen definieren: Pro Team und Plattform eindeutig festlegen, wo produktive Secrets verwaltet werden und wo nicht.
- Scope verkleinern: Secrets nach Umgebung, Anwendung und Laufzweck trennen, statt breite Sammel-Variablen zu pflegen.
- Rotation operationalisieren: Für jede Secret-Klasse Eigentümer, Intervall, Automatisierungsgrad und Fallback dokumentieren.
- Laufzeit absichern: Logs, Artefakte, Runner, Sidecars, Pod-Umgebungen und Debug-Ausgaben gezielt auf Secret-Leakage prüfen.
- Kubernetes härten: Encryption at rest, restriktives RBAC und externe Secret Stores dort einsetzen, wo das Risikoprofil es verlangt.
Secrets Management ist damit kein isoliertes Security-Thema, sondern ein Reifegradtest für moderne DevOps-Organisationen. Wer Geheimnisse kurzlebig, kontextarm und technisch sauber handhabt, reduziert nicht nur das Angriffsrisiko, sondern verbessert auch Deployability, Auditierbarkeit und Betriebsstabilität. Gerade 2026, mit mehr Automatisierung, mehr Cloud-Abhängigkeiten und mehr nicht-menschlichen Identitäten in den Delivery-Ketten, ist das kein Nice-to-have mehr. Es ist Grundlagenarbeit für verlässlichen Betrieb.
