Secrets Management

Applications need secrets — database passwords, API keys, signing keys, TLS certificates — and where those secrets live decides how bad a code leak or a stolen laptop turns out to be. A secrets manager stores them centrally, hands them out on authenticated request, rotates them, and audits access, replacing the anti-pattern of secrets in code, config files, and environment variables.

This topic builds Meridian's secret-handling and connects it to mutual TLS between its services — the endgame where app and api authenticate each other cryptographically instead of trusting the network.

Why Not Env Vars and Config Files

Secrets in a .env file, baked into an image, or committed to git are the single most common credential leak. They get copied, printed to logs, captured in crash dumps, and pushed to repositories — and they do not rotate. Committing a secret once and deleting it later does not help: it is in the git history forever, so the only fix is to rotate it. A real secret store removes secrets from all those leaky places.

What a Secrets Manager Does

A secrets manager provides central encrypted storage, authenticated and authorized access per service, automatic rotation, and an audit log of who read what and when. The application fetches a secret at runtime instead of carrying it, so the secret never lives in the code or the image — and access can be scoped so one service's compromise does not expose every other service's secrets.

Dynamic, Short-Lived Secrets

The strongest pattern is short-lived, on-demand credentials: a database password minted for this service for the next hour, then automatically expired. A secret that is valid for an hour is nearly worthless the moment after it leaks, which collapses the window an attacker has to use a stolen credential. Dynamic secrets turn credential theft from a lasting problem into a fleeting one.

Envelope Encryption and mTLS Identity

A key-management service holds master keys that never leave it and wraps the data keys applications use — envelope encryption, the model behind cloud encryption and Chapter 2's key-handling advice. The same idea gives services cryptographic identity: with mutual TLS, app and api each present a short-lived certificate and authenticate each other, so a service is trusted for who it cryptographically is, not for where on the network it sits.