OMNI52
Vault Cheatsheet OMNI52™ GmbH
Neu in Vault 2.12.0 bekommt keine Fixes mehr · Agentic IAM ist GA (Enterprise) · PKI liefert PKCS#12 und JKSAlle Neuerungen →

Vault
auf einem Blatt.

Dichte Referenz für Senior Platform Engineers und SREs zu HashiCorp Vault, dem Secrets-Management für regulierte Umgebungen. Seal/Unseal, Raft-HA, Secrets Engines (KV v2, Database, PKI, Transit), Auth-Methoden, Policies, Token-Lifecycle, Kubernetes-Integration, Audit Devices, Versionen und Upgrade auf 2.x, Health-Checks und Anti-Patterns. Keine Einsteiger-Folien.

Vorschau (2 Seiten A4 quer + Brand-Rückseite)

Vault Cheatsheet Seite 1: Seal/Unseal, Raft, Secrets Engines, Auth-Methoden, Policies, Token-Lifecycle, K8s-Integration (Agent Injector)
Vault Cheatsheet Seite 2: K8s-Integration (CSI, VSO), Audit, Versionen & Support, Upgrade auf 2.x, Health-Checks, Anti-Patterns

PDF herunterladen

Direkter Download, keine Mail-Adresse nötig. CC BY-SA 4.0: Kopieren, Drucken und Weiterverteilen sind ausdrücklich erlaubt, solange die Quellenangabe sichtbar bleibt.

Vault Cheatsheet (PDF, ~100 KB)

Was drin steht

Seal & HA

Unseal-Key-Kette, Shamir (5 Shares / Threshold 3) vs. Auto-Unseal mit Recovery Keys, Integrated Storage (Raft): Quorum, retry_join, Snapshots.

Secrets Engines

KV v2 mit Versionierung (undelete/destroy, data/-Prefix), dynamische DB-Credentials mit Lease, PKI mit kurzen TTLs, Transit als Encryption as a Service.

Auth-Methoden

kubernetes (TokenReview), AppRole (RoleID/SecretID, Response Wrapping), OIDC/JWT (bound_audiences, bound_claims) für Menschen und Workloads.

Policies & Tokens

HCL, deny by default, Capabilities inkl. sudo/deny/subscribe/recover, Globs * und +. Service- vs. Batch-Tokens, TTL/Renewal, periodic, Orphans.

K8s-Integration

Agent Injector (Annotations, /vault/secrets), Vault CSI Provider (SecretProviderClass), Vault Secrets Operator (CRDs, Sync in K8s-Secrets).

Audit & Anti-Patterns

file/syslog/socket, HMAC-SHA256, Blocking-Verhalten, zwei Devices, nicht auditierte Endpunkte. Root-Token im Alltag, KV als Konfig-Store, KV-v2-Policy-Falle.

Versionen & Upgrade

Schema V.M.F ohne Backport über Minor-Grenzen, Enterprise nach IBM Support Cycle-2, 1.19 als letzte LTS. Stolpersteine beim Upgrade auf 2.x, Health-Codes für den Load Balancer.

Cheatsheet im Volltext

Derselbe Inhalt wie im PDF, zum Mitlesen, Durchsuchen und direkten Kopieren der Snippets. Stand: Vault v2.1 (Edition 2026.10).

Architektur: Seal & Unseal

Seal / Unseal

Vault startet sealed: Die Daten sind mit einem Encryption Key (Keyring) verschlüsselt, der Keyring mit dem Root Key, der Root Key mit dem Unseal Key. Erst nach dem Unseal kann Vault Requests bedienen.

vault operator init teilt den Unseal Key per Shamir's Secret Sharing in Shares auf, Default 5 Shares, Threshold 3. Shares einzeln, in beliebiger Reihenfolge eingeben.

Shamir vs. Auto-Unseal

Shamir (Default): Menschen halten Key-Shares, jeder Neustart braucht das Quorum, operativ teuer, HA-feindlich.

Auto-Unseal: delegiert den Unseal Key an einen vertrauten Dienst (Cloud-KMS, HSM oder Transit-Engine eines zweiten Vault). Vault entsiegelt sich beim Start selbst; für Quorum-Operationen (z.B. generate-root) treten Recovery Keys an die Stelle der Unseal Keys.

Integrated Storage (Raft)

Eingebauter HA-Datastore: repliziert per Raft-Konsens auf alle Server, kein externes Backend nötig. Quorum = Mehrheit der Voting-Nodes, deshalb ungerade Server-Zahl (3 oder 5).

Join über retry_join-Stanza in der Config oder vault operator raft join, Nodes einzeln joinen und Health abwarten. disable_mlock ist mit Raft Pflichtfeld (seit 1.20), fehlt es, startet der Server nicht.

vault operator init     # 5 Shares, Threshold 3
vault operator unseal   # 3x, je ein Share
vault status
vault operator raft list-peers
vault operator raft snapshot save backup.snap

Secrets Engines

KV v2: versionierte Secrets

Jeder Key trägt Versionen (max_versions pro Mount/Key). Soft Delete macht eine Version unzugänglich, aber wiederherstellbar (undelete); destroy löscht Versionsdaten endgültig. cas (Check-and-Set) verhindert Lost Updates.

API-Pfade je Mount: data/, metadata/, delete/, destroy/, wichtig für Policies!

vault secrets enable -path=secret kv-v2
vault kv put    -mount=secret app/db user=svc pass=s3
vault kv get    -mount=secret -version=2 app/db
vault kv patch  -mount=secret app/db pass=neu
vault kv undelete -mount=secret -versions=2 app/db
vault kv destroy  -mount=secret -versions=1 app/db

Database: dynamische Credentials

Vault erzeugt DB-Accounts on demand: Jede App-Instanz bekommt eigene, kurzlebige Credentials mit Lease/TTL; nach Ablauf revoked Vault den Account. Role mappt auf creation_statements mit {{username}}/{{password}}-Platzhaltern.

Static Roles rotieren bestehende Accounts nach Zeitplan. Nach dem Setup rotate-root: das Bootstrap-Passwort kennt danach nur noch Vault.

vault read database/creds/readonly  # user+pass+lease
vault write -force database/rotate-root/pg

PKI: Zertifikate on demand

X.509-Zertifikate ohne manuellen CSR-Prozess, pro Workload-Instanz ein eigenes, kurzlebiges Zertifikat. Kurze TTLs statt Revocation: hält CRLs klein.

Aufbau: Root-CA und Intermediate-CA getrennt aufsetzen, Issuance läuft über die Intermediate. Roles begrenzen allowed_domains. ACME wird als Protokoll unterstützt; ab 2.1 liefert die PKI-Engine mit format=pkcs12_bundle bzw. jks_bundle base64-kodierte Bundles, Default-Passwort changeit, also pkcs12_password/jks_password setzen.

Transit: Encryption as a Service

Ver-/Entschlüsselung als API, Vault speichert die Daten nicht. Ciphertext trägt die Key-Version als Prefix (vault:v1:...).

rotate erzeugt eine neue Key-Version, rewrap hebt Ciphertext ohne Plaintext-Zugriff auf die neue Version, min_decryption_version sperrt Alt-Versionen. Dazu: sign/verify, HMAC, Datakeys für Envelope Encryption.

vault write transit/encrypt/app \
  plaintext=$(printf %s geheim | base64)
vault write -f transit/keys/app/rotate
vault write transit/rewrap/app ciphertext=vault:v1:...

Auth-Methoden

kubernetes

Pod authentisiert sich mit seinem ServiceAccount-JWT; Vault validiert es gegen die TokenReview-API des Clusters. Config: kubernetes_host. Vault im Pod: token_reviewer_jwt und CA weglassen, Vault liest das lokale SA-Token periodisch neu. Vault extern: ohne token_reviewer_jwt dient das Client-JWT als Reviewer (Clients brauchen system:auth-delegator), CA per kubernetes_ca_cert. Die Role bindet bound_service_account_names + ..._namespaces an Policies.

vault auth enable kubernetes
vault write auth/kubernetes/config \
  kubernetes_host=https://10.0.0.1:443 \
  kubernetes_ca_cert=@ca.crt
vault write auth/kubernetes/role/app \
  bound_service_account_names=myapp \
  bound_service_account_namespaces=prod \
  token_policies=app-ro token_ttl=1h

AppRole

Für Maschinen/CI: RoleID (quasi Username) + SecretID (geheim, Pull-Mode empfohlen). SecretID mit secret_id_ttl und secret_id_num_uses begrenzen; Zustellung an die App über Response Wrapping (kurzlebiges Wrapping-Token) statt Klartext. token_type=batch empfohlen.

OIDC / JWT

Zwei Modi einer Methode: oidc = interaktiver Redirect-Flow (Authorization Code + PKCE, oidc_discovery_url + Client-ID/-Secret) für Menschen; jwt = Bearer-JWT gegen JWKS/statische Keys für Workloads/CI.

jwt-Rollen: Trägt das JWT einen aud-Claim, muss ein Eintrag in bound_audiences exakt passen (oidc-Rollen: optional); bound_claims prüft weitere Claims; user_claim bestimmt den Entity-Alias.

Policies (HCL)

Deny by default

Policies (HCL oder JSON) beschreiben erlaubte Pfade, leere Policy = kein Zugriff. Capabilities: create, read, update, patch, delete, list, sudo (root-protected Paths), deny (gewinnt immer), subscribe (Events), recover (Einzel-Recovery aus geladenem Snapshot, Enterprise).

default-Policy hängt an jedem Token; root-Policy kann alles, nie an Alltags-Tokens.

# app-ro.hcl -- KV v2 braucht data/-Prefix!
path "secret/data/app/*" {
  capabilities = ["read"]
}
path "secret/metadata/app/*" {
  capabilities = ["list"]
}

Globs

* nur am Pfadende = Prefix-Match (secret/data/bar/*).

+ = genau ein Segment, secret/data/+/team trifft secret/data/foo/team.

vault policy write app-ro app-ro.hcl lädt die Policy.

Token-Lifecycle

Service vs. Batch

Service-Tokens (hvs.): renewbar, revozierbar, Accessor, können Child-Tokens erzeugen, Zustand im Storage.

Batch-Tokens (hvb.): verschlüsselter Blob ohne Storage-Eintrag, nicht renewbar, kein Child, leichtgewichtig für hohe Last.

TTL, Renewal, Orphan

Jedes Nicht-Root-Token hat eine TTL; Renewal verlängert bis zur Max-TTL (System-Default 32 Tage, konfigurierbar). Periodic Tokens leben beliebig lang, solange sie pro Periode renewed werden; explicit max TTL setzt eine harte Grenze.

Revoke eines Tokens revoked seine Child-Tokens mit, Orphan-Tokens haben keinen Parent und überleben.

vault token create -policy=app-ro -ttl=1h
vault token renew  <token>
vault token lookup            # eigenes Token
vault token revoke -accessor <accessor>

Kubernetes-Integration

Agent Injector (Annotations)

Mutating Webhook injiziert einen Vault-Agent-Sidecar; Secrets landen als Dateien unter /vault/secrets/. Templates rendern beliebige Formate. agent-pre-populate-only für Jobs/CronJobs (nur Init-Container, Pod terminiert sauber).

metadata:
  annotations:
    vault.hashicorp.com/agent-inject: "true"
    vault.hashicorp.com/role: "app"
    vault.hashicorp.com/agent-inject-secret-db:
      "secret/data/app/db"
    vault.hashicorp.com/agent-inject-template-db: |
      {{- with secret "secret/data/app/db" -}}
      pg://{{ .Data.data.user }}:{{ .Data.data.pass }}@db
      {{- end -}}

Vault CSI Provider

Der Secrets-Store-CSI-Driver mountet Secrets als Volume (SecretProviderClass), Auth über den Pod-ServiceAccount (kubernetes/JWT). Optionaler Sync in K8s-Secrets für Env-Vars. Alle Secrets Engines nutzbar.

VSO: Vault Secrets Operator

Operator synct Vault-Secrets in native K8s-Secrets: CRDs VaultConnection, VaultAuth, VaultStaticSecret, VaultDynamicSecret, VaultPKISecret. Remediert Drift am Ziel-Secret, rotiert und kann Deployments per rolloutRestartTargets neu ausrollen.

apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultStaticSecret
metadata: {name: app-db, namespace: prod}
spec:
  vaultAuthRef: app-auth
  mount: secret
  type: kv-v2
  path: app/db
  refreshAfter: 60s
  destination: {name: app-db, create: true}

Audit Devices

Pflicht für Prod

Typen: file, syslog, socket, loggen jeden Request/Response, außer u.a. sys/init, sys/unseal, sys/seal, sys/step-down, sys/rekey/init|update|verify, sys/health; generate-root wird auditiert. Sensible String-Werte stehen default nur als HMAC-SHA256-Hash im Log.

Blocking-Verhalten: Kann Vault auf kein aktiviertes Audit Device schreiben, beantwortet es keine Requests mehr, deshalb mindestens zwei Devices auf getrennten Pfaden.

vault audit enable file \
  file_path=/var/log/vault_audit.log
vault audit list

Versionen & Support

Schema V.M.F (ab 2.0)

V = Major, startet einen Support-Lifecycle; M = Feature-Release; F = Fix-Release. Fixes nur auf dem jüngsten Minor einer Major-Linie, kein Backport über Minor-Grenzen: Mit 2.1.0 endet die Pflege von 2.0.

Enterprise 2.x: IBM Support Cycle-2, 2 Jahre Base, 1 Jahr Extended (kritische Fixes), 3 Jahre Sustained (ohne Fixes). Letzte LTS ist 1.19, Extended Maintenance bis April 2027.

Community: Patches nur auf der aktuellen Linie, letzte Community-1.21er ist 1.21.4. Aktuelle Patchstände: vault-cheatsheet.de/lifecycle.

Upgrade auf 2.x: Stolpersteine

sys/rekey, sys/generate-root und DR-generate-operation-token verlangen ab 2.0.0 Key-Shares und ein gültiges Token; Altverhalten nur per enable_unauthenticated_access in der Server-Config.

Offizielle Container-Images ab 2.0.2 ohne IPC_LOCK: disable_mlock = true, Swap aus oder verschlüsselt.

Doppelte HCL-Attribute in Config und Policies sind seit 1.21 ein Fehler, ab 2.0.4 ohne Ausweg über VAULT_ALLOW_PENDING_REMOVAL_DUPLICATE_HCL_ATTRIBUTES; vor dem Upgrade, noch auf 1.20 oder älter, die Server-Logs auf “policy contains duplicate attributes” prüfen.

ACL: LIST mit abschließendem Slash umgeht ab 2.0.3 keine spezifischere deny-Regel mehr.

RSA-Schlüssel über 8192 Bit lehnt Vault ab 2.0.2 ab (CVE-2026-39829, im CHANGELOG unter secrets/ssh), vorher inventarisieren.

Identity-Templates in Policy-Pfaden: Rendert ein Metadatenwert + oder *, gibt es ab 2.0.1 “permission denied”.

UBI-Images ab 2.0.4 ohne gnupg, openssl, procps: Probes und Debug-Skripte prüfen.

Raft ab 2.1.1: max. 20 parallele retry_join-Worker, darüber Fehler “too many concurrent raft retry joins in progress”.

Mehrere dieser Änderungen kamen per Enterprise-Patch auch in die 1.x-Linien, z. B. Templates ab 1.19.17, 1.20.11, 1.21.6; IPC_LOCK und RSA ab 1.19.18, 1.20.12, 1.21.7. Enterprise-Patchstand vor dem Upgrade gegen den CHANGELOG prüfen.

Betrieb

Health-Checks für den LB

GET /v1/sys/health: 200 aktiv, 429 Standby, 473 Performance Standby, 472 DR-Secondary, 474 Standby ohne Verbindung zum Active, 501 nicht initialisiert, 503 sealed, 530 aus dem HA-Cluster entfernt. ?standbyok=true (Standby) bzw. ?perfstandbyok=true (Performance Standby) liefert stattdessen den Active-Code 200. Der Endpunkt wird nicht auditiert.

Anti-Patterns

Was du nicht tun solltest

Root-Token im Alltag: nur für Setup/Break-Glass; danach revoken. generate-root braucht ab 2.0 Quorum und gültiges Token; Notfallweg ohne Token: enable_unauthenticated_access = ["generate-root"] in die Server-Config, per SIGHUP ohne Restart laden, danach wieder entfernen.

KV als Konfig-Store: Vault verwaltet Secrets, kein allgemeines App-Config-Management, Nicht-Geheimes gehört in ConfigMaps/Git, sonst wächst Policy- und Audit-Fläche ohne Gewinn.

Policies auf secret/app statt secret/data/app: KV-v2-Pfad-Falle, die Policy greift nie.

Leases ignorieren: dynamische DB-Credentials cachen und nach Lease-Ablauf weiterverwenden bricht in Prod.

Kein/ein Audit Device: blind im Incident bzw. Blocking-Risiko, darum immer zwei.

Shamir-Shares bei einer Person: hebelt das Threshold-Konzept aus; Shares auf Rollen verteilen oder Auto-Unseal nutzen.

Sealed Vault als Ausnahme behandeln: Restart heißt sealed, ohne Auto-Unseal steht HA-Failover, bis das Quorum tippt.

Verwandte Cheatsheets

Ebenfalls von OMNI52:
kubernetes-cheatsheet.de, Kubernetes Core
istio-cheatsheet.de, Service-Mesh-Layer (Istio in der Tiefe)
rancher-cheatsheet.de, Rancher-Management
rke2-cheatsheet.de, RKE2-Distribution

Lizenz & Weiterverteilung

CC BY-SA 4.0. Du darfst dieses Cheatsheet kopieren, weiterverteilen, ausdrucken und in eigenen Materialien zitieren. Bedingung: Quellenangabe „Vault Cheatsheet, OMNI52 GmbH, vault-cheatsheet.de“ bleibt sichtbar, und abgeleitete Werke stehen unter der gleichen Lizenz (Share-Alike).

Nicht erlaubt: Logo, Marken oder den Eindruck zu vermitteln, dass der Inhalt von dir/euch stammt oder dass OMNI52 GmbH die Weiterverwendung sponsort.

Volltext der Lizenz: creativecommons.org/licenses/by-sa/4.0/deed.de.

Vault and HashiCorp are trademarks of HashiCorp, Inc. (an IBM Company). Vault is distributed under the Business Source License 1.1. OpenBao is an API-compatible community fork of Vault under MPL 2.0, hosted by the Linux Foundation. OMNI52™ is a trademark of OMNI52 GmbH (filed, not yet registered). This website is operated by OMNI52 GmbH and is not affiliated with, endorsed by, or sponsored by HashiCorp or IBM. “Vault” is used in a nominative / descriptive sense to indicate the technology this cheatsheet documents.