Section Overview Create a Working Vault Server Config

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

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:

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.

Enabling Secrets Engines

By default, cubbyhole/ and identity/ are mounted. All other engines must be enabled at a unique mount path.

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

CLI: vault secrets

Vault’s primary CLI for secrets engines:

$ vault secrets enable aws
Success! Enabled the aws secrets engine at: aws/

$ vault secrets tune -default-lease-ttl=72h pki/
Success! Tuned the pki secrets engine at: pki/

$ vault secrets disable aws/
Success! Disabled the secrets engine at: aws/

$ vault secrets list
Path        Type        Accessor         Description
----        ----        --------         -----------
cubbyhole/  cubbyhole   cubbyhole_...    per-token private secret storage
identity/   identity    identity_...     identity store
pki/        pki         pki_...          n/a

For detailed output (including KV version), use:

$ vault secrets list -detailed

Custom Path & Description

You can customize both the mount path and its metadata:

$ vault secrets enable \
    -path="cloud-kv" \
    -description="Team A Key/Value Store" \
    kv-v2

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

$ vault secrets list
Path            Type        Accessor            Description
----            ----        --------            -----------
aws/            aws         aws_dafa7adc        n/a
cloud-kv/       kv          kv_fa270a3f         Team A Key/Value Store
cubbyhole/      cubbyhole   cubbyhole_88c8e2e3  per-token private secret storage
identity/       identity    identity_e60e93cb   identity store
pki/            pki         pki_123456ab        n/a
transit/        transit     transit_7b8038ca    n/a

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.

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

• Vault CLI Commands
• Vault Concepts
• HashiCorp Vault Documentation