Secrets Management

Description

You get secrets living in one controlled place, a record of who took which secret and when, secrets that rotate (change) on a schedule, and a leaked secret revoked in one place instead of hunting it across forty repositories.

It matters because of a common scenario: a leaked key in a public repository is one of the most common doorways for an attacker, and the organization usually doesn't even know how many copies of that key exist. A vault turns 'change the key' into a single action.

What people often say

• 'We put them in a vault, we're done' — a secret with admin rights is still dangerous, vault or not; scope it down
• 'Environment variables are good enough' — they leak through logs, process listings, and error dumps

Covers / does not cover

Covers

• Central storage of credentials, keys, and certificates
• Controlled fetching and rotation
• Access logging and revocation

Does not cover

• It doesn't help if the application dumps the secret to logs after fetching it
• It doesn't fix an over-privileged secret (that's IAM's job)
• It doesn't protect a secret an attacker captures from the memory of an already-compromised host

Notes

• A secret isn't protected by hiding it deeper in code, but by moving it out of there. A key you can revoke in one move is worth more than a key whose copies you can't even count.