Stackbook Logo
security-complianceestablished · medium operational burden

Centralized Secrets Management

Also known as: vault-pattern, secret-store

Intent

Keep credentials out of code and config, issue them on demand with strong identity, and rotate them automatically.

Problem

Passwords, API keys and certificates end up in repositories, images and environment files where they leak and never rotate. Revoking a leaked secret requires redeploying everything that embeds it.

Forces

  • •Workloads need credentials at start-up
  • •Leaks must be containable quickly
  • •Access must be auditable per secret
  • •Applications should not manage cryptography themselves

Solution

Overview

Secrets management replaces static credentials in files with runtime retrieval governed by identity and policy. The best secret is one that does not exist: use workload identity or short-lived tokens where the platform supports it.

Roll this out by inventorying existing secrets first, then migrating the most sensitive ones, such as production database and signing credentials. Run secret scanning in CI and on repositories continuously, and practice rotating each secret type so that a real leak becomes a routine procedure rather than an emergency.

How it works

Pod starts -> presents service account JWT
Vault verifies with Kubernetes API -> returns token (TTL 15m, policy: payments-ro)
App -> GET secret/data/payments/db  (token)
Vault -> mints DB user app-7f3a, TTL 1h   # dynamic secret
App uses credentials; lease expires -> Vault revokes the DB user
Audit log: who, which path, when

Static secrets are versioned, and consumers pick up new versions by re-fetching on a schedule or via a sidecar agent that renders files.

Pitfalls

  • Committing secrets to git. Add pre-commit scanners and rotate anything that leaked, since history is permanent.
  • Passing secrets as environment variables that appear in process listings or logs.
  • One shared secret path for all services.
  • No tested restore of the secret store.
  • Caching secrets on disk without encryption.
  • Forgetting break-glass procedures for outages.

Key takeaways

  • Authenticate workloads by platform identity, not stored bootstrap secrets.
  • Prefer dynamic, short-lived credentials over static ones.
  • Scope policies per service and audit every access.
  • Treat the secret store as tier-zero infrastructure with backups and failover.

✓ When to Use

  • •Any system with database, API or signing credentials
  • •Multiple services and environments
  • •Compliance regimes demanding rotation and audit

✗ When Not to Use

  • •Throwaway prototypes with no real data
  • •Public configuration values that are not secret
  • •When a managed identity can remove the secret entirely

Pros

  • +Single audited source of truth
  • +Rotation and revocation without redeploys
  • +Dynamic credentials shrink the leak window

Cons

  • −Secret manager becomes critical infrastructure
  • −Bootstrap identity must be solved
  • −Added start-up latency and dependency

Cost Profile

Infrastructure

Medium — HA secret store

Operational

Medium — unseal, backup, policy upkeep

Cognitive

Medium

Failure Modes

  • Secret store outage prevents workloads from starting

  • Secrets logged or exposed in crash dumps

  • Overbroad policies let one service read all secrets

Real-World Examples

Alternatives

    Related Patterns

      Competency Domains

      security compliancereliability ops