Module 77: Encryption and Secrets
Rotation
🏠The everyday picture
When an employee leaves, or a key goes missing, a careful office changes the locks. A very careful office also changes them on a schedule, so a copy made long ago no longer works.
📘What it really is
- Rotation means replacing a secret or key with a new one and retiring the old. Do it:
- immediately after a suspected leak, or when someone with access leaves;
- on a schedule for long-lived secrets (for example, every 90 days or yearly, by sensitivity);
-
automatically where the platform supports it (managed database passwords, cloud keys, certificates via Let's Encrypt).
-
Zero-downtime rotation:
- create the new secret while the old still works;
- update the app to use the new one and deploy;
- confirm everything works;
-
revoke the old one. For signing keys, accept both old and new for a short overlap (verify with either, sign with the new).
-
Make rotation easy by design: secrets read from configuration, never hard-coded; one place to change each; a written runbook per secret.
-
Short-lived credentials avoid rotation problems altogether: cloud roles, GitHub Actions' OIDC tokens for cloud deploys, temporary database credentials. Prefer them where available.
-
Keep an inventory (Lesson 3's list) with the last rotation date and owner for each secret.
🖱️Try it
Rotate your CRM's database password on staging without downtime: create the new password, update the env file or secret, redeploy, confirm, then remove the old one. Time it, and write the runbook in your operations guide. Add the last-rotated date to your key and secret inventory.
✅Quick check
In what order do you rotate a secret without downtime?
Show the answer
Create the new one, switch the app to it, confirm it works, then revoke the old one.
Why are short-lived credentials attractive?
Show the answer
They expire on their own, so a leaked one is useful only briefly, and there's less to rotate by hand.