Secrets Management — HashiCorp Vault, SOPS und sichere Secrets

Jede moderne Anwendung arbeitet mit Geheimnissen — Datenbankzugangsdaten, API-Schlüssel, TLS-Zertifikate, Verschlüsselungsschlüssel, Drittanbieter-Tokens. Dennoch begegnen wir immer noch Unternehmen, die Passwörter hart im Code haben, .env-Dateien in Git committen oder über Slack teilen. Im Jahr 2026 ist das der schnellste Weg zu einem Sicherheitsvorfall.

Secrets Management ist nicht nur die Frage „wohin mit dem Passwort”. Es ist eine komplexe Disziplin, die sichere Speicherung, Verteilung, Rotation, Audit und Widerruf von Geheimnissen über den gesamten Anwendungslebenszyklus umfasst.

Warum Secrets Management kritisch ist¶

Geheimnisleck = offene Türen¶

Laut einer GitGuardian-Studie erschienen 2025 über 12 Millionen neue Geheimnisse in öffentlichen Repositories auf GitHub. AWS-API-Schlüssel, Datenbankpasswörter, private Schlüssel — alles frei zugänglich für jeden.

Konsequenzen eines Geheimnislecks: - Finanzielle Verluste — Angreifer mit AWS-Schlüsseln können innerhalb von Stunden Zehntausende Dollar in Kryptowährungen schürfen - Datenschutzverletzung — Datenbankzugangsdaten führen direkt zu Kundendaten - Compliance-Verstöße — DSGVO, NIS2, DORA verlangen den Schutz von Zugangsdaten - Reputationsschaden — öffentliche Geheimnislecks signalisieren die Reife der Sicherheitskultur

Architektur des Secrets Management¶

Grundprinzipien¶

Zentralisierte Speicherung — Geheimnisse leben an einem Ort, nicht über Konfigurationen, CI/CD-Variablen und Confluence-Notizen verstreut.

Verschlüsselung at rest und in transit — Geheimnisse sind immer verschlüsselt, nicht nur während der Übertragung.

Least-Privilege-Zugriff — jeder Service, Benutzer oder Pipeline hat nur Zugriff auf die Geheimnisse, die tatsächlich benötigt werden.

Automatische Rotation — Schlüssel und Passwörter ändern sich regelmäßig ohne manuelle Eingriffe.

Audit Trail — jeder Zugriff auf Geheimnisse wird protokolliert — wer, wann, woher.

Widerruf — Möglichkeit, kompromittierte Geheimnisse sofort ungültig zu machen.

Dynamische Geheimnisse — statt statischer Passwörter temporäre Zugangsdaten mit begrenzter Gültigkeit generieren.

HashiCorp Vault — der De-facto-Standard¶

HashiCorp Vault ist die am weitesten verbreitete Open-Source-Lösung für Secrets Management. Und das aus guten Gründen.

Was Vault kann¶

Secret Engines — pluggable Backends für verschiedene Arten von Geheimnissen: - kv (Key-Value) — klassische Geheimnisspeicherung - database — dynamische Generierung von Datenbankzugangsdaten - pki — eigene Certificate Authority für TLS-Zertifikate - aws / azure / gcp — dynamische Cloud-Zugangsdaten - transit — Encryption as a Service (Verschlüsselung ohne Offenlegung des Schlüssels) - ssh — signierte SSH-Zertifikate statt statischer Schlüssel

Auth Methods — wie sich Anwendungen und Benutzer bei Vault authentifizieren: - Kubernetes Service Account - OIDC / JWT - AppRole (für CI/CD) - Cloud IAM (AWS, Azure, GCP) - LDAP / Active Directory - TLS-Zertifikate

Policies — granulare Zugriffskontrolle:

# Secrets Management in der Praxis — HashiCorp Vault, SOPS und sichere Geheimnisverwaltung
path "secret/data/payments/*" {
  capabilities = ["read"]
}

path "database/creds/payments-readonly" {
  capabilities = ["read"]
}

# Zugriff auf Admin-Geheimnisse verweigern
path "secret/data/admin/*" {
  capabilities = ["deny"]
}

Vault in Kubernetes — praktische Implementierung¶

In Kubernetes-Umgebungen wird Vault typischerweise als StatefulSet mit Raft-Storage-Backend (integrierter Konsens) bereitgestellt:

# Vault Helm Values
server:
  ha:
    enabled: true
    replicas: 3
    raft:
      enabled: true
      setNodeId: true

  resources:
    requests:
      memory: 256Mi
      cpu: 250m
    limits:
      memory: 512Mi
      cpu: 500m

  auditStorage:
    enabled: true
    size: 10Gi

  # Auto-Unseal über Azure Key Vault
  seal:
    azurekeyvault:
      tenant_id: "xxx"
      vault_name: "core-vault-unseal"
      key_name: "vault-auto-unseal"

injector:
  enabled: true
  resources:
    requests:
      memory: 64Mi
      cpu: 50m

Vault Agent Injector¶

Der eleganteste Weg, Geheimnisse in Pods in Kubernetes zu bringen, ist der Vault Agent Injector. Er funktioniert als Mutating Webhook — fügt automatisch Init-Container und Sidecar hinzu, die Geheimnisse in eine Datei im Pod ziehen:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
spec:
  template:
    metadata:
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "payment-service"
        vault.hashicorp.com/agent-inject-secret-db: "database/creds/payments-rw"
        vault.hashicorp.com/agent-inject-template-db: |
          {{- with secret "database/creds/payments-rw" -}}
          postgresql://{{ .Data.username }}:{{ .Data.password }}@db.core.internal:5432/payments
          {{- end }}
    spec:
      serviceAccountName: payment-service
      containers:
        - name: app
          image: core/payment-service:latest
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: vault-db
                  key: connection_string

Das Schöne an diesem Ansatz: Die Anwendung weiß nichts von Vault. Sie liest Geheimnisse aus Dateien oder Umgebungsvariablen — der Vault Agent übernimmt Authentifizierung, Abruf und automatische Aktualisierung bei Rotation.

Dynamische Geheimnisse — Game Changer¶

Statische Passwörter sind wie Wohnungsschlüssel: Sobald jemand sie kopiert, hat er für immer Zugang. Dynamische Geheimnisse eliminieren dieses Problem.

Vault kann Datenbankzugangsdaten on-the-fly mit begrenzter Gültigkeit generieren:

# Datenbank-Secret-Engine konfigurieren
vault write database/config/payments \
  plugin_name=postgresql-database-plugin \
  connection_url="postgresql://{{username}}:{{password}}@db:5432/payments" \
  allowed_roles="payments-rw,payments-ro" \
  username="vault-admin" \
  password="super-secret-admin-password"

# Rolle mit 1-Stunden-TTL definieren
vault write database/roles/payments-rw \
  db_name=payments \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT ALL ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  revocation_statements="REVOKE ALL ON ALL TABLES IN SCHEMA public FROM \"{{name}}\"; DROP ROLE IF EXISTS \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="24h"

Jede Anfrage an database/creds/payments-rw generiert einen einzigartigen Benutzernamen und ein Passwort, gültig für 1 Stunde. Nach Ablauf widerruft Vault die Zugangsdaten automatisch. Bei einem Leck sind die Zugangsdaten maximal eine Stunde gültig — eine dramatische Reduzierung des Blast Radius.

Mozilla SOPS — Verschlüsselung für GitOps¶

Nicht jede Organisation braucht (oder will) einen vollen Vault-Cluster betreiben. Für kleinere Teams oder als Ergänzung zu Vault gibt es Mozilla SOPS (Secrets OPerationS).

Wie SOPS funktioniert¶

SOPS verschlüsselt Werte in YAML-, JSON- oder ENV-Dateien, während Schlüssel lesbar bleiben. Dies ermöglicht das Committen verschlüsselter Geheimnisse direkt in Git bei gleichzeitiger Sichtbarkeit der Konfigurationsstruktur:

# Vor der Verschlüsselung
database:
  host: db.production.internal
  port: 5432
  username: app_user
  password: SuperSecretPassword123

# Nach SOPS-Verschlüsselung
database:
  host: db.production.internal  # unverschlüsselt — kein Geheimnis
  port: 5432
  username: ENC[AES256_GCM,data:kBqPdA==,iv:...,tag:...]
  password: ENC[AES256_GCM,data:1xMfNZK3nQ==,iv:...,tag:...]
sops:
  kms:
    - arn: arn:aws:kms:eu-central-1:123456:key/abc-def
  azure_kv:
    - vaultUrl: https://core-sops.vault.azure.net
      key: sops-key
      version: abc123
  lastmodified: "2026-02-16T10:30:00Z"
  mac: ENC[AES256_GCM,data:...,tag:...]

SOPS in der Praxis¶

# Mit Azure Key Vault initialisieren
export SOPS_AZURE_KEYVAULT_URLS="https://core-sops.vault.azure.net/keys/sops-key/abc123"

# Datei verschlüsseln
sops --encrypt --azure-kv https://core-sops.vault.azure.net/keys/sops-key/abc123 \
  secrets.yaml > secrets.enc.yaml

# Bearbeiten (entschlüsselt, öffnet Editor, verschlüsselt erneut)
sops secrets.enc.yaml

# Für Deployment entschlüsseln
sops --decrypt secrets.enc.yaml | kubectl apply -f -

SOPS + Flux/ArgoCD¶

Für GitOps-Workflows ist SOPS ideal. Sowohl Argo CD als auch Flux haben native Unterstützung:

# Flux Kustomization mit SOPS-Entschlüsselung
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: production-secrets
spec:
  interval: 10m
  path: ./clusters/production/secrets
  prune: true
  sourceRef:
    kind: GitRepository
    name: infrastructure
  decryption:
    provider: sops
    secretRef:
      name: sops-azure-credentials

External Secrets Operator — Brücke zwischen Welten¶

External Secrets Operator (ESO) löst ein häufiges Problem: Anwendungen in Kubernetes erwarten klassische Secret-Objekte, aber Geheimnisse leben in Vault, AWS Secrets Manager oder Azure Key Vault. ESO erstellt und synchronisiert Kubernetes Secrets aus externen Quellen.

# Definition der externen Quelle (ClusterSecretStore)
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: azure-keyvault
spec:
  provider:
    azurekv:
      tenantId: "xxx"
      vaultUrl: "https://core-production.vault.azure.net"
      authSecretRef:
        clientId:
          name: azure-credentials
          namespace: external-secrets
          key: client-id
        clientSecret:
          name: azure-credentials
          namespace: external-secrets
          key: client-secret

---
# Geheimnissynchronisierung
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: payment-db-credentials
  namespace: payments
spec:
  refreshInterval: 5m
  secretStoreRef:
    kind: ClusterSecretStore
    name: azure-keyvault
  target:
    name: payment-db-credentials
    creationPolicy: Owner
  data:
    - secretKey: username
      remoteRef:
        key: payments-db-username
    - secretKey: password
      remoteRef:
        key: payments-db-password

ESO prüft regelmäßig die externe Quelle und aktualisiert das Kubernetes Secret. Wenn sich ein Passwort in Azure Key Vault ändert, propagiert ESO es innerhalb von 5 Minuten in den Cluster.

Secrets in CI/CD-Pipelines¶

CI/CD-Pipelines sind kritische Punkte — sie brauchen Zugriff auf Geheimnisse für das Deployment, sind aber gleichzeitig Hochrisiko-Umgebungen (Shared Runners, Logs, Artefakte).

CI/CD-Prinzipien¶

1. Niemals Geheimnisse loggen — Maskierung in Logs reicht nicht, besser Geheimnisse gar nicht als Variablen exponieren
2. Kurzlebige Tokens — Vault AppRole mit 15-Minuten-TTL für Pipelines
3. Isolation pro Umgebung — Staging-Pipeline hat keinen Zugriff auf Produktionsgeheimnisse
4. OIDC-Föderierung — GitHub Actions und GitLab CI unterstützen OIDC-Tokens, die gegen Vault-/Cloud-Zugangsdaten ohne statische Secrets getauscht werden können

# GitHub Actions — OIDC-Authentifizierung mit Vault
jobs:
  deploy:
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Geheimnisse aus Vault importieren
        uses: hashicorp/vault-action@v3
        with:
          url: https://vault.core.internal
          method: jwt
          role: github-deploy
          jwtGithubAudience: https://vault.core.internal
          secrets: |
            secret/data/production/db password | DB_PASSWORD ;
            secret/data/production/api key | API_KEY

      - name: Deploy
        run: |
          helm upgrade --install app ./chart \
            --set db.password=${{ steps.vault.outputs.DB_PASSWORD }}

Pre-commit Hooks gegen Lecks¶

Prävention ist besser als Erkennung. Tools wie gitleaks, trufflehog oder detect-secrets scannen Commits vor dem Push:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

# Oder eigenständig
gitleaks detect --source . --verbose

In CI/CD-Pipelines laufen sie als Gates:

# GitLab CI
secret-scan:
  stage: security
  image: ghcr.io/gitleaks/gitleaks:latest
  script:
    - gitleaks detect --source . --report-format sarif --report-path gitleaks.sarif
  artifacts:
    reports:
      sast: gitleaks.sarif

Geheimnis-Rotation — Automatisierung ist der Schlüssel¶

Manuelle Passwort-Rotation ist zum Scheitern verurteilt. Entweder wird sie gar nicht durchgeführt oder sie verursacht Ausfälle durch veraltete Konfigurationen.

Rotationsstrategien¶

Vault Dynamic Secrets — am elegantesten. Geheimnisse werden nicht vorab generiert, sondern on-demand mit begrenzter Gültigkeit. Rotation ist implizit.

Vault Rotation Policy — für statische Geheimnisse (API-Schlüssel von Drittanbietern), bei denen Vault regelmäßig den Rotations-Endpoint aufruft:

# Automatische Rotation alle 30 Tage
vault write sys/policies/password/rotation \
  policy='length=32 rule "charset" { charset = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*" }'

Blue-Green-Rotation — für Geheimnisse, die nicht atomar rotiert werden können: 1. Neues Geheimnis erstellen (Green) 2. Alle Verbraucher aktualisieren 3. Überprüfen, ob das alte Geheimnis (Blue) nicht mehr verwendet wird 4. Altes Geheimnis widerrufen

Monitoring und Alerting¶

# Prometheus-Alert für ablaufende Geheimnisse
groups:
  - name: secrets
    rules:
      - alert: SecretExpiringIn7Days
        expr: vault_secret_lease_remaining_seconds < 604800
        for: 1h
        labels:
          severity: warning
        annotations:
          summary: "Geheimnis {{ $labels.path }} läuft in weniger als 7 Tagen ab"

      - alert: SecretRotationFailed
        expr: vault_secret_rotation_failures_total > 0
        for: 5m
        labels:
          severity: critical

Cloud-native Alternativen¶

Vault ist nicht immer die richtige Wahl. Wenn Sie komplett auf einer Cloud sind, können native Services einfacher sein:

Azure Key Vault¶

// .NET-Anwendung mit Azure Key Vault
var client = new SecretClient(
    new Uri("https://core-production.vault.azure.net"),
    new DefaultAzureCredential()
);

KeyVaultSecret secret = await client.GetSecretAsync("database-password");
string connectionString = $"Server=db.core.internal;Password={secret.Value}";

Vorteile: native Azure-AD-Integration, Managed Identity (keine Zugangsdaten für den Zugriff auf Zugangsdaten), automatische Rotation über Event Grid + Azure Functions.

AWS Secrets Manager¶

import boto3

client = boto3.client('secretsmanager', region_name='eu-central-1')
response = client.get_secret_value(SecretId='production/database')
secret = json.loads(response['SecretString'])

AWS bietet integrierte Rotation für RDS, Redshift und DocumentDB — einfach aktivieren und Intervall festlegen.

Vergleich¶

Eigenschaft	Vault	Azure KV	AWS SM	GCP SM
Multi-Cloud	✅	❌	❌	❌
Dynamische Geheimnisse	✅	❌	❌	❌
PKI/CA	✅	❌	❌	❌
Encryption as Service	✅	✅	✅	✅
Automatische Rotation	✅	✅	✅	✅
Betriebskosten	Hoch	Niedrig	Niedrig	Niedrig
Vendor Lock-in	Nein	Ja	Ja	Ja
Open-Source	Ja	Nein	Nein	Nein

Unsere Empfehlung: Vault für Multi-Cloud und komplexe Umgebungen, Cloud-native Lösungen für Single-Cloud mit einfachen Anforderungen.

Implementierungs-Checkliste¶

Wenn Sie mit Secrets Management beginnen, folgen Sie diesem Plan:

Phase 1 — Audit (Wochen 1–2)¶

• [ ] Inventarisierung aller Geheimnisse (Code, CI/CD, Konfiguration, Dokumentation)
• [ ] Klassifizierung nach Sensitivität (kritisch, hoch, mittel, niedrig)
• [ ] Geheimnis-Eigentümer identifizieren
• [ ] Repositories mit gitleaks/trufflehog scannen

Phase 2 — Zentralisierung (Wochen 3–4)¶

• [ ] Vault bereitstellen / Cloud-native Lösung konfigurieren
• [ ] Kritische Geheimnisse zuerst migrieren
• [ ] Zugriffsrichtlinien einrichten (Least Privilege)
• [ ] Audit-Logs aktivieren

Phase 3 — Automatisierung (Wochen 5–8)¶

• [ ] CI/CD-Integration (OIDC, AppRole)
• [ ] Kubernetes-Integration (ESO oder Vault Injector)
• [ ] Automatische Rotation für Datenbankzugangsdaten
• [ ] Pre-commit Hooks gegen Lecks

Phase 4 — Monitoring (fortlaufend)¶

• [ ] Alerting bei ablaufenden Geheimnissen
• [ ] Regelmäßige Zugriffsaudits
• [ ] Penetrationstests des Secrets Management
• [ ] Vierteljährliche Überprüfung der Zugriffsrichtlinien

Fazit¶

Secrets Management ist kein sexy Thema — bis es eines wird. Ein API-Schlüssel-Leck, ein Datenbankpasswort oder ein privates Zertifikat können fatale Folgen haben. Die Investition in die richtige Lösung zahlt sich vielfach zurück.

Wichtige Erkenntnisse: - Zentralisieren — ein Ort für alle Geheimnisse - Rotation automatisieren — manuelle Rotation funktioniert nicht - Dynamische Geheimnisse verwenden wo möglich — eliminiert das Leck-Problem - Code scannen — Pre-commit Hooks fangen Fehler ab, bevor sie in Git landen - Auditieren — jeden Zugriff loggen, Alerting einrichten

Bei CORE SYSTEMS implementieren wir Secrets Management als Teil jedes Projekts. Sicherheit ist kein Add-on — es ist das Fundament. Wenn Sie die Verwaltung von Geheimnissen in Ihrer Organisation angehen, kontaktieren Sie uns — wir helfen gerne bei Architektur und Implementierung.

---

Brauchen Sie Hilfe mit Secrets Management oder der gesamten Sicherheitsarchitektur? Schauen Sie sich unsere Security-Services an oder kontaktieren Sie uns direkt.

Unsere Erfahrung: Secrets Management für einen Bankenkunden¶

Für einen Kunden aus dem Bankensektor haben wir eine vollständige Secrets-Management-Lösung implementiert. Konkrete Ergebnisse:

• HashiCorp Vault + dynamische DB-Credentials + automatische Rotation — End-to-End-Lösung für Secrets Management
• 100 % der Secrets automatisch rotiert — kein manueller Eingriff, einschließlich Datenbankzugänge und API-Schlüssel
• Credential Exposure Window von 90 Tagen auf 1 Stunde — dynamische Credentials mit TTL und automatischem Revoke
• SOC-2-Audit beim ersten Mal bestanden — vollständiger Audit Trail und Policy Enforcement
• Null Secrets im Code — Pre-commit Hooks und CI-Scanning eliminierten den Abfluss von Geheimnissen ins Repository