GitLab Secrets Manager

Höhere Agentengenauigkeit, geringere Token-Kosten
Mehr dazu, wie du deine Software Factory stärkst und KI-Agenten Autonomie gewinnen lässt, ohne an Sicherheit einzubüßen.
Über die neuesten Funktionen und Verbesserungen auf dem Laufenden bleiben.
Keine Ausweitung von Secrets mehr mit GitLab Secrets Manager, basierend auf OpenBao. Pipeline- und Laufzeit-Secrets werden aus einem einzigen Speicher gelesen und durch Berechtigungen und Audit-Trails reguliert, die bereits für deinen Code gelten.
Secrets dort verwalten, wo Entwickler(innen) bereits arbeiten
Mit GitLab Secrets Manager befinden sich die Secrets in denselben Gruppen und Projekten wie der Code, der sie verwendet. Daher fügt sich die Anforderung von Secrets in den normalen Workflow ein, ohne dass ein Plugin, ein Agent oder ein zweites Tool erlernt werden muss.
Der Zugriff richtet sich nach deiner bestehenden Gruppen- und Projekthierarchie, und verfeinerte Berechtigungen bieten zusätzliche Kontrolle, sodass kein zweites Zugriffsmodell synchronisiert werden muss. Definiere Zugangsdaten einmalig auf Projektebene oder teile sie gruppenweit. Wer ein Projekt verlässt, verliert automatisch den Zugriff.
Entwickler(innen) deklarieren ein Secret, das ein Job erfordert, mit dem Schlüsselwort „secrets:“ in der Pipeline-Konfigurationsdatei. GitLab kennt bereits das Projekt, den Branch und die Umgebung des Jobs, sodass keine Identität zwischen CI und einem separaten Vault verknüpft werden muss.
Wenn eine Secrets-Referenz fehlerhaft ist, wird der Fix zusammen mit dem Code im selben Merge Request bereitgestellt, ohne zweites Repository oder Genehmiger(in). Da sichere Zugangsdaten nur eine Zeile entfernt sind, landen weniger Secrets in CI-Variablen, lokalen Konfigurationsdateien oder im Repository.
Begrenzter Wirkungsbereich von ungeschützten Zugangsdaten
Wenn eine kompromittierte Abhängigkeit innerhalb eines Jobs ausgeführt wird, bedeutet die Bereinigung mit GitLab Secrets Manager, dass die Secrets, auf die dieser Job zugreifen könnte, rotiert und überprüft werden, ohne jede Pipeline einzufrieren.
Im Gegensatz zu CI-Variablen, die jeden Job in der Pipeline erreichen, erreicht ein Secret nur die Jobs, die es deklarieren und in seinen Geltungsbereich fallen: Branch, Umgebung und Schutzstatus.
Secrets Manager schreibt den Wert in eine temporäre Datei und gibt nur dessen Pfad preis, wodurch die Offenlegung in Unterprozessen, Absturzprotokollen und Telemetriedaten eingeschränkt wird. Der Wert wird in den Job-Protokollen maskiert und beim Beenden des Jobs verworfen, sodass nichts auf dem Runner erhalten bleibt.
Erstell-, Lese-, Aktualisierungs- und Lösch-Ereignisse werden im selben Audit-Trail erfasst wie der Rest von GitLab. Pipeline-Lesevorgänge enthalten Pipeline- und Job-IDs, sodass zuständige Personen und Auditor(inn)en Zugangsdaten vom Zugriff bis zur Bereitstellung nachverfolgen können, ohne Protokolle systemübergreifend manuell korrelieren zu müssen.
Ein zentraler Speicherort für Pipelines, Cluster und Infrastruktur
Pipelines lesen Secrets direkt aus. Kubernetes-Workloads, Terraform- und OpenTofu-Vorgänge, Vault-kompatible CLI-Tools und andere Automatisierungen verbinden sich über Standardintegrationspunkte, mit denselben Berechtigungen und demselben Audit-Trail wie Pipelines.
Der External Secrets Operator synchronisiert die Kubernetes-Secrets mit GitLab, sodass rotierte Werte ohne erneute Bereitstellung weitergegeben werden. Terraform und OpenTofu lesen Secrets als Datenquelle beim Ausführen, wodurch Zugangsdaten aus Dateien und CI/CD-Variablen ferngehalten werden.
Secrets Manager basiert auf OpenBao und stellt eine Vault-kompatible API bereit, sodass Teams, die bereits mit der OpenBao- oder Vault-CLI skripten, ihre gewohnten Befehle beibehalten können. Jede andere Automatisierung ruft Secrets über die Secrets Manager-API ab, anstatt Zugangsdaten fest zu codieren oder separate Variablendateien zu verwalten.
Zugangsdaten folgen Multi-Cloud-, Hybrid- und lokalen Workloads ohne plattformspezifische Identitätsföderation. Die Verlagerung eines Workloads in eine andere Cloud bedeutet nicht, dass ein zweiter Speicher eingerichtet werden muss, und Secrets, die sonst über konto- und regionsspezifische Speicher verstreut wären, bleiben an einem Ort.
GitLab bietet mehr als nur die Verwaltung von Zugangsdaten. Push-Schutz bei Erkennung von Secrets verhindert, dass Zugangsdaten das Repository erreichen, die clientseitige Erkennung erfasst Secrets im Text von Issues und Merge Requests, und die Pipeline-Erkennung von Secrets findet welche, die bereits im Code vorhanden sind. Duo Agent Platform sichtet die Funde und kennzeichnet wahrscheinliche falsch positive Ergebnisse.
GitLab Secrets Manager ist eine kostenpflichtige Erweiterung für Premium und Ultimate und wird über GitLab Credits abgerechnet: 1 Credit pro gespeichertem Secret pro Monat und 1 Credit pro 2.500 Secrets-Lesevorgängen. Falls du eine Pauschale bevorzugst, ist ein Enterprise License Agreement (ELA) verfügbar.
Du nutzt bereits Premium oder Ultimate? Dann kannst du GitLab Secrets Manager 30 Tage lang bzw. bis zum Ablauf von 500 Evaluierungs-Credits kostenlos testen – je nachdem, was zuerst eintritt.
GitLab hat dieses Fälligkeits-Framework auf Basis seiner Arbeit mit branchenführenden Kunden entwickelt. Beantworte einige Fragen dazu, wie dein Team mit Sicherheit und Compliance umgeht, um dein Fälligkeitsergebnis und Empfehlungen für die nächste Stufe zu erhalten.
Quiz von maximal 5 Minuten
Sie bleiben bestehen, und nichts wird automatisch migriert. CI/CD-Variablen eignen sich weiterhin gut für unempfindliche Konfigurationen. Um Kandidaten für die Migration zu finden, verwende das Secrets Audit Tool für CI/CD-Variablen, um herauszufinden, welche Variablen Zugangsdaten enthalten. Anschließend verschiebst du diese Werte nach deinem eigenen Zeitplan in den Secrets Manager.
Ja, unverändert. Die bestehenden Integrationen für HashiCorp Vault, AWS Secrets Manager, Azure Key Vault und Google Cloud Secret Mana