What My Vault Platform Actually Looks Like Now
This is the short version of the current state.
Repo:
The Core Shape
The platform is built around a few hard boundaries:
- an offline root CA outside Vault,
- a separate Vault environment for
testandprod, - HTTPS + mTLS on the Vault API,
- one Unix user per app or proxy,
- one Vault identity per app or proxy,
- and Vault Agents that do the repetitive certificate and secret work.
The Environment Split
test and prod are not just labels.
They differ in address, trust material, runtime owner, mounts, and app-facing paths.
That means “test” and “prod” are separated in the mechanics of the system, not just in naming.
How Identities Work
The strongest part of the design is probably the identity model.
Instead of broad shared service credentials, the repo documents a narrower flow:
- one app or proxy gets its own Unix user,
- that identity gets its own certificate-auth mapping,
- that mapping gets a small policy set,
- and the agent only renders what that identity actually needs.
So a proxy does proxy work. An app does app work. Neither should quietly inherit broad Vault power just because it exists on the same machine.
What Agents Do
Agents are doing different jobs depending on the component:
- app agents can render leaf certs and secret material,
- proxy agents keep CA chains current for upstream verification,
- container secret consumers can use AppRole-backed secret rendering.
That split is important because not every component needs the same type of identity or the same type of output.
What Still Needs Work
The current repo also admits the unfinished parts, which I think is the honest and useful way to document a system.
The hardening backlog still includes:
- backup and restore procedures,
- a clearer disaster recovery runbook,
- rotation cadence for root and intermediates,
- monitoring and alerting,
- tighter handling of debug or temporary access paths,
- and optional auto-unseal work if I want to accept the Azure dependency.
That is the difference between “it works” and “it is fully mature.”
Why I Like The Current State
What I like now is that the setup has stopped being abstract.
It has:
- a clear repo,
- a clear naming model,
- a clearer trust model,
- and a better relationship between documentation and operations.
That is enough structure to keep growing without rebuilding the whole mental model every week.