CI/CD-Zugangsdaten absichern mit GitLab Secrets Manager

Viele Zugangsdaten-Leaks beginnen gleich: Jemand braucht ein Credential, hat keinen geeigneten Ort dafür und improvisiert. Das Ergebnis ist eine CI/CD-Variable mit zu weitreichenden Berechtigungen, eine Konfigurationsdatei oder eine .env-Datei, die „nur kurz" committet wird.

GitLab Secrets Manager, jetzt in der öffentlichen Beta mit GitLab 19.0, speichert Credentials auf derselben Plattform, die auch den Code und die Pipelines ausführt. Jedes Secret ist auf die Jobs beschränkt, die es benötigen, und unterliegt den Zugriffskontrollen, die bereits für Code gelten. Weniger Secrets landen am falschen Ort – und wenn eines kompromittiert wird, bleibt der Schadenskreis kleiner.

Wo Secrets normalerweise landen

Entwicklungsteams greifen oft standardmäßig auf CI/CD-Variablen zurück. Variable auf Projekt- oder Gruppenebene setzen, Wert maskieren, Pipeline aktualisieren. Von da an wird der Wert in jeden Job injiziert, und jede Person mit Pipeline-Zugriff kann ihn lesen. Dieses Muster widerspricht dem Least-Privilege-Prinzip – hält aber den Build am Laufen.

Die übliche Alternative ist ein eigenständiger Vault. Das holt die Secrets zwar aus der CI/CD-Konfiguration heraus, bringt aber eine dauerhafte operative Steuer mit sich: ein weiteres System zur Authentifizierung, ein weiteres Zugriffsmodell zur Pflege und ein weiterer Audit-Stream, der bei einem Incident manuell korreliert werden muss.

Secrets Manager in bestehenden Projekten ausprobieren

GitLab Secrets Manager ist eine native GitLab-Funktion auf Basis von OpenBao – bereits Teil der Plattform, sodass Credentials innerhalb der bestehenden Projekt- und Gruppenstruktur bleiben.

Ein Secret lässt sich aus CI/CD-Variablen herauslösen, indem es in der .gitlab-ci.yml mit dem Schlüsselwort secrets: deklariert wird:

      deploy:
  secrets:
    DATABASE_PASSWORD:
      gitlab_secrets_manager:
        name: db-password
  script:
    - deploy --password $DATABASE_PASSWORD

    

Standardmäßig schreibt GitLab das Secret in eine temporäre Datei und stellt den Pfad als Umgebungsvariable bereit, die auf diesen Job beschränkt ist. Die Übergabe des Pfads statt des Werts reduziert die Offenlegung in Unterprozessen, Crash-Dumps und Telemetriedaten.

Das Zugriffsmodell, das bereits besteht

Ein eigenständiger Secrets Manager zwingt dazu, zwei Zugriffsmodelle parallel zu pflegen. Jedes Team, jede Anwendung und jede Berechtigungsgrenze, die bereits in GitLab modelliert ist, muss im Secrets-Tool nachgebaut und synchron gehalten werden – wenn Teammitglieder hinzukommen, Rollen wechseln oder das Unternehmen verlassen. Driften die beiden Systeme auseinander – wenn ausgeschiedene Teammitglieder weiterhin Zugriff behalten oder Anwendungen Berechtigungen ansammeln, die sie nicht mehr benötigen – entstehen ausnutzbare Lücken.

Secrets Manager nutzt die bestehende Gruppen- und Projektstruktur als Isolierungsgrenze – ohne separate Struktur, die aufgebaut und gepflegt werden müsste. Lese-, Erstellungs-, Aktualisierungs- und Löschberechtigungen lassen sich pro Teammitglied, Gruppe oder Rolle festlegen – mit denselben Kontrollen wie für Code. Secrets auf Gruppenebene stehen jedem darunter liegenden Projekt zur Verfügung: gemeinsame Credentials einmal definieren, überall vererben. Verlässt jemand das Projekt oder wird entfernt, erlischt der Zugriff auf die zugehörigen Secrets sofort.

Projektspezifische Credentials im GitLab Secrets Manager

Jedes Secret auf den Job beschränkt, der es benötigt

Als das Axios-npm-Paket im März 2025 kompromittiert wurde, mussten Organisationen, die eine betroffene Version einsetzten, davon ausgehen, dass alle Credentials, die ihre Pipelines berührt hatten, in Angreiferhänden lagen. Kompromittierte Secrets mussten rotiert, jedes erreichbare System geprüft werden.

Je weiter der Geltungsbereich eines Secrets reicht, desto größer das Schadensausmaß bei einer Kompromittierung – und das Entwicklungsteam trägt diese Kosten neben dem Sicherheitsteam, in Form von blockierten Merges und fehlgeschlagenen Builds. Enger Scoping begrenzt die Bereinigung auf die Systeme, die ein kompromittiertes Credential tatsächlich erreichen konnte.

Secrets Manager begrenzt das Schadensausmaß, indem er jedes Credential auf den Job beschränkt, der es benötigt. Welche Jobs ein bestimmtes Secret abrufen dürfen, entscheidet das System anhand von drei Job-Attributen: Zielumgebung, Branch und ob dieser Branch geschützt ist. Wildcards funktionieren bei Umgebung und Branch. Da die Geltungsbereiche durch Job-Attribute definiert werden, die GitLab bereits erfasst, ist kein zweites System erforderlich, das mit der Pipeline abgeglichen werden müsste.

Wenn ein Job ausgeführt wird, fordert er den Wert des benötigten Secrets an. Das Secrets-Backend verifiziert die Job-Identität, prüft Branch und Umgebung gegen die Scope-Regeln – und gibt den Wert erst dann zurück. Bedingungen lassen sich kombinieren: Eine einzelne Regel kann verlangen, dass ein Job auf einem geschützten Branch läuft und eine production/*-Umgebung ansteuert, bevor er Credentials erhält. Endet der Job, wird das Secret verworfen. Nichts bleibt auf dem Runner; Job-Protokolle werden maskiert. Eine CI-Variable hingegen bleibt in der Projektkonfiguration auf unbestimmte Zeit lesbar.

Ein Secret bis zur Pipeline zurückverfolgen

Wenn ein Secret kompromittiert wird oder eine Abhängigkeit betroffen ist, muss das Incident-Response-Team das Credential durch jede Pipeline und jeden Job verfolgen, der es verwendet hat. Bisher bedeutete das: Logs aus CI-System, Secrets-Tool, Identity Provider und allen weiteren Berührungspunkten manuell zusammenführen.

GitLab Secrets Manager protokolliert Erstellungs-, Aktualisierungs- und Löschereignisse für Secrets auf Projekt- und Gruppenebene im selben Audit-Trail wie die übrige Plattform – Änderungen am Secrets-Inventar stehen neben den übrigen Governance-Aufzeichnungen. Secret-Abrufe aus CI/CD-Pipelines werden als Audit Events mit Pipeline- und Job-IDs gestreamt: Das Incident-Response-Team kann nachvollziehen, wo ein Secret verwendet wurde, ohne Daten aus verschiedenen Systemen manuell zu korrelieren. Audit-Logging ist für Self-Managed-Deployments bereits verfügbar; GitLab.com-Unterstützung folgt während des öffentlichen Beta-Programms.

Secrets Manager in Aktion

An der öffentlichen Beta teilnehmen

GitLab Secrets Manager ist in der öffentlichen Beta für Premium- und Ultimate-Nutzer auf GitLab.com und Self-Managed-Deployments verfügbar. GitLab Dedicated folgt in Kürze.

Auf GitLab.com: Opt-in und erstes Secret erstellen. Für Self-Managed-Deployments: Installationsschritte folgen und Secrets Manager als Entwicklungsteam nutzen.

Die Integrationen für HashiCorp Vault, AWS Secrets Manager, Azure Key Vault und Google Cloud Secret Manager laufen neben GitLab Secrets Manager weiter – für eine Einführung im eigenen Tempo.

Der Secrets Manager ist während der Beta-Phase kostenlos. Nach General Availability wird er als kostenpflichtige Funktion über GitLab Credits abgerechnet – Opt-in erforderlich, mit rechtzeitiger Ankündigung vor GA.

Feedback einreichen, damit die Funktion vor GA weiterentwickelt werden kann.

Weitere Beiträge zu GitLab 19.0

• GitLab 19.0 veröffentlicht
• Mehr KI-Modelle für GitLab Duo Agent Platform Self-Hosted
• Merge Requests von manuellen Aufgaben in einen automatisierten Workflow verwandeln
• CI-Komponentennutzung in deinem Unternehmen nachverfolgen
• Supply-Chain-Risiken reduzieren – mit SBOM-basiertem Dependency Scanning
• Vollständige Security-Scanner-Abdeckung der Codebase in Minuten