>_SecOpsLog_
CoursesVault from dev to productionWhy production Vault exists

Why production Vault exists

Standing secrets, sprawl, and the platform you need.

In short. Most teams do not adopt Vault because they love new infrastructure.

Intermediate25 min · lesson 1 of 13

Most teams do not adopt Vault because they love new infrastructure. They adopt it the week after a long-lived database password shows up in a public gist, or after an AWS access key from a forgotten CI variable starts mining crypto in someone else's account. The failure mode is standing privilege: a credential that works for months, is copied into five places, and has no owner when it needs to die.

A secrets platform is not a prettier password file. It is a system that authenticates callers, authorizes path-by-path access, encrypts data at rest behind a seal, emits an audit trail of every read, and can mint credentials that expire on their own. HashiCorp Vault is one such platform. This course walks from a toy vault server -dev to a production shape you can defend in an outage and in an audit — without pretending Vault is the only tool that can fill that role.

If you already store secrets in a cloud manager or in SOPS, you still need the same mental model: identity in, least privilege out, short lifetime by default. Vault just makes those properties explicit across databases, cloud APIs, and internal PKI in one control plane.

The problem Vault is built to solve

Static secrets sprawl. A Postgres password lands in a .env, then in a Kubernetes Secret, then in a runbook screenshot, then in a laptop backup. Rotation becomes a coordination problem across every consumer. Attribution is worse: when the password leaks, you cannot tell which service used which copy. Dynamic secrets and short-lived tokens shrink that blast radius by making expiry and revocation first-class.

Identity is the second half. Humans should not share a root token. Workloads should not embed long-lived Vault tokens in manifests. Production Vault hangs doors on the cluster: OIDC for people, Kubernetes (or cloud) auth for machines, ACL policies for what each door can open. Without that, you have encrypted storage with a shared skeleton key.

terminal
# Dev server — fine for learning, never for prod
vault server -dev
# note the printed Root Token and Unseal Key, then:
export VAULT_ADDR='http://127.0.0.1:8200'
vault status
output
Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Version         1.17.x
Storage Type    inmem
HA Enabled      false
What a secrets platform must do
1Authenticate
Who is calling — human or workload?
2Authorize
Which paths and capabilities?
3Deliver
Static read, dynamic mint, or issue cert
4Audit & expire
Log the read; kill the lease on schedule
Encryption at rest matters, but identity + TTL + audit are what turn a vault into a platform.

What this course covers — and what it leaves alone

You will build an HA raft cluster, wire TLS and auto-unseal, configure OIDC and Kubernetes auth, write ACL policies, use KV v2 safely, mint dynamic database and cloud credentials, run a short-lived PKI, deliver secrets with AppRole and Vault Agent, turn on audit, rehearse break-glass, and practice snapshots. The advanced course goes deeper on namespaces, replication, Sentinel, and SPIFFE. This track is the production baseline every platform team needs first.

Myths to drop early: "Vault encrypts my Kubernetes Secrets automatically" (it does not unless you integrate it), "dev mode is almost production" (in-memory, unsealed, root printed), and "once it is in Vault it is safe forever" (policies, TTLs, and audit still decide outcomes).

Dev mode is a lab tool
vault server -dev stores data in memory, starts unsealed, and prints a root token. Treat anything you put in it as disposable. The next lessons replace every one of those shortcuts.

Try this

Start a disposable dev server, write a KV secret, read it back, then stop the process and confirm the data is gone. That contrast is the whole reason durable storage and seals exist.

terminal
vault server -dev > /tmp/vault-dev.log 2>&1 &
export VAULT_ADDR=http://127.0.0.1:8200
export VAULT_TOKEN=$(grep 'Root Token' /tmp/vault-dev.log | awk '{print $NF}')
vault kv put secret/demo password=s3cret
vault kv get secret/demo
kill %1
sleep 1
vault status || true
output
====== Data ======
password    s3cret
 
Error checking seal status: ... connection refused
# SUCCESS — demo secret lived only in memory

Takeaway

Production Vault exists to replace standing, copied secrets with authenticated, authorized, audited, expiring access. A password file in a safer box is not the goal.

Next: trade the in-memory toy for a three-node raft cluster and learn what quorum failure actually looks like.

Quick check
01What is the primary risk of standing shared database passwords?
Incorrect — Typing is irrelevant.
Correct — lifetime and copies are the blast radius.
Incorrect — Engines accept long-lived passwords happily.
Incorrect — KV can store static secrets; dynamic is preferred when possible.
02vault server -dev is appropriate for…
Incorrect — Dev mode is in-memory and unsealed.
Correct — never promote -dev to an incident surface.
Incorrect — Auditors want durable audit and seals.
Incorrect — DR needs durable storage and replication design.
Dev server to HA raft

Related

What counts as a secretSecrets management foundationsThe secrets threat model & secret-zeroAdvanced secrets managementHashiCorp Vault cheat sheetCheat sheetVault & secrets interview questionsInterview prep