Why keys leak
Access keys end up in places they should not be: committed to a repository, pasted into a chat, baked into a container image, left in a shell history file. Unlike a password, a key is designed to be used by software, so it gets copied into configuration and then forgotten.
Automated scanners watch public repositories for exactly this. A key committed to a public repository can be found and used within minutes.
Rotate without downtime
The safe pattern is overlap rather than replacement. Most providers allow two active keys on an identity at once, which is what makes this possible.
- Create a second key alongside the existing one.
- Deploy the new key to everything that uses it.
- Watch the last-used timestamp on the old key until it stops moving.
- Deactivate the old key, but do not delete it yet.
- Wait long enough to be confident nothing broke, then delete it.
The deactivate-before-delete step matters. If something you forgot was using the old key, deactivating is instantly reversible while you fix it.
Find every place the key is used
The last-used timestamp tells you whether a key is in use but not by what. Before rotating, search for the places keys tend to hide.
- CI and deployment pipeline secrets
- Environment variables in container and function configuration
- Configuration files on servers, including ones under version control
- Third-party services granted access to your account
- Local developer machines
Better: stop using long-lived keys
Rotation manages a risk that can often be removed. Every major provider supports short-lived credentials issued to a workload at runtime, so no static secret exists to leak.
Attaching a role to a virtual machine, using workload identity for containers, or federating a CI system are all versions of the same idea: the credential lives for minutes and cannot be reused if it escapes.
Where that is possible, it is a much better answer than rotating a permanent key on a schedule.
If a key is exposed
- Deactivate the key immediately. Do not wait to work out whether it was used.
- Issue a replacement and deploy it.
- Read the audit log for the period the key was exposed, looking for calls you cannot account for.
- Check for resources you did not create, particularly compute in regions you do not use, which is the usual signature of a key being used for mining.
- Remove the key from wherever it leaked, including repository history, which requires rewriting history rather than a new commit.
Related cloud accounts
This guide applies across providers. The cloud account catalogue lists every platform with its configurations and prices, and the comparison table puts them side by side.
Further reading
- AWS vs Azure: Which Cloud Account Should You Buy?
- Azure Accounts: What You Get and How to Choose a Configuration
- How to Choose a Cloud Provider Without Overthinking It
- Oracle Cloud Accounts: What You Get and How to Choose a Configuration
Frequently asked questions
If you must use long-lived keys, a quarterly review is a reasonable baseline. The better goal is to replace them with short-lived credentials so rotation is unnecessary.
On most providers, yes, and that overlap is what allows rotation without downtime.
Deactivate it first, then review the audit log for the exposure window. Removing the key stops future use but tells you nothing about what already happened.
