Skip to main content
RunBook Academy

← All checklists in Secrets, PKI & Certificates

As neededsecret-rotation

Secret Rotation Checklist

23 items ·15 critical ·7 warn ·1 info

How to use this checklist

Open this at the start of a rotation and keep it open until the old credential has been proven dead. It is deliberately shaped as a running gate rather than an audit: some items are decisions taken before anything changes, some are observations made while two credentials are live, and the last few are only answerable once the old value has been withdrawn.

It applies to any credential a consumer presents in order to be believed: a database password, an API token, a cloud access key, a message broker credential, a service account secret. It does not apply to a credential others verify against. A signing key or a certificate authority key needs a trust transition in which the new anchor is distributed first, which is the opposite ordering and belongs in its own procedure.

Where the numbers come from

The consumer list comes from the secret manager metadata and the audit records of who read the path, corrected by hand for the consumers that read it from somewhere else. Lease lifetimes come from the issuer rather than from documentation, because a role carries the expiry the creation statement set for it. The proof that the old value is dead comes from the target system refusing it, not from the revocation tool reporting success.

Several items are judgements rather than measurements. Whether the target supports two live credentials, which order suits the credential shape, and where the point of no return sits are all decisions to be recorded before the change starts. The value of recording them is that the person who takes over halfway through inherits the reasoning rather than guessing at it.

Access this needs

Authority to create and to revoke the credential at its issuer, read access to the secret manager path and its metadata, read access to the audit records for the period, the ability to run a representative query or call as the credential, and read access to infrastructure state and configuration management material. An outside vantage point is needed for the final verification, because the internal health check is exactly the observer that will not notice.

What the review produces

A rotation record carrying the trigger, the consumer list as it stood at the start, the identifier of the new credential, the time the overlap opened, the deadline that was written down, the time the old credential was revoked, and the observed refusal that proves it. Anything unfinished is attached to a person with a date. The record is what an audit reads, and it is what the next rotation starts from.

Sign-off

  • Reviewer: ________________ Date: ___________
  • Platform owner: ___________ Date: ___________
  • Security owner: ___________ Date: ___________

Every critical item must pass. A failing critical item means the rotation is not finished, whatever the change record says, and the old credential must be treated as live until the item passes. Record the date, the reviewer, and the disposition of every item that did not pass.

Critical15 items

  1. bao kv metadata get kv/app/config
  2. psql "postgresql://v-token-app-read@127.0.0.1:5432/appdb" -c "SELECT current_user, now();"
  3. bao read sys/leases/lookup/database/creds/app-readonly
  4. psql "postgresql://v-token-app-read@127.0.0.1:5432/appdb" -c "SELECT 1;"
  5. bao lease lookup database/creds/app-readonly/xoHI541EXoFgKn1OTiusOdd9
  6. terraform state pull | grep -c "password"
  7. curl -sS -o /dev/null -w "%{http_code}\n" https://api.example.com/healthz

Warning7 items

  1. openssl rand -base64 32
  2. grep -RIl "app_db_password" /etc/ansible 2>/dev/null
  3. bao audit list -detailed

Info1 item