Secrets Management
Practice this topic in a realistic system design interview
A leaked cloud access key can do a lot of damage quickly.
If it appears in a public repo or log, automated scanners can find it within minutes. Once someone has the key, they may be able to read data, call APIs, spend money, or take over the connected service.
That is why secrets are different from normal configuration. API keys, database passwords, private keys, signing keys, and service tokens give access to something important. In many systems, just having the value is enough to use it.
This chapter explains how to manage secrets from the day they are created to the day they are rotated, revoked, or cleaned up after an incident.
1. What Counts as a Secret?
Common secrets include:
| Type | Examples | If exposed |
|---|---|---|
| Database credentials | PostgreSQL, MySQL, Redis passwords | Data can be stolen or changed |
| API keys | Stripe, SendGrid, OpenAI, payment gateways | Someone can use the API as you |
| Cloud credentials | AWS access keys, GCP service account keys, Azure credentials | Cloud resources can be abused or taken over |
| Private keys | TLS keys, SSH keys, code signing keys | Someone can pretend to be you or your service |
| 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 | Encrypted data may be exposed |
Treat secrets like keys. Anyone who has the value may be able to use it.
The design goal is not just "keep it hidden." Good secrets management also means least privilege, short lifetime, clear audit logs, and fast shutoff when something leaks.