Secrets Management: A Practical HashiCorp Vault Guide

Secrets Management: A Practical HashiCorp Vault Guide

On many sites, database passwords and API keys are written directly into .env or config files. Once the repository, a backup, or a developer's laptop is leaked, the entire credential set leaks with it. HashiCorp Vault centralizes secrets in one place, uses unified policies to control who can read them and when they expire, and can generate temporary credentials on demand. For application-side environment variable management, see Environment Variables and Configuration Management; this article focuses on Vault itself.

Core concepts: secrets engines and paths

Secrets in Vault are managed by "secrets engines", each mounted at a path (such as kv/ or database/). They behave like a virtual file system, supporting read, write, and delete.

• KV engine: stores static secrets (API keys, passwords) encrypted; good for migrating existing data.
• Dynamic engines: generate credentials on demand by connecting to external systems (database accounts, cloud AK/SK); they expire when no longer needed.
• Encryption as a service: provides data encryption/decryption APIs so applications do not manage keys themselves.

Engines are isolated by a barrier view, so even if one engine is compromised it cannot read data from other engines.

Take the most common KV v2 engine: day-to-day reads and writes are just a few commands.

vault kv put secret/api app_key=xxxxx \
  app_secret=yyyyy
vault kv get secret/api
vault kv metadata get secret/api        # view versions and update times
vault kv rollback secret/api 1          # roll back after a bad write

KV v2 ships with versioning: every put creates a new version, and reading or rolling back old versions is trivial — far more reliable than hand-editing text in config files. To get a feel for Vault, migrate one or two real secrets into KV v2 first and experience the difference of "centralized storage + version rollback"; it teaches more than ten pages of docs.

Dynamic credentials and short-lived leases

Dynamic credentials are Vault's most valuable capability:

vault read database/creds/my-role

Each call returns a one-time database account whose lease expires automatically, naturally solving the "passwords unchanged for months" problem. Combined with TTLs and lease renewal, you can shrink credential lifetimes from months to minutes or hours.

When configuring the database dynamic engine, you first define connections and roles: a connection tells Vault how to reach PostgreSQL/MySQL, and a role declares the permissions, default TTL, and max TTL for each issued account. For example, a read-only role could set default_ttl=1h and max_ttl=24h, so an application can use the account for at most 24 hours before it is revoked automatically. Compared with manually rotating passwords weekly, this shrinks credential lifetimes to hours, so even if an attacker grabs an account, the exposure window stays tiny.

Key rotation and integration patterns

• Rotation: update static keys periodically with vault kv put and sync downstream; dynamic keys rotate automatically by tuning role TTLs.
• Injection: applications fetch secrets through Vault Agent, a Kubernetes Sidecar, or the API, avoiding secrets in images and logs.
• Policy: use ACL policies to limit "who can read which path", applying least privilege to every application and person.
• Auditing: Vault ships audit logs, integrated with Security Log Auditing to record every read.

Deployment and High Availability

In production, run Vault in high-availability mode with Consul or Raft as the underlying storage so a single node failure cannot leave applications unable to fetch credentials. Initialize Vault on first start and store the unseal keys safely, and use Auto Unseal to reduce operational burden. Protect Vault communication with TLS, restrict which sources can reach the management port, and archive audit logs separately.

Common Mistakes

• Treating Vault as just an "encrypted config file" while still hard-coding static keys in images and code;
• Ignoring the lease mechanism, leaving dynamic credentials without a sensible TTL;
• Policies that are too broad, letting one permission read every path;
• Skipping rotation and recovery drills, only to find the process does not work when you actually need it.

Working with the Wider Security Stack

Vault is the hub that consolidates credentials. Together with SSH hardening, data encryption, and security log auditing, it makes "who read which secret and when" fully traceable.

Plaintext Config vs. Vault: How to Judge the Cost

For a solo site, the left column is acceptable; once the team grows past three or four people, secrets number in the dozens, or compliance such as SOC 2 applies, Vault's "centralized + auditable" advantage becomes obvious. A typical rotation case: after a database password leaks, the traditional approach means editing config, restarting services, and possibly missing a replica; with a dynamic engine, you just tune the role and reissue credentials — every replica's old credentials die at once and the bleeding stops within 5 minutes.

Start Path

Introducing Vault does not have to be all-at-once: first deploy a single node in development and enable the KV engine to migrate database passwords and API keys in; then connect one dynamic engine to validate the lease mechanism; then use Vault Agent for one application's secret injection; finally round out policies, auditing, and rotation. Each step delivers immediate security value without overloading the team at once.

16IDC Observation

Vault suits environments with many secrets, multiple team members, or compliance requirements. Small single-server sites can start with "host sensitive fields separately plus rotate regularly". Key management should work together with SSH Hardening and database encryption to form a unified credential control system. Browse more approaches back in the Security Hardening category.

References: https://developer.hashicorp.com/vault/docs/secrets, https://developer.hashicorp.com/vault/docs/database, https://developer.hashicorp.com/vault/docs/agent

Source: https://developer.hashicorp.com/vault/docs/secrets