AS-301c · Module 1

Vault Design Patterns

4 min read

A secrets vault is a centralized, access-controlled, audited storage system for credentials. HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and Google Secret Manager are the major implementations. The specific product matters less than the architectural properties: every secret has an access policy, every access is logged, every credential has an automated lifecycle, and no secret is accessible without authentication and authorization.

  1. Dynamic Secrets The most powerful vault pattern is dynamic secrets — credentials generated on demand for a specific agent, with a defined TTL, that are automatically revoked when the TTL expires. An agent that needs database access does not receive a static password. It receives a dynamically generated credential that works for 30 minutes and then ceases to exist. No rotation required because the secret is never reused.
  2. Secret Engines Vaults organize secrets by engine — database engines, cloud provider engines, PKI engines, key-value engines. Each engine understands the lifecycle of its secret type. The database engine can generate credentials and revoke them. The PKI engine can issue and revoke certificates. Engine specialization means the vault handles lifecycle management, not your application code.
  3. Access Policies Every agent identity maps to a vault policy that defines which secrets it can access, under what conditions, and for how long. Policies follow least privilege — an agent gets access to the specific secrets it needs for its current role. Policy changes are version-controlled, reviewed, and audited. A policy change is a security event.

Do This

  • Use dynamic secrets wherever possible — credentials that expire automatically eliminate rotation burden and sprawl risk
  • Map vault policies to agent identities, not to teams or environments — granular policies reduce blast radius
  • Audit vault access logs weekly for anomalous access patterns — a secret accessed by an unexpected identity is an investigation

Avoid This

  • Store static secrets in the vault and consider the problem solved — static secrets still need rotation even in a vault
  • Create broad vault policies that give multiple agents access to the same secrets — shared access defeats the purpose of centralization
  • Ignore vault access logs — the audit trail is the proof that your secrets management is working