Vault Cheatsheet OMNI52™ GmbH

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 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

Vault Cheatsheet Seite 2: Policies, Token-Lifecycle, K8s-Integration, Audit, Anti-Patterns

PDF herunterladen

Direkter Download, keine Mail-Adresse nötig. CC BY-SA 4.0 — kopieren, drucken, weiterverteilen ist 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, 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. Root-Token im Alltag, KV als Konfig-Store, KV-v2-Policy-Falle.

Cheatsheet im Volltext

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

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.

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 -version=2 kv
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.

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=$(base64 <<< "geheim")
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, kubernetes_ca_cert, token_reviewer_jwt. 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.

bound_audiences muss exakt einem aud-Claim entsprechen; 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).

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/*). + matcht 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

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. 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

Anti-Patterns

Was du nicht tun solltest

Root-Token im Alltag: nur für Setup/Break-Glass; danach revoken (vault token revoke) und bei Bedarf per generate-root + Quorum neu erzeugen.

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 — 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 heisst sealed — ohne Auto-Unseal steht HA-Failover, bis das Quorum tippt.

Aus der OMNI52 Cheatsheet-Fabrik

Verwandte Sheets in dichter Senior-Qualität:
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.

Vaultauf einem Blatt.

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

PDF herunterladen

Was drin steht

Seal & HA

Secrets Engines

Auth-Methoden

Policies & Tokens

K8s-Integration

Audit & Anti-Patterns

Cheatsheet im Volltext

Architektur: Seal & Unseal

Seal / Unseal

Shamir vs. Auto-Unseal

Integrated Storage (Raft)

Secrets Engines

KV v2: versionierte Secrets

Database: dynamische Credentials

PKI: Zertifikate on demand

Transit: Encryption as a Service

Auth-Methoden

kubernetes

AppRole

OIDC / JWT

Policies (HCL)

Deny by default

Globs

Token-Lifecycle

Service vs. Batch

TTL, Renewal, Orphan

Kubernetes-Integration

Agent Injector (Annotations)

Vault CSI Provider

VSO: Vault Secrets Operator

Audit Devices

Pflicht für Prod

Anti-Patterns

Was du nicht tun solltest

Aus der OMNI52 Cheatsheet-Fabrik

Lizenz & Weiterverteilung

Vault
auf einem Blatt.