Secrets Manager
Keine Ausweitung von Geheimnissen mehr mit GitLab Secrets Manager, basierend auf OpenBao. Pipeline- und Laufzeitgeheimnisse werden aus einem einzigen Speicher gelesen und durch die Berechtigungen und Audit-Trails reguliert, die bereits für deinen Code gelten.
Geheimnisse dort verwalten, wo Entwickler(innen) bereits arbeiten
Mit GitLab Secrets Manager befinden sich die Geheimnisse in denselben Gruppen und Projekten wie der Code, der sie verwendet. Daher fügt sich die Anforderung von Geheimnissen 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 das Geheimnis, 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 Geheimnisreferenz 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 Geheimnisse 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 Geheimnisse, 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 Geheimnis 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 Geheimnisse 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-Geheimnisse mit GitLab, sodass rotierte Werte ohne erneute Bereitstellung weitergegeben werden. Terraform und OpenTofu lesen Geheimnisse 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 Geheimnisse ü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 Geheimnisse, die sonst über konto- und regionsspezifische Speicher verstreut wären, bleiben an einem Ort.
[ SCHUTZ ]
Geheimnislecks blockieren und aufspürenGitLab bietet mehr als nur die Verwaltung von Zugangsdaten. Push-Schutz bei Erkennung von Geheimnissen verhindert, dass Zugangsdaten das Repository erreichen, die clientseitige Erkennung erfasst Geheimnisse im Text von Issues und Merge Requests, und die Pipeline-Erkennung von Geheimnissen findet Geheimnisse, die bereits im Code vorhanden sind. Duo Agent Platform sichtet die Funde und kennzeichnet wahrscheinliche falsch positive Ergebnisse.
[ PREISE ]
Du zahlst nur für das, was du nutzt.GitLab Secrets Manager ist eine kostenpflichtige Erweiterung für Premium und Ultimate und wird über GitLab Credits abgerechnet: 1 Credit pro gespeichertem Geheimnis pro Monat und 1 Credit pro 2.500 Geheimnislesevorgängen. Falls du eine Pauschale bevorzugst, ist ein Enterprise License Agreement (ELA) verfügbar.
// NÄCHSTE SCHRITTE
Du nutzt bereits Premium oder Ultimate? Hauptgruppeneigentümer(innen) können GitLab Secrets Manager 30 Tage lang oder bis zum Ablauf von 500 Evaluierungs-Credits kostenlos testen, je nachdem, was zuerst eintritt.
Jetzt testenLiefert deine Sicherheitsmodernisierung
im großen Maßstab ab?
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
Häufig gestellte Fragen