Practice this topic in a realistic system design interview
Almost every application depends on credentials to talk to other systems.
It needs a database password to connect to the database. It needs an API key to call a payment provider. It may need a private key for TLS, a token for a message queue, or a signing key for session tokens.
Each of these is a secret. If someone else gets one, they can act as your application. For example, if an attacker gets your payment provider's API key, they may be able to issue refunds or read customer payment data.
So secrets need to be stored, delivered, and used in a way that keeps them out of the wrong hands. That is what secrets management is about.
In this chapter, we will look at what secrets management is, the common ways secrets leak, how secrets managers deliver credentials to applications, and how to rotate secrets without causing downtime.
A secret is any value that grants access to a system or data. Unlike normal configuration, just having the value is often enough to use it.
| 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, message queue tokens, CI/CD tokens | Account or service takeover |
| Encryption keys | Data encryption keys, backup keys | Encrypted data may be exposed |
Good secrets management is not just "keep it hidden." It answers four questions for every secret:
But before looking at the solution, let's look at how secrets usually leak.