Secrets Engines sind das Herzstück von Vault – sie ermöglichen es, Sicherheit nicht nur als Speicherfrage, sondern als Prozess zu denken. Ob Datenbankpasswort, SSH-Zugang oder JWT-Signatur: Alles lässt sich dynamisch, sicher und nachvollziehbar verwalten – wenn man die richtigen Engines kennt und korrekt einsetzt. Der Schlüssel liegt dabei weniger in der Vielfalt, sondern im Verständnis und im Design. Wer Vault produktiv einsetzen will, kommt um ein tiefes Verständnis der Secrets Engines nicht herum.
Dieser Artikel bietet einen fundierten Überblick über Funktion, Einsatzmöglichkeiten und Lifecycle von Secrets Engines – von generischen Engines wie KV, Transit oder PKI bis hin zu spezialisierten Modulen für Cloud- und Datenbankplattformen.
Was sind Secrets Engines?
Secrets Engines sind spezialisierte Komponenten innerhalb von Vault, die geheime Daten speichern, generieren, verschlüsseln oder im Namen des Nutzers Aktionen durchführen. Man kann sich eine Secrets Engine als eine Art „Pluggable Service“ vorstellen, der über einen dedizierten Pfad in Vault aktiviert wird und je nach Typ unterschiedliche Aufgaben übernimmt.
Einige Secrets Engines dienen primär als sicherer Speicher – vergleichbar mit einem verschlüsselten Redis oder Memcached. Andere hingegen interagieren mit externen Systemen und erzeugen dynamisch Zugangsdaten, etwa für AWS IAM, Oracle Datenbanken oder SSH-Zugriffe. Wieder andere bieten kryptografische Services wie Encryption as a Service, TOTP- und QR-Code-Generierung oder die Ausstellung von Zertifikaten.
Technisch gesehen funktioniert jede Secrets Engine wie ein virtuelles Dateisystem, mit dem Nutzer über Operationen wie read, write oder delete interagieren. Ein Request an Vault wird automatisch an den zuständigen Pfad geroutet, an dem die Engine „gemountet“ ist. Dabei definiert jede Engine ihren eigenen Satz an Pfaden und Funktionen.
Typen von Secrets Engines: Überblick über das Vault-Ökosystem
Vault bietet eine breite Palette an Secrets Engines, die sich grob in zwei Kategorien gliedern lassen:
Spezialisierte Secrets Engines
Diese Engines richten sich an konkrete Plattformen und Dienste und erfordern typischerweise tiefes Fachwissen über die jeweilige Zielplattform:
- Cloud: AWS, Azure, Google Cloud, AliCloud
- Datenbanken: Cassandra, Couchbase, ElasticSearch, HANA, IBM DB2, Influx DB, MongoDB, MongoDB Atlas, MSSQL, MariaDB, MySQL, Oracle Database, PostgreSQL, Redis, Redis Elasticache, Redshift, Snowflake
- Identitätsdienste: Kerberos, LDAP, diverse Cloud-Dienste inkl. OCI, RADIUS, SAML, JWT/OIDC, Okta, Github, CloudFoundry, sw.
- Infrastrukturtools: Consul, Nomad, Terraform Cloud
- Messaging: RabbitMQ
- Weitere: Venafi, SSH, TOTP, Transform, diverse externe KMS, etc.
Hier ist zu beachten: Ein Vault-Engineer kann nicht Experte für jede Plattform sein. Die korrekte Konfiguration solcher Engines erfordert meist enge Zusammenarbeit mit Domänenexperten der jeweiligen Plattform.
Generische Secrets Engines
Diese Engines gehören zum Standardrepertoire und sollten jedem Vault-Anwender vertraut sein:
- Cubbyhole: Temporäre, tokengebundene Datenspeicherung. Ideal für private, flüchtige Secrets die nur im Speicher gehalten werden und nach einem Serverneustart verloren gehen können oder sollen.
- Key/Value (KV): Die wohl am weitesten verbreitete Engine für die Definition von Keys und an diese zugewiesene Werte, z.B. Username und Passwort. KV v2 unterstützt Versionierung, während KV v1 als veraltet gilt.
- Database: Unterstützt über 13 Plattformen über Plugins und ermöglicht das automatische Erstellen und Widerrufen von Datenbank-Credentials.
- Transit: Bietet Verschlüsselungsdienste ohne Speicherung. Ideal für Anwendungen, die sensible Daten lokal verarbeiten, aber zentrale Schlüsselverwaltung benötigen.
- PKI: Erstellt und verwaltet X.509-Zertifikate – ein Must-have für interne CA-Lösungen.
- Identity: Ermöglicht Identitätsverknüpfung, Alias-Verwaltung und Policy-Zuweisung.
Prüfungsrelevante Secrets Engines
Bei einer Zertifizierungsprüfung als Vault Associate und Vault Operations Professional sollten Sie diese Secret Engines gut kennen:
- Cubbyhole
- KV
- Identity
- PKI
- Database
- Transit
Wir werden diese Engines in eigenen Artikel separat genauer betrachten.
Lifecycle von Secrets Engines
Jede Secrets Engine durchläuft typischerweise einen Lebenszyklus: Sie wird
- aktiviert,
- konfiguriert,
- genutzt,
- regelmäßig „getuned“, und
- in vielen Use Cases auch wieder deaktiviert.
Besonders dynamisch erzeugte Secret Engines (z. B. für automatisiert erzeugte Datenbanken, Cloud-Accounts oder Mandanten) müssen nicht nur aktiviert, sondern auch regelmäßig verändert (getuned) und spätestens mit dem Entfernen der jeweils relevanten Infrasktrukturkomponente auch wieder abgeschaltet werden. Dies ist nicht nur ein Aufräumen, sondern auch ein wichtiger Nachweis für die Wahrung der Datenqualität und Einhaltung von regulatorischen Richtlinien wie Anforderungen des Datenschutzes. Deshalb ist die Auditbarkeit jeder Aktion ist ein zentraler Bestandteil der Vault-Sicherheitsarchitektur.
Aktivierung und Isolierung von Secrets Engines
Um eine Secrets Engine verwenden zu können, muss sie zunächst aktiviert werden – entweder über die CLI, die API oder die UI.
Secrets Engines müssen aktiv durch den Nutzer aktiviert werden (mit Ausnahme von Cubbyhole und Identity, die standardmäßig aktiv sind). Die Aktivierung erfolgt an einem eindeutigen, frei wählbaren Pfad, der als mount point dient. Vault setzt dabei folgende Prinzipien durch:
- Case-sensitive Pfade: kv/ und KV/ sind unterschiedliche Mounts
- Keine Namenskonflikte: Ein Mount foo/ verhindert foo/bar/
- Jede Engine ist isoliert: Zugriff nur auf die eigene Datenbasis
Wichtige Merkmale, die man als Engineer und Endbenutzer nie vergessen sollte - und auch jederzeit als Fragen in einer Zertifizierungsprüfung auftauchen können:
- Standardmäßig aktiv: Die Engines Cubbyhole und Identity sind bereits voraktiviert und können nicht deaktiviert werden.
- Manuelle Aktivierung: Alle anderen Engines erfordern eine explizite Aktivierung.
- Aktivierungsmethoden: Die Aktivierung kann über die Befehlszeile (CLI), die API oder die Benutzeroberfläche (UI) erfolgen.
- Interaktion über Pfade: Sämtliche Interaktionen mit einer Secrets Engine erfolgen über ihren Pfad.
- Isolierte Pfade: Jede aktivierte Engine ist vollständig vom Rest des Systems isoliert – sowohl logisch als auch physisch. Im Falle von Mandantenfähigkeit sind auch Engines mit identischen Mount Points (Pfaden) voneinander isoliert.
- Flexible Pfadnamen: Die Pfade müssen nicht mit dem Namen oder Typ der Secrets Engine übereinstimmen.
- Case-sensitive: Der Pfad ist Groß-/Kleinschreibung-sensitiv. Eine Engine unter kv/ ist nicht identisch mit KV/.
Im Hintergrund erhält jede aktivierte Engine einen zufällig generierten UUID-basierten Speicherpfad in der Vault-Storage-Layer. Dieser Speicherpfad ist vergleichbar mit einem chroot. Diese „Barrier View“ stellt sicher, dass eine Engine nur auf ihre eigenen Daten zugreifen kann. Selbst im Fall einer kompromittierten Engine ist damit ein Zugriff auf andere Secrets Engines ausgeschlossen, auch innerhalb des gleichen Namespaces (Mandanten).
Pro Tip: Es ist sinnvoll, eine konsistente Benennungskonvention für Ihre Secrets Engines zu entwickeln, die für Ihre Organisation passend ist. Falls Sie mit Namespaces arbeiten, können verbindliche Namenskonventionen die Komplexität des Gesamtsystems und damit das Risiko sowie den Aufwand im Betrieb stark reduzieren.
Aktivieren über die Befehlszeile
Der Befehl vault secrets ist der Haupteinstiegspunkt für die Verwaltung von Secrets Engines über die CLI. Wichtige Unterbefehle sind:
- disable: Deaktiviert eine Secrets Engine
- enable: Aktiviert eine neue Secrets Engine
- list: Listet alle aktivierten Secrets Engines auf
- move: Verschiebt eine Secrets Engine von einem Pfad zu einem anderen
- tune: Konfiguriert Parameter einer Secrets Engine
Beispiele
1. Aktivieren der KV (Key/Value) Secrets Engine auf dem Default-Pfad
[rramge@ol9 ~]$ vault secrets enable kv Success! Enabled the kv secrets engine at: kv/ [rramge@ol9 ~]$
Überprüfung:
[rramge@ol9 ~]$ vault secrets list Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_fe623ade per-token private secret storage identity/ identity identity_cd5a6252 identity store kv/ kv kv_62ea76c1 n/a sys/ system system_b247c51c system endpoints used for control, policy and debugging [rramge@ol9 ~]$
Sie sehen hier neben der KV Secrets Engine noch die Cubbyhole und Identity Secrets Engines, da diese, wie bereits erwähnt, immer vorhanden sind. Die System-Engine ist nicht zum Speichern von Daten, sondern zur Arbeit mit Vault selbst gedacht - dazu kommen wir noch in späteren Artikeln, je nach Bedarf.
2. Aktivieren der KV (Key/Value) Secrets Engine auf einem individuellen Pfad:
Hier wird zusätzlich noch das Argument --path=<mount-point> mitgegeben:
[rramge@ol9 ~]$ vault secrets enable -path=mykv kv Success! Enabled the kv secrets engine at: mykv/ [rramge@ol9 ~]$
Überprüfung:
[rramge@ol9 ~]$ vault secrets list Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_fe623ade per-token private secret storage identity/ identity identity_cd5a6252 identity store kv/ kv kv_62ea76c1 n/a mykv/ kv kv_5fa9f096 n/a sys/ system system_b247c51c system endpoints used for control, policy and debugging [rramge@ol9 ~]$
3. Aktivierung der KV (Key/Value) Secrets Engine mit zusätzlicher Beschreibung
Man kann auch das Argument --description mitgeben:
[rramge@ol9 ~]$ vault secrets enable -path=mykv --description="My K/V Secret Store" kv Success! Enabled the kv secrets engine at: mykv/ [rramge@ol9 ~]$
Das Resultat wäre dann:
[rramge@ol9 ~]$ vault secrets list Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_fe623ade per-token private secret storage identity/ identity identity_cd5a6252 identity store kv/ kv kv_62ea76c1 n/a mykv/ kv kv_645ae3a2 My K/V Secret Store sys/ system system_b247c51c system endpoints used for control, policy and debugging [rramge@ol9 ~]$
4. Eine Secrets Engine wieder abschalten
Entfernen wir die beiden Secret Engines unter kv/ und mykv/ wieder:
[rramge@ol9 ~]$ vault secrets disable mykv Success! Disabled the secrets engine (if it existed) at: mykv/ [rramge@ol9 ~]$ vault secrets disable kv Success! Disabled the secrets engine (if it existed) at: kv/ [rramge@ol9 ~]$
Achtung: Wenn Sie eine bestehende Secrets Engine, welche bereits Secrets enthält, wieder abschalten, droht ein Datenverlust! Das Deaktivieren einer Secrets Engine löscht alle zugehörigen Daten – ein vorheriges Backup ist unbedingt empfohlen, insbesondere bei persistenten Engines wie KV oder PKI.
Aktivieren über die API mittels Terraform
Neben der CLI bietet sich auch eine deklarative API-Steuerung über Terraform an. Sie können ein Terraform-Modul für die Verwaltung von Secret Engines und deren Eigenschaften hier finden: https://github.com/ICT-technology/terraform-vault-mount/
Dieses Modul ist ein dynamisches Modul zum Erzeugen und Management mehrerer Secret Engines in einem Modulaufruf. Es fängt API-Fehler proaktiv ab, implementiert Best Practices im Umgang mit Secret Engines und unterstützt automatisierte Testpipelines mittels terraform test.
Benutzungsbeispiel
Sie finden ein lauffähiges Beispiel im examples/ Subfolder. Setzen Sie ihre Umgebungsvariablen $VAULT_ADDR und $VAULT_TOKEN korrekt und dann sollte es direkt aus diesem Subfolder heraus einsetzbar sein - stellen Sie aber sicher, dass Sie es in einer privaten Entwicklungsumgebung ausführen und nicht in einer Produktionsumgebung.
Das Modul legt folgende Secret Engines an:
- kv-v2
- pki
- kubernetes
- ldap
- transit
- aws
Nach erfolgreichem terraform apply wird das Modul eine Liste von mount-accessors der angelegten Secret Engines ausgehen. Diese mount-accessors kann man danach als Verweis in der Konfiguration von anderen Terraform-Ressourcen verwenden, aber auch für Themen wie Auditing und dynamische Policy-Zuweisungen.
examples/main.tf:
### BEGIN FILE: examples/main.tf ###
module "vault_mounts" {
source = "git::https://github.com/ICT-technology/terraform-vault-mount.git?ref=v2025.1.3"
mounts = {
kvv2 = {
path = "kv-v2"
type = "kv-v2"
description = "Key-Value Version 2 Secrets Engine"
options = { version = "2" }
}
pki = {
path = "pki"
type = "pki"
description = "PKI Secrets Engine"
default_lease_ttl_seconds = 3600
max_lease_ttl_seconds = 86400
}
kubernetes = {
path = "kubernetes"
type = "kubernetes"
description = "Kubernetes Auth Engine"
}
ldap = {
path = "ldap"
type = "ldap"
description = "LDAP Auth Engine"
options = { case_sensitive_names = "true" }
}
transit = {
path = "transit"
type = "transit"
description = "Transit Secrets Engine for Encryption-as-a-Service"
options = {
convergent_encryption = false
}
}
aws = {
path = "aws"
type = "aws"
description = "AWS Secrets Engine"
}
}
}
### END FILE: examples/main.tf ###examples/outputs.tf:
### BEGIN FILE: examples/outputs.tf ###
output "mount_accessors" {
description = "Accessors for the configured Vault mounts"
value = module.vault_mounts.mount_accessor
}
### END FILE: examples/outputs.tf ###In der Praxis sieht ein terraform apply auf dieses Beispiel dann so aus:
[rramge@ol9 examples]$ terraform apply
[...]
Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value: yes module.vault_mounts.vault_mount.this["aws"]: Creating... module.vault_mounts.vault_mount.this["transit"]: Creating... module.vault_mounts.vault_mount.this["kvv2"]: Creating... module.vault_mounts.vault_mount.this["ldap"]: Creating... module.vault_mounts.vault_mount.this["kubernetes"]: Creating... module.vault_mounts.vault_mount.this["pki"]: Creating... module.vault_mounts.vault_mount.this["aws"]: Creation complete after 1s [id=aws] module.vault_mounts.vault_mount.this["pki"]: Creation complete after 1s [id=pki] module.vault_mounts.vault_mount.this["transit"]: Creation complete after 1s [id=transit] module.vault_mounts.vault_mount.this["kvv2"]: Creation complete after 1s [id=kv-v2] module.vault_mounts.vault_mount.this["kubernetes"]: Creation complete after 1s [id=kubernetes] module.vault_mounts.vault_mount.this["ldap"]: Creation complete after 1s [id=ldap] Apply complete! Resources: 6 added, 0 changed, 0 destroyed. Outputs: mount_accessors = { "aws" = "aws_e2982916" "kubernetes" = "kubernetes_6671be50" "kvv2" = "kv_26a6e11a" "ldap" = "ldap_8fbb6083" "pki" = "pki_2d96cba8" "transit" = "transit_25465e3f" } [rramge@ol9 examples]$
Aktivieren über die Weboberfläche
Auch die Aktivierung über eine Weboberfläche ist möglich. Vault bietet ein optional aktivierbares Web UI, welches sehr schlicht und eher als Showcase für Marketing-Präsentationen als für den administrativen Einsatz in größeren Produktionsumgebungen geeignet ist.
Auf diese webbasierte Oberfläche möchte ich an dieser Stelle nicht eingehen - ich gehe davon aus, dass Sie als technisch affiner und versierter Leser die Wichtigkeit und Notwendigkeit von reproduzierbaren Konfigurationsschritten und Automatisierung in sicherheitsrelevanten Kontexten erkennen, anstelle auf Mausklicks Wert zu legen. Lernen Sie stattdessen besser die CLI-Kommandos und erkennen Sie den Mehrwert von Infrastructure-as-Code, denn Sie benötigen dies sowohl in der Praxis, als auc als Vorbereitung auf eine Zertifizierungsprüfung.
Ausblick
Im nächsten Deep-Dive-Artikel über HashiCorp Vault werden wir einen ersten Blick auf die Key/Value Secrets Engine werfen, bevor wir dann richtig tief in diese einsteigen werden.
