Nachdem wir im ersten Teil bereits einen fundierten Überblick über das gesamte Ökosystem der Secrets Engines gewonnen haben, tauchen wir nun in den Alltag eines jeden Vault‑Clusters ein. Die Key / Value (KV) Secrets Engine ist das Arbeitspferd für alle Situationen, in denen Geheimnisse sicher abgelegt, versioniert und später gezielt wieder abgerufen werden müssen.
Obwohl Vault vor allem für seine dynamischen Fähigkeiten bekannt ist, existiert in jeder realen Umgebung eine stattliche Zahl an statischen Werten – beginnend bei API‑Schlüsseln externer SaaS‑Dienste, über Service‑Account‑Passwörter ohne Ablaufdatum bis hin zu Zertifikats‑Bundles für Legacy‑Systeme. Ohne einen robuste Key/Value‑Speicher würden diese Daten weiterhin und oftmals unkontrolliert in Textdateien, Git‑Repos, CI‑Systemen oder gar in Excel‑Tabellen herumgeistern. Genau das verhindert die Key/Value Secrets Engine.
In diesem Unterkapitel werfen wir einen praxisnahen Blick darauf,
- wie eine solche Key/Value Secrets Engine aktiviert wird,
- welche Überlegungen in die Wahl des Mount‑Pfades einfließen und
- wie man eine hierarchische Struktur entwirft, die auch in fünf Jahren noch verständlich ist.
In den folgenden Unterkapiteln ab Teil 2b werden wir dann in unterschiedliche Aspekte der Key/Value Secrets Engine einsteigen - dazu gehören die Unterschiede zwischen den beiden Varianten des KV-Stores, das Durchführen von Upgrades von der alten auf die neue Version, wie man Daten schreibt und liest, wie man mit Metadaten umgeht, und wie man gespeicherte Secrets versionieren, löschen und wiederherstellen kann.
Was ist die Key / Value Secrets Engine?
Die Key/Value Secrets Engine (o0der auch kurz einfach KV‑Engine genannt) beantwortet eine einfache, jedoch allgegenwärtige Frage:
Wo bewahren wir unveränderliche Geheimnisse so auf, dass sie vor neugierigen Blicken geschützt, revisionssicher protokolliert und gleichzeitig für Integrations‑Pipelines, menschliche Anwender und Applikationen leicht zugänglich bleiben?
Technisch gesehen handelt es sich um einen verschlüsselten, transaktionalen Key‑Value‑Store, der sämtliche Daten transparent mit 256‑bit AES verschlüsselt, bevor sie im Storage Backend landen.
Jede Lese‑ oder Schreiboperation wird durch das Audit‑Subsystem von Vault lückenlos protokolliert, sodass sich später exakt nachvollziehen lässt, wer wann auf welchen Pfad zugegriffen hat.
Für Teams, die bisher auf Cloud‑KMS‑Lösungen oder Parameter‑Stores gesetzt haben, ist die KV‑Engine oft der erste Berührungspunkt mit Vault, denn sie bietet ein vertrautes Datenmodell bei gleichzeitig deutlich erweiterten Sicherheits‑ und Automatisierungs‑Funktionen.
Zwei Versionen, zwei Philosophien
Ein Detail, das immer wieder für Verwirrung sorgt: Es existieren zwei Spielarten dieser Engine.
- Version 1 (kv): Die klassische, nicht-versionierte Variante
- Version 2 (kv-v2): Die moderne, versionierte Variante
Version 1, intern schlicht »kv«, speichert genau eine aktuelle Version pro Eintrag. Ein Überschreiben löscht die alten Daten unwiderruflich. Dies ist ein Verhalten, das in frühen Vault‑Tagen absolut ausreichend war, aber heutigen Compliance‑Anforderungen nicht mehr gerecht wird.
Version 2, konfigurierbar unter dem Namen kv‑v2 oder über den Parameter ‑version=2, führt pro Eintrag dagegen eine vollständige Historie. Jede Änderung an einem Key/Value-Paar legt eine neue Revision an, die sich später gezielt abrufen oder wiederherstellen lässt. Auch Soft‑Deletes mit definierter Aufbewahrungsfrist sind möglich, bevor ein Wert endgültig vernichtet wird.
In modernen Installationen sollte deshalb ausschließlich die v2‑Variante eingesetzt werden. v1 kommt höchstens noch dann zum Zuge, wenn Legacy‑Workloads auf eine stabile API angewiesen sind und kurzfristig nicht umgestellt werden können.
Neben der reinen Versionierung bringt v2 weitere Merkmale mit: Jeder Eintrag kann zum Beispiel mit einem optionalen Check‑and‑Set‑Index geschützt werden, der sogenannte Blind Writes verhindert. Außerdem lassen sich die maximal aufbewahrten Revisionen serverseitig begrenzen, um Speicherverbrauch und Replikations‑Traffic kalkulierbar zu halten.
Für die Zertifizierungs‑Prüfung ist wichtig zu wissen, dass ein Upgrade von v1 auf v2 nicht automatisch geschieht. Der Migrations‑Prozess muss aktiv gestartet werden und erfordert passende ACLs sowie eventuell einen Multi‑Step‑Plan, wenn dutzende Anwendungen beteiligt sind. Es ändern sich auch API-Pfade, d.h. etwaige Skripte und Applikationen müssen Bei einer Migration von v1 auf v2 angepasst werden.
Wichtig für die Praxis: In neuen Implementierungen sollte fast ausschließlich Version 2 zum Einsatz kommen. Version 1 gilt als veraltet und findet nur noch in speziellen Legacy-Szenarien Verwendung.
Zugriffsmöglichkeiten und Integration
Wie bei allen Komponenten von Vault stehen drei Haupt‑Interaktionswege zur Verfügung.
- UI: Für interaktive Nutzung und schnelle Einblicke, ideal für schnelle Ad‑hoc‑Arbeiten in Entwicklungs- und Demo‑Umgebungen. Da dies für Produktionsumgebungen nicht ausreichend ist, gehen wir in dieser Artikelserie nicht näher auf die UI ein.
- CLI: Für Administratoren und Scripting. Das CLI ist das produktionstaugliche Äquivalent zu Mausklicks in der UI. Unsere Codebeispiele arbeiten mit dem CLI.
- API: Für die Automation und Integration in Pipelines und Anwendungen.
Die Nutzung der API mittels Infrastructure-as-Code ist der Standard für Produktionsumgebungen. Ein Build‑Job kann beispielsweise unmittelbar vor dem Deployment einen frischen Token anfordern und sich dann über einen simplen GET‑Request das gewünschte Secret aus dem KV‑Pfad apps/payment/prod/api_key ziehen.
Für Workloads wie Applikationen bietet sich der Vault Agent an, der die Daten in temporäre Dateien zur Verfügung und die Zugangstokens der Applikation selbstständig erneuert. Durch diese Flexibilität passt sich die KV‑Engine an praktisch jeden Workflow an, ohne dass zentrale Sicherheitsziele aufgeweicht werden müssen.
Sicherheit als Design
Alle Daten in der KV‑Engine werden noch vor dem Speichern verschlüsselt. Dadurch spielt es weder für Auditoren noch für Betriebs‑Teams eine Rolle, ob das physische Backend eine lokales Filesystem, ein Consul Cluster (war bis vor einigen Jahren Standard) oder das integrierte Raft‑Backend (heutiger Standard) ist. Selbst ein kompromittierter Storage hat keine Möglichkeit, Klartext zu rekonstruieren.
Die Zugriffsrechte steuert Vault über sein Policy‑System. Einzelne Pfade lassen sich mit Policy-Regeln basierend auf Berechtigungen wie read, create, update oder delete absichern. Ein typisches Produktions‑Szenario sieht so aus, dass Entwickler Leserechte auf einen Pfad wie apps/*/prod erhalten, während nur das Operations‑Team dort schreiben darf.
Durch das Vergeben spezieller Capabilities wie list kann man verhindern, dass neugierige Augen überhaupt erfahren, welche untergeordneten Pfade existieren.
Als zusätzliche Sicherheits‑Schicht können Token Tiers oder Control Groups eingesetzt werden, zum Beispiel um besonders sensible Aktionen einer Mehr‑Faktor‑Freigabe zu unterwerfen.
Praktische Aktivierung
Die Aktivierung einer KV‑Engine erfolgt, wie bereits in Teil 1 gezeigt, über den Befehl vault secrets enable <engine>.
Sobald der Mount‑Punkt definiert ist, gilt er als Namenraum – vollständig isoliert von anderen Engines. Behalten Sie im Auge, dass ein nachträgliches Umbenennen nur über vault secrets move möglich ist und unter Umständen umfangreiche Policy‑Anpassungen erfordert.
Version 1 aktivieren
# Standard-Aktivierung von KV v1
$ vault secrets enable kv
Success! Enabled the kv secrets engine at: kv/
# Aktivierung an einem benutzerdefinierten Pfad
$ vault secrets enable -path=legacy-secrets kv
Success! Enabled the kv secrets engine at: legacy-secrets/
Version 2 aktivieren
# Methode 1: Explizite Angabe von kv-v2 $ vault secrets enable kv-v2 Success! Enabled the kv-v2 secrets engine at: kv-v2/ # Methode 2: Version als Parameter $ vault secrets enable -path=secrets -version=2 kv Success! Enabled the kv-v2 secrets engine at: secrets/
Profi-Tipps aus der Praxis
1. Jeder Mount sollte sofort mit einer Beschreibung versehen werden, damit Kollegen in sechs Monaten noch wissen, wofür er gedacht war.
2. Es lohnt sich, bei produktiven v2‑Mounts die Option max_versions zu setzen, sobald klar ist, wie viele Revisionen wirklich benötigt werden. In regulierten Branchen, in denen eine zehnjährige Aufbewahrung gefordert ist, muss der Wert entsprechend großzügig kalkuliert werden.
3. Ich empfehle, den Parameter cas_required auf true zu setzen, um den Check-and-Set-Mechanismus zu aktivieren und versehentliche parallele Überschreibungen auszuschließen. Dann muss nämlich jeder Schreibzugriff auf ein Secret (also create, update oder patch) auch den cas-Parameter enthalten. Der cas-Parameter dient als Versionsprüfung: Ein Schreibvorgang wird nur dann erfolgreich abgeschloissen, wenn der cas-Wert der aktuellen Version des Secrets tatsächlich entspricht. Dadurch bekommen Sie parallele Schreibvorgänge auf Secrets unter Kontrolle.
Versionserkennung
Gerade in großen Umgebungen stellt sich häufig die Frage, welche Mount‑Punkte bereits auf der KV-Engine v2 laufen. Der folgende Befehl zeigt die Antwort in der Spalte »Options«.
$ vault secrets list --detailed Path Type Accessor Description Options ---- ---- -------- ----------- ------- cubbyhole/ cubbyhole cubbyhole_abc123 [...] map[] kv/ kv kv_def456 [...] map[] secrets/ kv kv_ghi789 [...] map[version:2]
Ja, sie haben Recht: Das muss man erstmal wissen.
Fehlt der Eintrag version:2 innerhalb von map[], handelt es sich um eine alte v1‑Instanz.
In Automations‑Skripten empfiehlt es sich, diese Ausgabe maschinenlesbar nach version:2 zu parsen und nicht nur den Pfadnamen zu prüfen. Denn nicht nur ist der Pfadname (Mountpoint) einer KV-Engine frei wählbar, sondernAnwender können einen v1‑Mount auch ohne weiteres kv‑v2 nennen.
Pfadkonzept und Isolation
Jede aktivierte KV‑Engine bildet einen eigenen Namensraum. Dies bedeutet:
- Case-Sensitivity: Die Pfade kv/ und KV/ sind unterschiedlich und völlig unabhängig, weil Vault Groß‑ und Kleinschreibung unterscheidet.
- Keine Überlappungen: Ein Mount bei secrets/ verhindert zusätzliche Mounts auf untergeordnete Pfade wie secrets/sub/. Dadurch wird ausgeschlossen, dass zwei Teams versehentlich dieselben Verzeichnisse befüllen, was zum Beispiel passieren könnte, wenn es Missverständnisse bei den zugeteilten Namespaces gibt.
- Vollständige Isolation: Hinter den Kulissen erhält jede Engine einen zufällig generierten UUID‑Pfad, der wie ein chroot funktioniert. Selbst falls ein Mount kompromittiert würde, könnte es nicht auf Daten anderer Engines zugreifen.
Strukturierung von Secrets
Eine saubere Namenskonvention sorgt für kurze Zugriffspfade, eindeutige Verantwortlichkeiten und letztlich für weniger Support‑Fragen. Ein häufig genutztes Muster lautet »//<secret‑group>/«. In der Praxis könnte das so aussehen:
apps/
└── aws/
├── prod/
│ ├── user: dbadmin
│ ├── password: P@ssw0rd
│ └── api_key: b93md83mdmapw
└── dev/
├── cert: -----BEGIN CERTIFICATE-----
└── key: -----BEGIN PRIVATE KEY-----
Das hier erstellte Verzeichnis apps/aws/ dient nur als Container, darin liegt kein Secret. Erst die untersten Knoten enthalten die tatsächlichen Schlüssel–Wert‑Paare.
Der Vorteil dieser Hierarchie liegt in der einfachen Delegation von Rechten. Ein Dev‑Team könnte read-Berechtigung auf alle Pfade mit dev im Namen erhalten, während das Ops‑Team globale Schreibrechte für die Produktion innerhalb des zugeteilten Namespaces behält (Namespaces sind virtuelle und voneinander isolierte Vault-Instanzen innerhalb Vault Enterprise).
Berechtigungsmodell
Für die Arbeit mit der KV Engine werden fünf verschiedene Berechtigungen, sogenannte Capabilities, benötigt:
- create: Neue Secrets anlegen (überschreibt existierende in v1)
- update: Bestehende Secrets ändern (nur relevant für v2)
- read: Secrets lesen (werden im Klartext zurückgeliefert)
- delete: Secrets löschen, wahlweise soft oder hard
- list: Verfügbare Secrets in einem Pfad auflisten (nur die Keys, nicht deren Werte)
Diese Capabilities werden über Policies zugewiesen – ein Thema, das wir in einem späteren Artikel vertiefen werden. Hier sei kurz erklärt: Policies kombinieren diese Rechte und knüpfen sie an Token Roles. So können Sie einem CI‑System ermöglichen, während der Build‑Phase schreibend auf Pfade wie apps/build zuzugreifen, im Release‑Job jedoch ausschließlich lesend auf apps//prod.
Ausblick
In diesem Artikel haben wir die Grundlagen der Key/Value Secrets Engine kennengelernt und die wichtigen Unterschiede zwischen Version 1 und 2 verstanden.
Im nächsten Teil werden wir tiefer in die praktische Nutzung einsteigen: Wie speichern, lesen und verwalten wir Secrets? Welche Best Practices gibt es für die Pfadstruktur? Und wie nutzen wir die Versionierung von KV v2 optimal?
Bleiben Sie dran – es wird praktisch!
