GitLab Secrets Manager: Secrets verwalten wie den eigenen Code

Zugangsdaten entstehen oft in der lokalen Entwicklungsumgebung und werden dann in CI/CD-Variablen ohne Geltungsbereich kopiert, damit die Pipelines weiterlaufen. Dort als direkter Wert gespeichert statt als Verweis auf ein beschränktes Secret, erreicht ein Signaturschlüssel jeden Job der Pipeline, auch einen kompromittierten.

Ein separater Vault verringert dieses Risiko, verlangt aber, jede Änderung an Projektmitgliedschaften, geschützten Branches und Produktionsumgebungen dort nachzuziehen. Ist der Vault nicht mehr synchron, bricht eine Pipeline ab oder das Servicekonto eines Agenten behält Zugriffe, die es nicht mehr benötigt.

GitLab Secrets Manager verbessert die Sicherheit von Zugangsdaten ohne zweites Berechtigungsmodell. Er ist ab sofort in GitLab 19.5 für Premium und Ultimate auf GitLab.com und GitLab Self-Managed allgemein verfügbar. GitLab Dedicated folgt in Kürze. Der Secrets Manager basiert auf OpenBao und speichert Zugangsdaten für Build und Laufzeit unter denselben Berechtigungen und mit demselben Audit-Trail wie der Code. Plattform-Teams können Entwicklungsteams Secrets im Self-Service anbieten. Sicherheitsteams erhalten Zugangsdaten, die auf die Jobs beschränkt sind, die sie nutzen, und bei jedem Lesezugriff aus CI/CD zusätzlich die Pipeline- und Job-ID.

"Der GitLab Secrets Manager erlaubt uns, Secrets über CI/CD, Kubernetes und Infrastructure as Code hinweg zu zentralisieren, ohne mehrere Vaults aufzusetzen oder separate Integrationspunkte zu pflegen. Er stärkt zudem unsere Lieferkettensicherheit, weil er eingrenzt, welche Nutzer(innen) und Pipelines auf bestimmte Zugangsdaten zugreifen können." – Jeremy Nauta, Software Architect bei OneTrust

Wie der Secrets Manager Build-Secrets auf einzelne Jobs beschränkt

Agenten können Aktionen ausführen, mit denen niemand gerechnet hat. Sicherheitsteams müssen deshalb bei jedem Job davon ausgehen, dass seine Agenten alle Zugangsdaten nutzen, die sie erreichen können. Der Secrets Manager schränkt ein, was Agenten erreichen, und nutzt dafür den Kontext, den GitLab zu jedem Job bereits hat: das Projekt, den Branch, auf dem der Job läuft, ob dieser Branch geschützt ist, und die Zielumgebung.

Das Entwicklungsteam deklariert das Secret, das ein Job benötigt, mit dem Schlüsselwort secrets: in der .gitlab-ci.yml. GitLab stellt den Wert nur Jobs bereit, die ihn deklarieren und in seinen Geltungsbereich fallen. Bedingungen für den Geltungsbereich akzeptieren Wildcards für Branch und Umgebung und lassen sich kombinieren. So kann eine einzige Regel einen geschützten Branch und eine Umgebung production/* voraussetzen, bevor ein Job die Zugangsdaten erhält.

Im Job schreibt GitLab den Wert in eine temporäre Datei und gibt nur deren Pfad weiter. Das senkt das Risiko, dass der Wert in Unterprozessen, Crash-Dumps oder Telemetriedaten auftaucht. In Job-Logs maskiert GitLab den Wert, und sobald der Job endet, wird er verworfen. Anders als eine CI/CD-Variable ist ein Secret in der Projektkonfiguration nie lesbar. OpenBao verschlüsselt Secrets im Ruhezustand mit AES-256-GCM, sodass eine Kopie der Secrets-Datenbank nur Chiffretext enthält. Jobs rufen Werte direkt aus OpenBao ab, mit kurzlebigen Tokens, die an die Identität des jeweiligen Jobs gebunden sind. Secrets im Klartext gelangen so nicht in die GitLab-Anwendung.

So gelingt der Einstieg in den Secrets Manager:

Offengelegte Zugangsdaten widerrufen und nachverfolgen

Als das npm-Paket axios kompromittiert wurde, riet eine Sicherheitswarnung von SANS Teams, davon auszugehen, dass alle Umgebungsvariablen auf betroffenen Systemen exfiltriert wurden, und die Untersuchung auf CI/CD-Runner und Build-Infrastruktur auszuweiten. Incident-Response-Teams mussten herausfinden, welche Zugangsdaten jeder betroffene Job lesen konnte, wie sich der Zugriff unterbinden ließ und welche Ausführungen sie gelesen hatten.

Führt ein Job eine manipulierte Abhängigkeit aus, beschränkt sich die Offenlegung mit dem Secrets Manager auf die Secrets, die dieser Job deklariert hat und lesen durfte. Für die Bereinigung werden die offengelegten Zugangsdaten widerrufen und ersetzt, der Wert im Secrets Manager aktualisiert und genau dieser eine Job geprüft, während andere Pipelines weiterlaufen. Beim Anlegen eines Secrets schlägt der Secrets Manager vor, eine Erinnerung für die Rotation einzurichten. Dynamische Zugangsdaten folgen in Kürze und ermöglichen dann kurzlebigen Zugriff ohne manuelle Rotation.

GitLab streamt jedes Erstellen, Lesen, Aktualisieren und Löschen eines Secrets an die konfigurierten Ziele für Audit-Events und hält Änderungen im Audit-Trail fest. Jeder Lesezugriff aus einer Pipeline enthält die Pipeline- und Job-ID. Diese lassen sich dem Commit, der auslösenden Person und, sofern vorhanden, dem Merge Request zuordnen. Incident-Response- und Audit-Teams können einen Lesezugriff so auf die zugrunde liegende Änderung zurückführen, ohne Logs aus CI-System, Vault und Identity Provider abgleichen zu müssen. Audit-Events enthalten nie Secret-Werte.

Secrets mit den Berechtigungen des Codes verwalten

Je mehr Arbeit Agenten übernehmen, desto mehr Anfragen nach Pipelines und Servicekonten mit Zugangsdaten landen bei Plattform-Teams. Stauen sich diese Anfragen, greifen Teams auf weit gefasste Berechtigungen und gemeinsam genutzte Secrets zurück.

Der Secrets Manager nutzt den GitLab-Namespace als Isolationsgrenze. Projekte erben die Secrets der übergeordneten Gruppen, sodass gemeinsame Zugangsdaten nur einmal definiert werden. Owner vergeben Lese-, Schreib- und Löschrechte an bestimmte Personen oder Standardrollen, mit demselben Mitgliedschaftsmodell, das auch für den Code gilt. Wird eine Person oder das Servicekonto eines Agenten aus einem Projekt entfernt, endet auch der Zugriff dieser Identität auf die Secrets des Projekts.

Entwicklungsteams greifen über ihren bestehenden Projektzugriff auf Secrets zu. Funktioniert ein Verweis auf ein Secret nicht mehr, beheben sie ihn im selben Merge Request wie den Code, ohne zweites Repository, weitere Freigabe oder Zugriffsticket. Sind verwaltete Zugangsdaten nur eine Zeile entfernt, landen weniger Secrets in zu weit gefassten CI/CD-Variablen, lokalen Dateien oder im Repository.

Ein Speicher für Pipelines und Laufzeit-Workloads

Kubernetes, Terraform und Skripte erhalten oft eigene Secret-Speicher, jeweils mit eigenem Zugriffsmodell und eigenen Logs. Der Secrets Manager versorgt Laufzeit-Tools aus demselben Speicher wie die Pipelines, unter denselben Berechtigungen und mit demselben Audit-Trail:

• Kubernetes über den External Secrets Operator (ESO). ESO ruft das Secret in festgelegten Intervallen erneut ab und aktualisiert das Kubernetes Secret direkt. Ein rotierter Wert erreicht den Cluster so ohne Pipeline-Lauf.
• Terraform und OpenTofu. Beide lesen ein Secret beim Plan- oder Apply-Schritt als Datenquelle und halten Zugangsdaten aus .tfvars-Dateien und CI/CD-Variablen heraus.
• OpenBao- und Vault-CLIs über die Vault-kompatible API. Teams behalten ihre bestehenden Skripte und richten sie auf den Secrets Manager aus.
• Weitere Laufzeit-Tools über die Secrets-Manager-API.

Jedes Laufzeit-Tool authentifiziert sich mit einem Servicekonto oder einem Zugriffstoken. Diese Identität benötigt eine Projektmitgliedschaft und eine explizite Leseberechtigung für das Secret. GitLab stellt dann ein separates, fünf Minuten gültiges Token aus, mit dem das Tool das Secret abruft.

Wie der Secrets Manager die Lieferkettenkontrollen von GitLab ergänzt

Die Governed Software Factory von GitLab verbindet Code, Pipelines, Pakete und Secrets auf einer Plattform, mit einem Identitätsmodell und einer durchgängigen Aufzeichnung darüber, wie eine Änderung in die Produktion gelangt ist. Dependency Firewall entscheidet, welche Pakete in eine Pipeline aufgenommen werden, der Secrets Manager begrenzt, welche Zugangsdaten die Pipeline erreichen kann, und Artifact Central steuert, was ausgeliefert wird.

Im GitLab Security Standard, dem Framework von GitLab, mit dem Agenten schrittweise mehr Autonomie erhalten, unterstützt der Secrets Manager zwei der fünf Stufen. Bei Authorize bindet er jeden Job an die Secrets, die seine Identität und sein Geltungsbereich zulassen. Bei Respond streamt er jedes CRUD-Event.

Secret Push Protection blockiert Commits mit Zugangsdaten, bevor sie das Repository erreichen, und Secret Detection findet die Zugangsdaten, die bereits im Code und in der Historie liegen. Die GitLab Duo Agent Platform sichtet die Funde dieser Scans vorab und markiert wahrscheinliche False Positives. So muss das Team nur bei tatsächlich offengelegten Zugangsdaten widerrufen, rotieren und prüfen.

Die bestehenden GitLab-Integrationen für HashiCorp Vault, AWS Secrets Manager, Azure Key Vault und Google Cloud Secret Manager funktionieren weiterhin parallel zum Secrets Manager. Die Migration kann daher im eigenen Tempo erfolgen.

Erste Schritte

GitLab Secrets Manager ist ein kostenpflichtiges Add-on für Premium und Ultimate und wird über GitLab Credits abgerechnet: 1 Credit pro gespeichertem Secret und Monat sowie 1 Credit pro 2.500 Lesevorgängen. Für Air-Gapped-Umgebungen ist eine Enterprise-Lizenzvereinbarung verfügbar.

• Auf GitLab.com können Owner von Top-Level-Gruppen den GitLab Secrets Manager kostenlos testen, für 30 Tage oder 500 Evaluierungs-Credits, je nachdem, was zuerst endet. Dazu in der Top-Level-Gruppe Secure > Secrets Manager und anschließend Start 30-day trial auswählen.
• Auf GitLab Self-Managed muss die Administration den Secrets Manager installieren und aktivieren und dabei die dokumentierten Empfehlungen zu Dimensionierung und Hochverfügbarkeit beachten.
• Die Unterstützung für GitLab Dedicated folgt in Kürze.

Welche Zugangsdaten zuerst umziehen sollten, zeigt das Secret-Audit-Tool für CI/CD-Variablen: Es markiert Variablen, die wahrscheinlich Zugangsdaten enthalten. Ein Migrations-Workflow für CI/CD-Variablen ist in Entwicklung.

Vorschläge oder Feedback? Gerne im Feedback-Issue zum Secrets Manager.