Infrastructure, cloud & DevOps · Advanced

Managing secrets and keys

In one line: A secret in the code repository is a leaked secret — even if the repo is private, and even if you deleted it afterward.

Where to store them

In a managed secret store that injects values at runtime, with permissions per service and per environment, and with access logging. Environment variables are a transport mechanism, not a storage place.

Periodic rotation

Every secret needs a rotation process you can run in minutes. It's needed when an employee leaves, on a suspected leak, and routinely. If rotation requires downtime, it won't be done when needed.

Support two active keys in parallel briefly, so rotation is smooth.

Prevent a leak in advance

A secret scanner in the build process and a hook before saving a change, so a secret is blocked before it enters the history. If it already entered — assume it leaked, rotate immediately, and only then clean the history.

Going deeper

Separate secrets by environment absolutely. A production key accessible from a development environment negates the meaning of separation, and it's how most internal leaks happen — not maliciously, but through a script pointed at the wrong address by mistake.