Best Practices für die Verwaltung von Geheimnissen mit HashiCorp Vault in CI / CD

Die sichere Verwaltung von Geheimnissen ist ein kritischer Aspekt moderner CI/CD-Pipelines. Jedes Leck von API-Schlüsseln, Datenbankanmeldeinformationen oder Token kann zu katastrophalen Datenverstößen, Compliance-Verstößen und Reputationsschäden führen. HashiCorp Vault bietet eine robuste, unternehmensweite Lösung für das Geheimmanagement, die es Unternehmen ermöglicht, sensible Daten während des gesamten Entwicklungs- und Bereitstellungslebenszyklus zu schützen. Durch die Übernahme von Best Practices für die Vault-Integration können Teams die Exposition minimieren, die Rotation automatisieren und strenge Zugriffskontrollen durchsetzen, ohne die Lieferung zu verlangsamen.

Dieser Leitfaden beschreibt bewährte Strategien für die Verwendung von HashiCorp Vault in CI/CD-Umgebungen. Sie lernen, wie man dynamische Geheimnisse nutzt, feinkörnige Richtlinien implementiert, Datentransporte und -ruhen verschlüsselt, Anmeldeinformationen kontinuierlich rotiert und alle geheimen Zugriffe überwacht. Wir decken auch Integrationsmuster für wichtige CI/CD-Tools wie Jenkins, GitLab CI und GitHub-Aktionen ab, zusammen mit häufigen Fallstricken, die es zu vermeiden gilt.

Die Einhaltung dieser Praktiken stärkt nicht nur Ihre Sicherheitslage, sondern optimiert auch die operativen Arbeitsabläufe, reduziert den manuellen Aufwand und trägt dazu bei, regulatorische Anforderungen wie SOC 2, PCI DSS und HIPAA zu erfüllen.

HashiCorp Vault in CI/CD verstehen

HashiCorp Vault ist ein Tool, das den Zugriff auf Token, Passwörter, Zertifikate und andere Geheimnisse sicher speichert und streng kontrolliert. In CI/CD-Workflows kann Vault Geheimnisse dynamisch generieren, geheimen Lebenszyklus verwalten und Zugriffsrichtlinien durchsetzen. Im Gegensatz zu statischen Geheimnissen, die in Konfigurationsdateien oder Umgebungsvariablen fest codiert sind, behandelt Vault Geheimnisse als ephemere Ressourcen, die auf Anforderung erstellt und nach Gebrauch automatisch widerrufen werden.

Vault integriert sich mit CI/CD-Systemen über seine REST API, CLI und native Authentifizierungs-Plugins.

  • Authentication: Die CI/CD-Pipeline authentifiziert sich mit einer sicheren Methode wie AppRole, Kubernetes auth oder einem kurzlebigen Token, das vom CI-Tool injiziert wird.
  • Geheimer Abruf: Während einer Build- oder Bereitstellungsphase fordert die Pipeline Geheimnisse von Vault an - entweder statische Geheimnisse aus einem KV-Speicher oder dynamische Geheimnisse aus einer Datenbank, Cloud oder PKI-Engine.
  • Nutzung: Secrets werden vorübergehend in Umgebungsvariablen, Konfigurationsdateien oder Befehlsargumente eingespeist und dann für Aufgaben wie die Verbindung zu einer Datenbank, das Signieren von Artefakten oder die Bereitstellung bei einem Cloud-Anbieter verwendet.
  • Cleanup: Nach Gebrauch widerruft die Pipeline temporäre Anmeldeinformationen oder entschärft Umgebungsvariablen, um das Expositionsfenster zu verkleinern.

Dieser Ansatz eliminiert die Notwendigkeit, Geheimnisse in Git-Repositories, CI/CD-Konfigurationsdateien oder Artefakt-Registern zu speichern, was die Angriffsfläche drastisch reduziert.

Grundprinzipien des Geheimmanagements mit Vault

1. Verwenden Sie dynamische Geheimnisse

Statische Geheimnisse — wie ein einzelnes Datenbankpasswort, das jahrelang verwendet wurde — sind eine Sicherheitsverbindlichkeit. Wenn sie kompromittiert werden, gewähren sie dauerhaften Zugriff, bis sie manuell gedreht werden. Die dynamischen geheimen Engines von Vault erstellen im laufenden Betrieb Anmeldeinformationen mit kurzen Time-to-Live-Werten (TTL-Werten). Vault kann beispielsweise ein eindeutiges, zeitlich begrenztes Passwort für einen PostgreSQL-Benutzer oder einen IAM-Zugriffsschlüssel für eine AWS-Rolle generieren.

Dynamische Geheimnisse bieten mehrere Vorteile:

  • Kurze Lebensdauer: Geheimnisse verfallen automatisch, oft innerhalb von Minuten oder Stunden.
  • Per-session uniqueness: Jede Pipeline erhält unterschiedliche Anmeldeinformationen, so dass es unmöglich ist, ein kompromittiertes Geheimnis aus einem früheren Build wiederzuverwenden.
  • Automatischer Widerruf: Vault kann dynamische Geheimnisse sofort nach Abschluss der Pipeline oder nach Ablauf der TTL widerrufen.

Um dynamische Geheimnisse zu implementieren, konfigurieren Sie eine geheime Engine (z. B. Datenbank, AWS, Azure) mit einer definierten Rolle und standardmäßiger TTL. Ihre Pipeline fordert dann einen Leasingvertrag für diese Rolle an und verwendet die zurückgegebenen Anmeldeinformationen nur für die Dauer des Auftrags.

2. Einführung einer feinkörnigen Zugangskontrolle

Vault-Richtlinien sind in HCL (HashiCorp Configuration Language) geschrieben und folgen einem pfadbasierten Berechtigungsmodell. Jede Richtlinie gewährt oder verweigert den Zugriff auf bestimmte geheime Pfade und Fähigkeiten (lesen, erstellen, aktualisieren, löschen, auflisten, sudo).

Beachten Sie diese Leitlinien:

  • Role-based policies: Create separate Richtlinien für Entwicklung, Staging und Produktionspipelines. Ein CI-Jobbuilding eines Feature-Zweigs sollte niemals Zugriff auf Produktionsgeheimnisse haben.
  • Wegebeschränkungen: Beschränken Sie den Zugriff auf nur die genauen geheimen Pfade, die benötigt werden.
  • Zeitgebundener Zugriff: Kombinieren Sie Richtlinien mit Token-TLs und Erneuerungslimits.
  • Verwenden Sie Identitäten: Leverage Vault Identity Entities and Groups to attached policies to specific CI/CD tools, jobs, or service accounts.

Beispiel minimale Politik für eine CI-Pipeline:

path "database/creds/ci-app" {
 capabilities = ["read", "list"]
}

path "secret/data/ci/*" {
 capabilities = ["read", "list"]
}

path "auth/token/lookup-self" {
 capabilities = ["read"]
}

3. Geheimnisse in Ruhe und Transit verschlüsseln

Vault verschlüsselt automatisch alle in seinem Backend gespeicherten Daten mit einem Master-Schlüssel. Dieser Schlüssel ist selbst verschlüsselt und kann mit einem externen Schlüsselverwaltungsdienst (KMS) oder einem Hardware-Sicherheitsmodul (HSM) verwaltet werden. Der Verschlüsselungstransfer ist jedoch ebenso wichtig. Die gesamte Kommunikation zwischen CI/CD-Agenten und Vault sollte TLS 1.2 oder höher verwenden.

Best Practices:

  • Aktivieren Sie TLS: Konfigurieren Sie den Vault-Server mit einem gültigen Zertifikat einer vertrauenswürdigen CA oder einer internen PKI.
  • Zertifikate überprüfen: CI/CD-Clients müssen die Zertifikatskette des Vault-Servers überprüfen.
  • Verwenden Sie, wenn möglich, gegenseitiges TLS: Für zusätzliche Sicherheit benötigen Sie Client-Zertifikate von CI/CD-Systemen.
  • Vermeiden Sie Klartext über das Netzwerk: Holen Sie niemals Geheimnisse über HTTP oder unverschlüsselte Verbindungen ab. Die meisten CI/CD-Agenten unterstützen Umgebungsvariablen, die die Vault-Adresse und das Token sicher einfügen können.

4. Automatische Geheimrotation

Regelmäßige Rotation reduziert den Schaden durch ein durchgesickertes Geheimnis. Die dynamischen Geheimnisse von Vault werden automatisch mit jeder Leasinganforderung gedreht, aber statische Geheimnisse in KV-Stores müssen ebenfalls rotiert werden. HashiCorp empfiehlt die Verwendung der Mechanismen von Vault für die Rotation und sowie periodische Richtlinien, um die Rotation auf Anwendungsebene zu erzwingen.

Um die Rotation statischer Geheimnisse zu automatisieren:

  • Speichern Sie statische Geheimnisse in der KV v2-Engine von Vault, die Versionierungs- und Check-and-Set-Operationen unterstützt.
  • Schreibe einen geplanten Job (cron, Nomad Periodic Batch oder CI Pipeline), der neue Werte generiert und in Vault schreibt.
  • Aktualisieren Sie abhängige Systeme (Datenbanken, API-Gateways) mit dem neuen Geheimnis über das Plugin-Ökosystem von Vault oder externe Skripte.
  • Verwenden Sie Vaults Endpunkt, um den Root-Verschlüsselungsschlüssel in regelmäßigen Abständen zu drehen.

5. Zugang zu Audits und Monitoren

Vault protokolliert jede authentifizierte Anfrage an seine Überwachungsgeräte. Sie können Auditprotokolle an Dateien, Syslog oder externe Dienste wie Elasticsearch, Splunk oder Datadog senden. Auditprotokolle enthalten die Client-IP, die Authentifizierungsmethode, den Anforderungspfad, die Antwortdaten (falls zulässig) und alle Fehler.

Wichtige Überwachungspraktiken:

  • Auditprotokollierung aktivieren: Konfigurieren Sie mindestens ein Auditgerät und verwenden Sie ein sicheres Ziel, das nur anhänglich ist, um Manipulationen zu verhindern.
  • Erstelle Warnungen für fehlgeschlagene Authentifizierungsversuche, Zugriff auf sensible Pfade (z. B. Anmeldeinformationen für Produktionsdatenbanken) oder Leasing-Widerrufe.
  • Review regular: Periodically audit policy use and access patterns. Remove unused policies or paths.
  • Verwenden Sie Vaults Endpunkt: Für das Echtzeit-Streaming von Protokolleinträgen, hilfreich für das Debuggen während CI/CD-Läufen.

Integration von Vault in CI/CD Pipelines

Authentifizierungsverfahren für CI/CD

Die Wahl der richtigen Authentifizierungsmethode ist für die Sicherheit und Benutzerfreundlichkeit von entscheidender Bedeutung.

  • AppRole: Empfohlen für die Machine-to-Machine-Authentifizierung. Ein CI/CD-Dienst erstellt eine Vault-Rolle mit und . Die Pipeline authentifiziert sich, indem sie beide präsentiert und ein kurzlebiges Client-Token erhält.
  • Kubernetes Auth: Ideal für Pipelines, die in Kubernetes laufen. Vault validiert das Kubernetes Service Account-Token über den Kubernetes API-Server und gibt ein Vault-Token basierend auf den gebundenen Richtlinien des Service Accounts aus.
  • AWS/GCP/Azure Auth: Für Pipelines, die auf Cloud-Anbietern laufen, kann Vault die Instanz-Metadaten oder die IAM-Rolle überprüfen, um Token ohne fest codierte Schlüssel auszugeben.
  • Token-Based: Für einfache Setups kann ein CI/CD-Tool wie Jenkins ein Vault-Token als geheime Variable einfügen.

Immer dynamische, gebundene Authentifizierung gegenüber statischen Token bevorzugen: Konfigurieren Sie Token-TLs so, dass sie der maximalen Pipelinelaufzeit entsprechen (z. B. 30 Minuten) und legen Sie eine angemessene Anzahl von Nutzungen fest (falls zutreffend).

Integration mit spezifischen CI/CD Tools

Jenkins: Verwenden Sie das HashiCorp Vault Plugin. Konfigurieren Sie eine Vault Serveradresse, Authentifizierungsmethode (AppRole oder Token) und definieren Sie Pipelines, die Geheimnisse über Schritte abrufen. Das Plugin unterstützt base64-Codierung, Dateiinjektion und Zuordnung von Umgebungsvariablen.

GitLab CI: GitLab CI unterstützt Vault nativ über das -Token. Konfigurieren Sie Vault, um JWT-Authentifizierung von GitLabs JWT-Emittent zu akzeptieren. Verwenden Sie in den -Block, um ein Vault-Token anzufordern und dann Geheimnisse mithilfe der Vault CLI oder API abzurufen.

GitHub-Aktionen: Verwenden Sie die GitHub-Aktion. Es unterstützt OIDC-Authentifizierung (empfohlen), Token oder AppRole. Fügen Sie einen Schritt hinzu, der Geheimnisse Umgebungsvariablen zuordnet oder in Dateien schreibt. Für OIDC konfigurieren Sie Vault mit einer JWT-Auth-Methode, die dem Emittenten vertraut und an bestimmte Repositorien oder Zweige gebunden ist.

CircleCI: Verwenden Sie die Vault-Orb oder direkte API-Aufrufe. Die Kontextfunktion von CircleCI kann ein Vault-Token speichern, aber AppRole oder OIDC werden bevorzugt.

Beispiel-Workflow mit AppRole in Jenkins

Stellen Sie sich eine Jenkins-Pipeline vor, die ein Docker-Image erstellt und in einem Kubernetes-Cluster bereitstellt. Anstatt das Kubernetes-Konfigurations- und Registrierungspasswort in Jenkins zu speichern, holt es sie zur Laufzeit von Vault ab.

  1. Vorkonfigurieren Vault: Erstellen Sie eine Richtlinie, die den Lesezugriff auf und ermöglicht. Erstellen Sie eine AppRole-Rolle mit dieser Richtlinie, einer TTL von 10 Minuten und einer , die in Jenkins als Anmeldeinformationen gespeichert ist.
  2. Pipeline Step: Verwenden Sie das HashiCorp Vault Plugin mit der AppRole-Rollen-ID (auch ein Credential) und der SecretID. Das Plugin authentifiziert und erhält ein Vault-Token.
  3. Fetch Secrets: Lesen Sie das Docker-Registrierungspasswort und das Kubernetes-Token von Vault. Das Plugin schreibt sie in temporäre Umgebungsvariablen oder Dateien.
  4. ]Nutzung: ] Führen Sie mit den Anmeldeinformationen aus.
  5. Cleanup: Optional widerrufen Sie die AppRole SecretID, wenn die Wiederverwendbarkeit nicht gewünscht ist.

Fortgeschrittene Überlegungen

Secret Engines und ihre Anwendungsfälle

Vault unterstützt viele geheime Engines. Für CI/CD sind die wichtigsten:

  • KV v2 (Key-Value): Speichern Sie statische Geheimnisse wie API-Schlüssel, Zertifikate oder umgebungsspezifische Einstellungen.
  • Datenbank: Generieren Sie temporäre Datenbankbenutzer mit dynamischen Anmeldeinformationen für MySQL, PostgreSQL, MongoDB und andere.
  • Cloud-Provider (AWS, Azure, GCP): Generieren Sie temporäre IAM-Rollen, Service-Prinzipale oder Speicherkontoschlüssel.
  • PKI: Ausgabe von kurzlebigen TLS-Zertifikaten für mTLS zwischen Microservices oder für Container-Register.
  • Transit: Verschlüsseln/Entschlüsseln von Daten ohne Speicherung – nützlich für die Verschlüsselung von Artefakten, bevor sie in einem Repository gespeichert werden.

Best Practices für Policy Design

Gestaltung von Richtlinien mit einer klaren Namenskonvention und hierarchischen Struktur, z. B.:

  • – für CI-spezifische Geheimnisse.
  • – für die Inszenierung von Umgebungsgeheimnissen.
  • – für Produktionsgeheimnisse (mit sehr eingeschränktem Zugriff).

Die Verwendung von deny-Regeln ist sparsam; die Standard-Deny von Vault ist ausreichend. Kombinationen von und sollten getestet werden, bevor sie in die Produktion eingeführt werden. Der Vault CLI-Befehl ist hilfreich für die Validierung.

Backup und Disaster Recovery

Das Storage-Backend von Vault (Konsul, Floß, Datei usw.) muss regelmäßig gesichert werden. Wenn Sie integrierten Speicher (Raft) verwenden, aktivieren Sie Snapshot-Backups. Bei CI/CD-Pipelines, die für alle Geheimnisse von Vault abhängen, wird ein Vault-Ausfall die Bereitstellungen unterbrechen.

  • Ausführen von Vault in einer hochverfügbaren (HA) Konfiguration mit mindestens drei Knoten.
  • Speichern eines Fallback-Satzes von Geheimnissen in einem alternativen verschlüsselten Speicher (z. B. AWS Secrets Manager) mit einer kurzen TTL - aber behandeln Sie dies als letzten Ausweg.
  • Testen von Disaster Recovery-Verfahren regelmäßig, einschließlich Wiederherstellung von einem Snapshot.

Häufige Fallstricke zu vermeiden

  • Hardcoding eines Vault-Tokens in CI/CD-Variablen: Selbst wenn das Token als geheime Variable gespeichert ist, kann es durch Build-Protokolle oder Artefakte durchsickern. Verwenden Sie dynamische Authentifizierung (AppRole, OIDC), damit das Token für jeden Lauf generiert wird und niemals besteht.
  • In Pipelines den Root Token verwenden: Der Root Token sollte nur für Initialisierung und Notfälle verwendet werden. Alle Pipelines müssen Scope-Token mit entsprechenden Richtlinien verwenden.
  • Keine kurzen TTLs setzen: Eine CI-Pipeline läuft normalerweise für Minuten, nicht Stunden.
  • Audit Logs ignorieren: Ohne Audit-Monitoring verpassen Sie Indikatoren für Kompromisse oder falsch konfigurierte Richtlinien.
  • Speichergeheimnisse in Pipeline-Ausgaben: Drucken Sie niemals Geheimnisse in Konsolen, Protokolldateien oder Artefakte. Verwenden Sie dateibasierte Injektion oder entfernen Sie das Geheimnis unmittelbar nach der Verwendung aus Umgebungsvariablen.
  • Vergessen, Leasingverträge zu widerrufen: Dynamische Geheimnisse bleiben gültig, bis der Leasingvertrag abläuft oder widerrufen wird.

Schlussfolgerung

Die Integration von HashiCorp Vault in Ihre CI/CD-Pipelines eliminiert die gefährlichste Quelle für geheime Lecks: fest codierte oder in der Umgebung gespeicherte statische Anmeldeinformationen. Durch die Einhaltung der hier beschriebenen Best Practices – dynamische Geheimnisse, feinkörnige Zugangskontrolle, Verschlüsselung, automatisierte Rotation und umfassende Auditierung – können Sie einen robusten, produktionsbereiten Geheimmanagement-Workflow erreichen.

Beginnen Sie klein: Nehmen Sie die AppRole-Authentifizierung für eine Pipeline an, holen Sie einen dynamischen Datenbanknachweis ab und überwachen Sie die Auditprotokolle. Erweitern Sie schrittweise alle Pipelines und geheimen Typen. Mit Vault gehen Sicherheit und Geschwindigkeit Hand in Hand, um sicherzustellen, dass Ihre CI / CD-Ausgaben sicher und zuverlässig sind.

Zusätzliche Ressourcen: