Secrets Engines are the core of Vault – they enable us to think of security not just as a matter of storage, but as a process. Whether it's a database password, SSH access, or JWT signature, everything can be managed dynamically, securely, and traceably – if the right engines are known and used correctly. The key lies less in diversity and more in understanding and design. Anyone who wants to use Vault productively cannot avoid a deep understanding of the Secrets Engines.
This article offers a well-founded overview of the function, use cases, and lifecycle of Secrets Engines – from generic engines like KV, Transit, or PKI to specialized modules for Cloud and database platforms.
What are Secrets Engines?
Secrets Engines are specialized components within Vault that store, generate, encrypt, or perform actions on behalf of the user. You can think of a Secrets Engine as a kind of "pluggable service" that is enabled at a dedicated path in Vault and takes on different tasks depending on its type.
Some Secrets Engines primarily serve as secure storage – comparable to an encrypted Redis or Memcached. Others interact with external systems and dynamically generate credentials, for example for AWS IAM, Oracle databases, or SSH access. Still others offer cryptographic services such as Encryption as a Service, TOTP and QR code generation, or the issuance of certificates.
From a technical perspective, every Secrets Engine functions like a virtual file system with which users interact through operations like read, write, or delete. A request to Vault is automatically routed to the corresponding path where the engine is "mounted". Each engine defines its own set of paths and functions.
Types of Secrets Engines: Overview of the Vault Ecosystem
Vault offers a broad range of Secrets Engines, which can roughly be divided into two categories:
Specialized Secrets Engines
These engines are designed for specific platforms and services, and typically require in-depth expertise about the target platform:
- Cloud: AWS, Azure, Google Cloud, AliCloud
- Databases: Cassandra, Couchbase, ElasticSearch, HANA, IBM DB2, Influx DB, MongoDB, MongoDB Atlas, MSSQL, MariaDB, MySQL, Oracle Database, PostgreSQL, Redis, Redis Elasticache, Redshift, Snowflake
- Identity Services: Kerberos, LDAP, various cloud services including OCI, RADIUS, SAML, JWT/OIDC, Okta, Github, CloudFoundry, etc.
- Infrastructure Tools: Consul, Nomad, Terraform Cloud
- Messaging: RabbitMQ
- Other: Venafi, SSH, TOTP, Transform, various external KMS, etc.
One important note: A Vault engineer cannot be an expert in every platform. The correct configuration of such engines usually requires close collaboration with domain experts for the respective platform.
Generic Secrets Engines
These engines belong to the standard toolkit and should be familiar to every Vault user:
- Cubbyhole: Temporary, token-bound data storage. Ideal for private, ephemeral secrets that are kept only in memory and can or should be lost after a server restart.
- Key/Value (KV): Arguably the most widely used engine for defining keys and assigning values to them, such as username and password. KV v2 supports versioning, while KV v1 is considered deprecated.
- Database: Supports more than 13 platforms via plugins and enables automatic creation and revocation of database credentials.
- Transit: Provides encryption services without storing data. Ideal for applications that process sensitive data locally but require central key management.
- PKI: Issues and manages X.509 certificates – a must-have for internal CA solutions.
- Identity: Enables identity linking, alias management, and policy assignment.
Secrets Engines Relevant for Certification Exams
If you are preparing for a certification exam as a Vault Associate or Vault Operations Professional, you should be well-acquainted with the following Secret Engines:
- Cubbyhole
- KV
- Identity
- PKI
- Database
- Transit
We will take a closer look at these engines in separate dedicated articles.
Lifecycle of Secrets Engines
Each Secrets Engine typically goes through a lifecycle: It is
- enabled,
- configured,
- used,
- regularly "tuned", and
- in many use cases also disabled again.
Especially dynamically generated Secrets Engines (for example, for automatically provisioned databases, cloud accounts, or tenants) must not only be enabled but also regularly updated (tuned) and eventually shut down once the corresponding infrastructure component is removed. This is not just about cleanup, but also a critical demonstration of maintaining data quality and meeting regulatory requirements such as data protection laws. Therefore, the auditability of every action is a central part of Vault's security architecture.
Enabling and Isolating Secrets Engines
To use a Secrets Engine, it must first be enabled – either through the CLI, the API, or the UI.
Secrets Engines must be explicitly enabled by the user (with the exception of Cubbyhole and Identity, which are enabled by default). The activation takes place at a unique, freely chosen path that serves as the mount point. Vault enforces the following principles:
- Case-sensitive paths: kv/ and KV/ are different mounts
- No name conflicts: A mount foo/ prevents foo/bar/
- Each engine is isolated: Access is restricted to its own data set
Important characteristics that engineers and end users should never forget – and which can also appear as questions in a certification exam at any time:
- Enabled by default: The Cubbyhole and Identity engines are pre-enabled and cannot be disabled.
- Manual activation: All other engines require explicit activation.
- Activation methods: Activation can be done via the command line (CLI), the API, or the user interface (UI).
- Interaction via paths: All interactions with a Secrets Engine take place via its path.
- Isolated paths: Each enabled engine is fully isolated from the rest of the system – both logically and physically. In the case of multi-tenancy, engines with identical mount points (paths) are still isolated from one another.
- Flexible path names: Paths do not have to match the name or type of the Secrets Engine.
- Case-sensitive: The path is case-sensitive. An engine mounted at kv/ is not the same as one at KV/.
In the background, each enabled engine receives a randomly generated UUID-based storage path in the Vault storage layer. This storage path is comparable to a chroot. This "barrier view" ensures that an engine can only access its own data. Even in the case of a compromised engine, access to other Secrets Engines is ruled out – even within the same namespace (tenant).
Pro Tip: It is advisable to develop a consistent naming convention for your Secrets Engines that fits your organization. If you are working with namespaces, binding naming conventions can significantly reduce the complexity of the overall system – and with it, the risk and operational effort.
Enabling via the Command Line
The vault secrets command is the main entry point for managing Secrets Engines via the CLI. Important subcommands include:
- disable: Disables a Secrets Engine
- enable: Enables a new Secrets Engine
- list: Lists all enabled Secrets Engines
- move: Moves a Secrets Engine from one path to another
- tune: Configures parameters of a Secrets Engine
Examples
1. Enabling the KV (Key/Value) Secrets Engine at the default path
[rramge@ol9 ~]$ vault secrets enable kv Success! Enabled the kv secrets engine at: kv/ [rramge@ol9 ~]$
Verification:
[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 ~]$
Here you see the KV Secrets Engine in addition to the Cubbyhole and Identity Secrets Engines, which, as mentioned, are always present. The system engine is not for storing data, but for working with Vault itself – we will cover that in later articles as needed.
2. Enabling the KV (Key/Value) Secrets Engine at a custom path:
In this case, the argument --path=<mount-point> is also provided:
[rramge@ol9 ~]$ vault secrets enable -path=mykv kv Success! Enabled the kv secrets engine at: mykv/ [rramge@ol9 ~]$
Verification:
[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. Enabling the KV (Key/Value) Secrets Engine with additional description
You can also provide the --description argument:
[rramge@ol9 ~]$ vault secrets enable -path=mykv --description="My K/V Secret Store" kv Success! Enabled the kv secrets engine at: mykv/ [rramge@ol9 ~]$
The result would be:
[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. Disabling a Secrets Engine
Let’s remove the two Secrets Engines mounted at kv/ and mykv/:
[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 ~]$
Warning: If you disable an existing Secrets Engine that already contains secrets, you risk data loss! Disabling a Secrets Engine deletes all associated data – a prior backup is strongly recommended, especially for persistent engines like KV or PKI.
Enabling via API using Terraform
In addition to the CLI, declarative API control using Terraform is also an option. You can find a Terraform module for managing Secrets Engines and their properties here: https://github.com/ICT-technology/terraform-vault-mount/
This module is a dynamic solution for creating and managing multiple Secrets Engines in a single module invocation. It proactively catches API errors, implements best practices for handling Secrets Engines, and supports automated test pipelines using terraform test.
Usage Example
You’ll find a working example in the examples/ subfolder. Set your environment variables $VAULT_ADDR and $VAULT_TOKEN properly, and then you should be able to run it directly from this subfolder – just make sure to execute it in a private development environment and not in a production system.
The module creates the following Secrets Engines:
- kv-v2
- pki
- kubernetes
- ldap
- transit
- aws
After a successful terraform apply, the module outputs a list of mount-accessors for the created Secrets Engines. These mount-accessors can then be used as references in the configuration of other Terraform resources, and also for auditing and dynamic policy assignment.
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 practice, a terraform apply on this example looks like this:
[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]\$
Enabling via the Web Interface
It is also possible to enable Secrets Engines via a web interface. Vault provides an optionally activatable Web UI, which is quite minimal and better suited as a showcase for marketing presentations rather than for administrative use in larger production environments.
We won’t cover the web-based interface at this point – I assume that, as a technically adept and experienced reader, you recognize the importance and necessity of reproducible configuration steps and automation in security-sensitive contexts, rather than relying on mouse clicks. Instead, learn the CLI commands and understand the value of Infrastructure-as-Code, as you will need this in both practical use and certification preparation.
Outlook
In the next deep-dive article on HashiCorp Vault, we will take a first look at the Key/Value Secrets Engine before diving into it in greater depth.
