Vault vs SOPS vs age: Linux Guide 2026

Q: Was ist der Unterschied zwischen SOPS und HashiCorp Vault?

SOPS ist ein dateibasiertes Tool, das YAML-/JSON-Dateien verschlüsselt und im Git-Repository ablegt; es liefert keine dynamischen Credentials. Vault ist ein Server, der Secrets zur Laufzeit an authentifizierte Clients ausliefert und dynamische Credentials mit TTL erzeugen kann. In der Praxis kombiniert man beide: Vault für rotierende DB-/Cloud-Credentials, SOPS für deklarative Konfigurations-Secrets im GitOps-Workflow.

Q: Ist SOPS mit age sicher genug für Produktions-Secrets?

Ja, wenn die age-Identities auf Hardware-Token (YubiKey via PIV oder FIDO2) liegen und das Repository selbst mit signierten Commits geschützt ist. Kryptografisch nutzt age X25519 und ChaCha20-Poly1305, beides moderne, gut auditierte Primitive. Das Risiko liegt nicht im Krypto, sondern in der Schlüsselverwaltung: eine age-Identity in einer unverschlüsselten Datei auf einem Entwickler-Laptop ist der häufigste Kompromittierungsvektor.

Q: Ersetzt age GnuPG vollständig?

Für Datei-Verschlüsselung im DevOps-Kontext praktisch ja. age ist einfacher, schneller, hat keine Web-of-Trust-Altlasten und ein simples Format. Für E-Mail-Signaturen (OpenPGP) oder Debian-Repository-Signing bleibt GnuPG unverzichtbar, weil das dort etablierte Ökosystem ist. Neue Deployments für Secrets Management sollten age nutzen.

Q: Wie oft sollte man Secrets rotieren?

Dynamische Credentials (DB, Cloud IAM) sollten TTLs im Bereich Minuten bis Stunden haben; Vault erledigt das automatisch. Statische Service-Account-Passwörter maximal alle 90 Tage, TLS-Zertifikate 90 Tage via ACME, Signing-Keys ein bis drei Jahre. NIST SP 800-57 Part 1 Rev. 5 ist die maßgebliche Referenz. Rotation ohne funktionierenden Rollback-Plan ist gefährlicher als keine Rotation.

Q: Was passiert, wenn die Vault-Unseal-Keys verloren gehen?

Wenn weniger als das konfigurierte Threshold (typisch 3 von 5) erreichbar sind, kann der Vault-Cluster nach einem Neustart nicht mehr entsiegelt werden. Alle Secrets sind unwiederbringlich verloren, es sei denn, ein Auto-Unseal-Backend (Cloud KMS, HSM) ist konfiguriert. Deshalb: Unseal-Keys auf mindestens fünf physisch getrennte Hardware-Token verteilen, dokumentierter Wiederherstellungsprozess, jährlicher Recovery-Drill.

Aktualisiert: 30. August 2026

Secrets Management unter Linux bezeichnet die zentralisierte, verschlüsselte Verwaltung sensibler Zugangsdaten wie API-Tokens, Datenbank-Passwörter und TLS-Schlüssel. 2026 dominieren drei Werkzeuge das Feld: HashiCorp Vault als serverbasierter Broker mit dynamischen Credentials, SOPS für verschlüsselte YAML-/JSON-Dateien im Git-Repository und age als moderner, minimalistischer Nachfolger von GnuPG. Ehrlich gesagt hängt die Wahl weniger vom Feature-Vergleich ab als von der Frage, die ich bei jedem Architektur-Review stelle: Was bricht zuerst, wenn die Master-Identität kompromittiert wird? Dieser Leitfaden vergleicht Vault, SOPS und age auf Blast-Radius-Ebene und zeigt produktionsreife Konfigurationen.

Vault eignet sich für dynamische Credentials, kurze TTLs und rollenbasierte Zugriffe. Blast Radius: der Vault-Unseal-Key.
SOPS + age sind der GitOps-Standard 2026, wenn Secrets versioniert im Repository liegen sollen. Blast Radius: die age-Identity-Datei.
age ersetzt GnuPG in fast allen neuen Deployments: X25519, keine Web-of-Trust-Altlasten, ein 60-Zeichen-Public-Key.
In Kubernetes hat sich der External Secrets Operator gegen Sealed Secrets durchgesetzt: Secrets bleiben in Vault, ESO synchronisiert nur.
Rotation ohne Audit-Trail ist Sicherheitstheater. Jede Secret-Engine muss audit-Devices oder eine WORM-Sink haben.
NIST SP 800-57 verlangt für symmetrische Schlüssel eine Cryptoperiode von maximal zwei Jahren; für Service-Accounts sind 90 Tage praxistauglich.

Was ist Secrets Management unter Linux?

Secrets Management ist die Disziplin, Zugangsdaten so zu speichern, auszuliefern und zu rotieren, dass sie nur der berechtigte Prozess zum berechtigten Zeitpunkt sieht. Nichts davon soll in ~/.bash_history, docker inspect oder einem Git-Diff auftauchen. In der Praxis meint der Begriff ein System aus vier Bausteinen: einem Storage-Backend (verschlüsselt at-rest), einer Auth-Method (wer darf lesen), einer Secret-Engine (statisch, dynamisch oder Broker) und einem Audit-Device (unveränderliches Log).

Die meisten Linux-Teams starten mit Umgebungsvariablen in systemd-Units oder .env-Dateien. Das funktioniert, solange niemand Root-Zugriff bekommt und niemand versehentlich env in einem Support-Ticket postet. Sobald jedoch drei Bedingungen zutreffen (mehr als eine Umgebung, mehr als ein Admin, regulatorische Anforderungen wie DORA, NIS-2 oder EU Cyber Resilience Act), reicht das nicht mehr. Dann braucht es zentralisiertes Secrets Management mit rollenbasiertem Zugriff, Verschlüsselungs-Providern (KMS/HSM), Rotationsmechanismen und einem prüfbaren Zugriffsprotokoll. Genau hier setzen Vault, SOPS und age an, jedes mit sehr unterschiedlicher Architektur.

HashiCorp Vault, SOPS und age im direkten Vergleich

Die drei Werkzeuge lösen dasselbe Problem auf grundverschiedene Weise. Vault ist ein Server, der Secrets zur Laufzeit ausliefert. SOPS ist ein Tool, das Dateien verschlüsselt und wieder entschlüsselt. age ist die Bibliothek und CLI, mit der SOPS (und andere) verschlüsseln. Die folgende Tabelle fasst die entscheidenden Dimensionen zusammen, die in einer echten Architekturentscheidung wiegen.

Dimension	HashiCorp Vault 1.18	SOPS 3.9	age 1.2
Architektur	Client-Server, HA-Cluster	CLI, dateibasiert	CLI und Go-Library
Speicherort der Secrets	Verschlüsseltes Backend (Raft/Consul)	Git-Repository	Beliebige Datei
Dynamische Credentials	Ja (DB, Cloud, PKI, SSH)	Nein	Nein
Rotation	Automatisch mit TTL/Leases	Manuell + Re-Encrypt	Manuell
Auth-Methoden	OIDC, LDAP, AppRole, K8s, Cloud IAM	KMS-Backends	SSH-Keys, X25519
Betriebsaufwand	Hoch (Unseal, HA, Backup)	Niedrig	Sehr niedrig
GitOps-Freundlichkeit	Mittel (via ESO)	Sehr hoch	Sehr hoch
Lizenz	BUSL 1.1	MPL 2.0	BSD-3

Vereinfacht gesagt: Vault gewinnt, wenn du dynamische Datenbank-Credentials oder kurzlebige Cloud-Tokens brauchst. SOPS + age gewinnt, wenn deine Deployment-Wahrheit im Git liegt (ArgoCD, Flux, Helmfile) und du keinen weiteren Server betreiben willst. In der Praxis kombiniere ich beide: Vault als Quelle für Cloud- und DB-Secrets, SOPS für Konfigurationen, die deklarativ im Repo bleiben sollen. Für die Governance rund um solche kombinierten Architekturen leistet ein regelmäßiges CIS-Benchmark-Audit mit OpenSCAP und Ansible gute Dienste.

HashiCorp Vault 1.18 produktiv einrichten

Ich zeige eine minimale, produktionsnahe Vault-Installation mit dem integrierten Raft-Storage, also ohne externen Consul und ohne Cloud-KMS-Auto-Unseal. Für ein 3-Node-Cluster in einer Hyperscaler-Umgebung würde ich zusätzlich Auto-Unseal via AWS KMS oder Azure Key Vault empfehlen; die Konfiguration ist analog. Getestet mit Vault 1.18.2 auf Debian 13 und RHEL 10.

# /etc/vault.d/vault.hcl — Single-Node-Konfiguration
storage "raft" {
  path    = "/var/lib/vault/data"
  node_id = "node-1"
}

listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_cert_file = "/etc/vault.d/tls/server.crt"
  tls_key_file  = "/etc/vault.d/tls/server.key"
  tls_min_version = "tls13"
}

api_addr     = "https://vault.example.internal:8200"
cluster_addr = "https://vault.example.internal:8201"
ui           = true
disable_mlock = false
log_level    = "info"

Nach dem Start erfolgt genau ein Mal die Initialisierung. Die fünf entstehenden Unseal-Keys sind kryptographisch das Wertvollste im ganzen System. Sie werden auf fünf Hardware-Token verteilt und niemals gemeinsam gespeichert. Der Root-Token wird nach dem Setup der ersten Auth-Method sofort widerrufen.

# Vault initialisieren (3 von 5 Keys entsiegeln)
vault operator init -key-shares=5 -key-threshold=3

# Entsiegeln (dreimal mit unterschiedlichen Keys)
vault operator unseal <unseal_key_1>
vault operator unseal <unseal_key_2>
vault operator unseal <unseal_key_3>

# Dynamische PostgreSQL-Credentials einrichten
vault secrets enable database
vault write database/config/postgres-prod \
    plugin_name=postgresql-database-plugin \
    connection_url="postgresql://{{username}}:{{password}}@db.internal:5432/appdb?sslmode=require" \
    allowed_roles="app-readonly,app-readwrite" \
    username="vault-admin" password="$PG_ADMIN_PW"

vault write database/roles/app-readonly \
    db_name=postgres-prod \
    creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
    default_ttl="1h" max_ttl="24h"

Ab diesem Punkt bekommt jede Anwendung, die sich per AppRole oder OIDC gegen Vault authentifiziert, ein frisches DB-Passwort mit einer Stunde TTL. Wird ein Container kompromittiert, ist die Credential nach maximal 24 Stunden nutzlos, und der Blast Radius eines Leaks schrumpft von Wochen auf Stunden. Details zu Auth-Methoden und Policies stehen in der offiziellen Vault-Dokumentation.

SOPS und age für GitOps: Secrets im Repository verschlüsseln

SOPS (Secrets OPerationS) verschlüsselt einzelne Werte in YAML-, JSON- oder ENV-Dateien, während die Struktur lesbar bleibt. Das ist der entscheidende Punkt: git diff zeigt weiterhin, welcher Key sich geändert hat, nur der Wert selbst ist unlesbar. Kombiniert mit age als Verschlüsselungsprovider entfällt die komplette GnuPG-Keyring-Verwaltung. Ein age-Public-Key ist eine einzige 62-Zeichen-Zeile.

# age-Keypair erzeugen (einmal pro Entwickler und pro Umgebung)
age-keygen -o ~/.config/sops/age/keys.txt
# Ausgabe: public key: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p

# .sops.yaml im Repository-Root: Regeln für Verschlüsselung
cat > .sops.yaml <<'EOF'
creation_rules:
  - path_regex: secrets/prod/.*\.ya?ml$
    encrypted_regex: '^(password|token|apiKey|.*_KEY|.*_SECRET)$'
    age: >-
      age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p,
      age1u9zc8dyx7vh37xwn5pu0lhw83jltx36q39p3f9y2rwjkxcx3ftzqk5uhpw
  - path_regex: secrets/dev/.*\.ya?ml$
    age: age1qxnaxekrdkfmvjt5nz7lqrgqf5gnaqhk9xf7l5jn4ay5r4uvmedq77hjw2
EOF

# Datei verschlüsseln
sops -e -i secrets/prod/database.yaml

# Entschlüsseln zum Editieren (öffnet $EDITOR)
sops secrets/prod/database.yaml

Nach dem Verschlüsseln enthält die Datei einen sops:-Metadatenblock mit dem verschlüsselten Data-Key und den Empfänger-Public-Keys. Jede age-Identity im .sops.yaml kann die Datei entschlüsseln, ohne dass jemand einen gemeinsamen Master-Key kennen muss. Für CI/CD wird eine dedizierte age-Identity generiert und als Secret im Build-Runner hinterlegt. Weitere Details zu age (Threat Model, Format-Spezifikation) finden sich unter age-encryption.org.

Kubernetes: External Secrets Operator statt Sealed Secrets

In Kubernetes ist die Debatte zwischen Sealed Secrets und External Secrets Operator (ESO) 2026 weitgehend entschieden: ESO hat sich als Standard etabliert. Sealed Secrets speichert verschlüsselte Secrets im Cluster (via Bitnami-Controller), was für kleine Setups pragmatisch ist. ESO dagegen lässt die Secrets in Vault, AWS Secrets Manager oder GCP Secret Manager liegen und synchronisiert sie nur als natives Kubernetes-Secret-Objekt in den Namespace, mit Rotation, und ohne dass jemand die verschlüsselten Blobs im Git verwalten muss.

# ExternalSecret-Manifest: DB-Credentials aus Vault ziehen
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: app-db-credentials
  namespace: production
spec:
  refreshInterval: 15m
  secretStoreRef:
    name: vault-prod
    kind: SecretStore
  target:
    name: app-db-secret
    creationPolicy: Owner
  data:
    - secretKey: username
      remoteRef:
        key: database/creds/app-readwrite
        property: username
    - secretKey: password
      remoteRef:
        key: database/creds/app-readwrite
        property: password

ESO ruft alle 15 Minuten Vault ab und aktualisiert das Kubernetes-Secret. Kombiniert mit Vaults dynamischer Datenbank-Engine bekommt jeder Pod ein rotierendes Passwort, ohne dass ein Entwickler jemals einen echten Credential-Wert sieht. Der Blast Radius bei einem kompromittierten Cluster ist auf die aktuelle TTL beschränkt. Sealed Secrets bleibt sinnvoll, wenn du zwingend ohne externen Secret-Store auskommen musst, etwa in Air-Gapped-Umgebungen. Für ergänzende Härtung der Container-Ebene siehe unseren Praxisleitfaden zu Container-Sicherheit unter Linux mit Docker und Podman.

Secret Rotation, Leasing und Audit-Trail

Rotation ohne Audit-Trail ist Sicherheitstheater. Ein rotierendes Secret ist nur wertvoll, wenn im Nachhinein nachweisbar ist, wer wann welches Secret abgerufen hat. Vault löst das mit Audit Devices, die jeden API-Request in ein append-only Log schreiben, wahlweise als File, Syslog oder Socket. Für Compliance-Anforderungen aus NIS-2 oder DORA reicht ein reines File-Device selten; ich empfehle Syslog mit einer WORM-Sink (z. B. AWS S3 Object Lock oder Azure Blob Immutability Policies).

# Audit-Device File aktivieren
vault audit enable file file_path=/var/log/vault/audit.log

# Zusätzlich Syslog für zentrales SIEM
vault audit enable syslog tag="vault" facility="AUTH"

# Auditlog inspizieren: Wer hat in den letzten 24h auf welches Secret zugegriffen?
jq -r 'select(.type=="response" and (.request.path | startswith("database/creds"))) |
  [.time, .auth.display_name, .request.path] | @tsv' /var/log/vault/audit.log

Cryptoperioden folgen NIST SP 800-57 Part 1 Rev. 5: symmetrische Data-Keys maximal 2 Jahre, asymmetrische Signing-Keys 1 bis 3 Jahre, ephemere Service-Credentials in Stunden bis Tagen. In der Praxis: DB-Credentials 1h TTL, Cloud-IAM-Tokens 15 Minuten, TLS-Zertifikate 90 Tage via ACME/Vault-PKI, GPG/SSH-Signing-Keys ein Jahr. Für den SSH-spezifischen Teil siehe unseren Deep-Dive zur SSH-Härtung 2026 mit Post-Quanten-Kryptografie und FIDO2.

Secrets in CI/CD-Pipelines und DevSecOps

CI/CD ist der häufigste Angriffsvektor für Secret-Leaks — nicht, weil Pipelines schlecht gebaut wären, sondern weil sie standardmäßig alles loggen. Ein echo $API_TOKEN im falschen Debug-Kontext, ein set -x in einem Bash-Script, und der Token liegt für alle Repo-Kollaboratoren im Job-Log. In meinem letzten Kunden-Projekt hatten wir genau diesen Fall: ein einziger schlecht platzierter Debug-Print, drei Wochen unbemerkt im Log. Vier Regeln, die ich seither in jedem DevSecOps-Review durchsetze:

Keine Long-Lived-Tokens in CI-Variablen. GitHub Actions und GitLab CI unterstützen OIDC-basierte Föderation mit AWS, GCP, Azure und Vault. Der Runner tauscht ein kurzlebiges JWT gegen ein 15-Minuten-Cloud-Token, kein statischer AWS_ACCESS_KEY_ID mehr.
Secret-Scanning verpflichtend. Tools wie gitleaks, trufflehog oder GitHub Advanced Security laufen als Pre-Commit-Hook und im Pipeline-Gate. Ein Commit mit einem AWS-Key wird geblockt, bevor er im Repo landet.
Masking und Log-Filter aktivieren. GitLab maskiert Secrets automatisch, wenn sie als "masked" markiert sind. Bei GitHub Actions passiert das nur für Werte, die als Secret registriert wurden. Werte, die zur Laufzeit über einen Vault-Call geholt werden, müssen explizit mit ::add-mask:: maskiert werden.
Ephemere Runner. Selbst mit perfekter Isolation ist ein persistenter Runner ein Ziel. Kubernetes-Runner mit einer Pod-Lifetime von einem Job schließen die häufigste Persistenz-Lücke.

Passend zur Runner-Härtung ist auch unser Artikel zur eBPF-Runtime-Security mit Tetragon und Falco, der die Detection-Seite abdeckt, falls doch einmal etwas durchrutscht.

Threat-Modelling: Was bricht zuerst?

Jede Secrets-Management-Architektur hat einen kritischsten Punkt, und die Frage ist nur, ob das Team ihn kennt. Ich gehe in jedem Review dieselben vier Szenarien durch. Das Ergebnis ist keine Rangliste, sondern eine Priorisierungshilfe: welchen Kontrolltyp braucht welches Szenario?

Szenario 1: Der Entwickler-Laptop wird gestohlen

Bei SOPS + age liegt die age-Identity im Home-Directory. Ohne Full-Disk-Encryption (LUKS) sind alle Prod-Secrets kompromittiert. Mitigation: age-Identity ausschließlich auf YubiKey (PIV-Applet) oder FIDO2, plus LUKS mit TPM+PIN. Bei Vault: kein Impact, solange der Vault-Token kurzlebig war.

Szenario 2: Ein Backup-Server wird kompromittiert

Vault-Raft-Snapshots enthalten alle Secrets, verschlüsselt mit dem Vault-Master-Key. Wer den Snapshot und genügend Unseal-Keys hat, entschlüsselt alles. Mitigation: Snapshots mit einem separaten age-Key nochmals verschlüsseln, Unseal-Keys in HSMs statt auf Papier.

Szenario 3: Ein CI-Runner wird übernommen

Statische Cloud-Credentials im Runner sind das Worst-Case-Szenario. Der Angreifer bekommt Prod-Access. Mitigation: OIDC-Föderation, 15-Minuten-Tokens, IP-Restrictions. Bei ephemeren Runnern ist das Fenster minimal.

Szenario 4: Das Vault-Root-Zertifikat läuft ab

Der klassische Self-Inflicted-Outage. Alle Clients verlieren gleichzeitig die Verbindung, keine Secrets mehr abrufbar. Mitigation: Zertifikats-Monitoring mit Warnung bei < 30 Tagen Restlaufzeit, automatische Rotation via ACME oder Vault-PKI selbst. Ich hab genau diesen Ausfall vor zwei Jahren produktiv erlebt, das Monitoring war da, aber der Alert ging nur an ein Postfach, das keiner mehr las. Seither: mindestens zwei unabhängige Kanäle.

Häufig gestellte Fragen

Was ist der Unterschied zwischen SOPS und HashiCorp Vault?