What is the Secrets Management pattern and how do tools like Vault or AWS Secrets Manager implement it?

The Secrets Management pattern centralises the storage, access control, rotation, and auditing of sensitive credentials — database passwords, API keys, TLS certificates, encryption keys — in a dedicated secrets store rather than hardcoding them in environment variables, config files, or source code. The goal is to ensure that a compromised container image, log file, or configuration repository cannot expose production credentials.

HashiCorp Vault provides several key capabilities:

• Dynamic secrets — instead of storing a long-lived database password, Vault generates a unique, short-TTL (e.g., 1-hour) database credential on demand for each service instance. When the lease expires, Vault revokes it automatically. If credentials leak, they expire quickly — limiting the blast radius.
• Encryption as a Service — services can ask Vault to encrypt/decrypt data without ever holding the encryption key themselves.
• Leasing and renewal — every secret is issued with a lease. Services renew leases before expiry; Vault revokes them if renewal stops (e.g., after a service crash).
• Audit log — every secret access is logged with the requesting entity, timestamp, and secret path.

AWS Secrets Manager provides:

• Automatic rotation of RDS database credentials on a configurable schedule (Lambda-powered).
• IAM-based access control — only services with the correct IAM role can retrieve a secret.
• Cross-account and cross-region replication for disaster recovery.

In Kubernetes, secrets are typically injected at pod creation via a Vault Agent sidecar or the Vault Secrets Operator (CSI provider), making the secret available as an in-memory file or environment variable at runtime — never baked into the container image or stored in etcd in plaintext.