Inventory identities by reachable consequence
Assign a cloud account owner and a separate reviewer for privileged access. List organization and account administrators, federated roles, workload identities, long-lived keys and emergency accounts. Record which identities can read secrets, impersonate another role, alter logging or change resource policies. A seemingly narrow deployment role may still escalate through the permissions it can attach or the code it can replace.
For each secret, track the service it authenticates to, its consumers, owner, storage locations and revocation method. Include development environments, build jobs, notebooks, local configuration and third-party integrations. Keep secret values out of the inventory document. The purpose is to answer where a credential can be used and what breaks when it is replaced, without creating another secret dump.
Prefer temporary identity and specific resource access
AWS’s IAM guidance recommends federation for people, roles for workloads, least privilege and removal of unused access. Apply those principles with a tested mapping between job and role. Separate production from development authority, constrain cross-account trust and investigate broad resource policies. Use policy-analysis tools as evidence, while checking actual application behavior before removing permissions relied on by a critical path.
Secrets Manager guidance covers access restriction, rotation, monitoring and safe retrieval. Our operating procedure is to retrieve only the specific secret a workload requires, avoid exporting an entire vault into its environment and prevent the value from entering process diagnostics or logs. Distinguish permission to administer a secret from permission to retrieve its plaintext and from permission to decrypt an associated key.
Rotate through consumers and invalidate the old path
Before a planned rotation, identify every consumer and its reload behavior. Some processes read a credential only at startup, while others cache it. Stage the replacement according to the service’s supported procedure, deploy consumers and confirm successful authentication. Then invalidate the previous credential and verify that an authorized controlled check using the old credential is denied without printing it.
During suspected compromise, prioritize containment by the credential’s reachable impact. Preserve relevant audit events, revoke sessions and keys as supported, and inspect actions performed before revocation. Expiring an access key does not necessarily undo resources, roles, application credentials or persistence created with it. Review changes to trust policies, logging, network exposure and workload images as part of recovery.
Test emergency access and failure behavior
Exercise a designated non-production workload through secret rotation and simulated identity-provider unavailability. Confirm that the emergency account can perform the agreed limited recovery tasks and that its use produces an independent alert. Protect its recovery material separately; an emergency account that everyone uses routinely is an undocumented standing privilege rather than a recovery mechanism.
Review unused roles and keys with service owners before removal, then record evidence that the obsolete paths no longer work. Set an expiration for temporary exceptions and verify it. The procedure is complete when a replacement credential works, the old credential fails, audit events are retained and a backup operator can recover the service without opening broad permanent access.
Controls to take away
- A secret manager does not fix excessive retrieval permissions.
- Revocation must include authority created before the credential was disabled.
- Test the application reload behavior during secret rotation.
Take this to your next review
Working checklist
Use this as a starting point, then assign owners and record evidence in your team's own system. Checks here reset when you leave or reload this note.
0 of 5 reviewed
Sources & further reading
The references below support this note. Adapt the procedures to your systems, access model and recovery requirements.
A correction or a better primary source? Send Raiders the article URL and evidence. Editorial policy.