No More Hardcoded Secrets

Current implementation:

I don’t want:

  • app containers with static DB passwords baked in,
  • environment variables full of long-lived credentials,
  • or “secret.yaml” files committed by accident.

My goal is:

  • short-lived secrets,
  • delivered via Vault Agents,
  • rendered into files through templates or mounted as volumes.

The Pattern I’m Aiming For

Per app or service:

  1. A Vault Agent runs as a sidecar or companion container.
  2. It authenticates to Vault (e.g. via mTLS and a constrained role).
  3. It fetches secrets and renders them into files using templates.
  4. The main app container reads these files at startup or on reload.

So instead of:

DB_PASSWORD=my-super-secret

in environment variables, I want:

/app/secrets/db_password

generated by Vault Agent, valid for a limited time.

What Changed In Practice

This is no longer just an idea. The pattern now exists in the repo in a more operational form:

  • infra/bootstrap-secret-agent.sh
  • infra/setup-vault-agent-mtls-client-config.sh
  • infra/setup-vault-agent-app-config.sh
  • infra/setup-vault-agent-proxy-config.sh

The split matters:

  • container-style secret consumers can use AppRole and rendered secret files,
  • host-level agents can use mTLS plus scoped PKI issuance,
  • proxy agents do not need leaf certs for apps; they keep CA chains current for upstream validation and reload proxies after updates.

The config source for this is the environment/app matrix in:

Why This Fits My VPS

Even on a single VPS:

  • I can run agents per service user.
  • Agents talk to Vault with mTLS and scoped policies.
  • I get closer to the patterns used in larger infrastructures, while still keeping it small and understandable.

The practical benefit is that the secret flow is now tied to Unix-user boundaries and repeatable setup scripts instead of one-off manual setup.