Pick a pattern
Both patterns need a credential with
keys_write, and listing keys needs keys_read. In the examples on this page, OPENTYPE_API_KEY holds that management key, not the runtime key you are replacing. Only the key’s id goes in a URL; the secret never does.
Overlap: rotate without downtime
1
Find the key you are replacing
List your keys and note the
id, name and scopes of the one to replace. secret_prefix (the first 13 characters of the secret) tells you which deployment holds it.2
Create the replacement
Create a new key with the scopes the service needs. You can only grant scopes you hold yourself. The response is the only time the secret is shown.
3
Store it and deploy
Write the
secret into your secret store and roll it out to every instance of the service.4
Confirm the old key is idle
Read the old key and check that
last_used_at has stopped moving. It is updated in the background, about once a minute at most, so wait a few minutes after the last instance restarts.5
Revoke the old key
DELETE /v1/keys/{key_id} with the old id. The old secret stops authenticating on its next request. The row stays listed with state: "revoked" for audit.Rotate in place: when a secret leaks
POST /v1/keys/{key_id}/rotate issues a new secret for the same key. The id, name and scopes stay the same. The old secret stops working at once, so every caller still holding it gets 401 invalid_credential until it has the new one. That is what you want when a secret has leaked.
secret, returned with 200. secret_prefix changes to match the new secret. No field records the rotation time.
After a leak
- Rotate the key, or revoke it if nothing legitimate uses it.
- Deploy the new secret to the callers that should have it.
- Read usage reporting for the window of the exposure and check for runs you do not recognize.
What the old secret does after each action
A revoked key cannot be rotated or re-enabled. To replace it, create a new key.
Errors
Plan it
- Give every environment and service its own key, so rotating one never touches the others. Name keys after the process that holds them.
- Keep a management key apart from runtime keys. A runtime key needs
runs_writeandruns_read; only the key that performs rotation needskeys_readandkeys_write. - Rotate on a schedule you choose, since keys never expire, and after anyone with access to a secret leaves.
- Revoke keys that stop being used.
last_used_atshows which ones.
Related
- API key security - how secrets are stored and why they are shown once.
- API keys in the console - create and revoke keys without code.
- Scopes and roles - choose the smallest scope set for each key.
- key_revoked - the reference entry for rotating a revoked key.
- Production checklist - where a rotation plan fits in going live.