CI/CD-Zugangsdaten absichern mit GitLab Secrets Manager

Aktualisierung vom 20. August 2026: GitLab Secrets Manager ist jetzt in Limited Availability als kostenpflichtiges Add-on verfügbar und wird über GitLab Credits abgerechnet. Er stellt Pipeline-Secrets job-genau bereit und arbeitet nun auch außerhalb von CI, etwa in Kubernetes, in Infrastructure as Code oder über die API. Ab sofort auf GitLab.com verfügbar.

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 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 Last 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 und 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, etwa 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 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. Enges 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, sodass sich nicht jeder Einzelfall aufzählen lässt. 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, und die 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, sodass Änderungen am Secrets-Inventar neben den übrigen Governance-Aufzeichnungen stehen. 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

Jetzt ausprobieren

GitLab Secrets Manager ist in Limited Availability als kostenpflichtige Funktion verfügbar, abgerechnet über GitLab Credits, für Premium und Ultimate auf GitLab.com. Für Self-Managed-Deployments befindet er sich in der Beta, Unterstützung für GitLab Dedicated folgt in Kürze.

Auf GitLab.com: das erste 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, sodass sich die Einführung im eigenen Tempo gestalten lässt.

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 im Unternehmen nachverfolgen
• Supply-Chain-Risiken mit SBOM-basiertem Dependency Scanning reduzieren
• Vollständige Security-Scanner-Abdeckung der Codebase in Minuten