Secrets Management

A secret is anything that grants access if it leaks: a database password, an API key, a signing key. How a team handles them says a lot about how seriously they take security in general.

Why secrets in code are a permanent leak

Committing a secret to git doesn't just expose it today - it's in the history forever, even after you delete it in a later commit, unless you rewrite history entirely (which is its own disruptive operation). Anyone who ever clones the repository, or had access at any point, has that secret. The only real fix once a secret is committed is to treat it as compromised and rotate it.

The minimum bar: .gitignore

.env
*.pem
secrets.yaml

Keeping real secrets in a local, untracked file (commonly .env), and listing that file in .gitignore, is the minimum - it stops the accidental commit. It's not a complete solution on its own: the file still sits in plain text on disk, readable by anything else running on that machine.

The real fix: a secrets manager

Tools like HashiCorp Vault, or a cloud provider's native secrets service, go further:

• Secrets are stored encrypted, not in plain text anywhere.
• Access is logged - you can see exactly what read a given secret, and when.
• Secrets can be fetched at runtime instead of baked into a config file at all.

Rotation

Even a well-managed secret should be rotated periodically - replaced with a new value on a schedule, or immediately if there's any suspicion it leaked. A secret that's valid forever is a single point of failure that never expires; rotation puts a ceiling on how long a leaked credential actually stays useful to whoever has it.

Try it

cat .gitignore

When you're ready, hit Mark complete and move to the next lesson.