Skip to main content
In this lesson, you’ll learn how to build a production-ready Vault server setup. We’ll walk through:
  • Launching Vault and managing its configuration files
  • Enabling and tuning Secrets Engines
  • Auto-unseal and Integrated Storage
  • Configuring authentication methods
  • Secure initialization, root token regeneration, and key rotation
The image is an objective overview for creating a working Vault server configuration, listing tasks such as enabling secret engines, practicing production hardening, and configuring authentication methods. It includes a certification badge and a cartoon character illustration.
Each of these steps is essential for a resilient, compliant Vault deployment. Let’s start by enabling and configuring the Secrets Engines.

​
Available Secrets Engines

Vault supports a wide range of Secrets Engines for cloud providers, directories, databases, and more. While Vault can integrate with AWS, Azure, GCP, Active Directory, and others, our focus will be on the core, cross-platform engines:
The image lists various "Available Secrets Engines" such as Active Directory, AWS, Google Cloud, and more, with a Vault certification badge in the corner.

​
Generic Secrets Engine Features

Vault’s generic engines share powerful capabilities:
  • Database Secrets Engine
    Manage credentials for MySQL, PostgreSQL, Oracle, and more via a single plugin-based engine.
  • Key/Value (KV) Secrets Engine
    KV v2 adds versioning and metadata on top of the simple key/value store.
  • PKI Secrets Engine
    Issue and revoke X.509 certificates with customizable roles, CA certs, and TTLs.
  • Transit Secrets Engine
    Encrypt/decrypt data without storing it, and integrate with Auto Unseal systems.
  • Cubbyhole & Identity Engines
    Enabled by default; provide per-token isolated storage and an identity backend.
The image is a slide about "Generic Secrets Engines," detailing features like database support, Key/Value versions, PKI certificates, and data encryption with Transit. It includes a Vault certification badge and a cartoon character.

​
Enabling Secrets Engines

By default, cubbyhole/ and identity/ are mounted. All other engines must be enabled at a unique mount path.
Vault’s cubbyhole/ and identity/ engines are mounted by default and cannot be disabled.
You interact with each engine via its mount path:
  • Default mount: use the engine type (e.g., aws/, kv/).
  • Custom mount: choose any path (e.g., team1-db/).
The image is a slide about enabling secrets engines, explaining that Cubbyhole and Identity are enabled by default, while others must be enabled using CLI, API, or UI. It also mentions that secrets engines are isolated at unique paths, which do not need to match the engine's name or type.

​
CLI: vault secrets

Vault’s primary CLI for secrets engines:
For detailed output (including KV version), use:
Always choose a unique mount path to prevent conflicts when enabling multiple secrets engines.

​
Custom Path & Description

You can customize both the mount path and its metadata:
  • -path="cloud-kv": custom mount point
  • -description="Team A Key/Value Store": shown in vault secrets list
  • kv-v2: engine type (Key/Value version 2)

​
Example: Listing Secrets Engines

Note: KV engines always show as kv in vault secrets list; the version is visible with -detailed.*

​
Enabling via UI

In the Vault UI, go to Secrets → Enable new engine. Select the engine type, configure options, and mount it—all in one guided flow.
The image is a user interface screenshot showing a list of enabled secrets engines, with an option to enable additional ones. It includes labels and annotations for clarity, and features a cartoon character at the bottom right.
With your Secrets Engines enabled and tuned, you’re now prepared to dive into the Key/Value Secrets Engine details—exploring data versioning, access control, and best practices.

​
References

Watch Video