Secrets Management
Last Updated: May 25, 2026
A secret is any value that grants access or proves trust, such as a database credential, API key, private key, signing key, OAuth client secret, webhook secret, or service token.
Secrets are different from ordinary configuration because exposure usually gives an attacker usable power. A leaked production credential can enable data access, service impersonation, infrastructure changes, or persistence.
This chapter covers how to manage secrets through their full lifecycle, from creation to rotation and incident response.
1. What Counts as a Secret?
Common secrets include:
| Type | Examples | If exposed |
|---|---|---|
| Database credentials | PostgreSQL, MySQL, Redis passwords | Data theft or modification |
| API keys | Stripe, SendGrid, OpenAI, payment gateways | Unauthorized usage or fraud |
| Cloud credentials | AWS access keys, GCP service account keys, Azure credentials | Infrastructure compromise |
| Private keys | TLS keys, SSH keys, code signing keys | Impersonation or unauthorized access |
| Signing secrets | JWT signing keys, webhook secrets | Token forgery or spoofed requests |
| Tokens | OAuth refresh tokens, service tokens, CI/CD tokens | Account or service takeover |
| Encryption keys | Data encryption keys, backup keys | Loss of confidentiality |
Secrets should be treated as bearer power. Anyone who has the value may be able to use it.
That means the design goal is not only secrecy. It is also least privilege, short lifetime, auditability, and fast revocation.