Cloud identity and permissions
Review effective cloud permissions, delegation, workload credentials, and permission-changing actions rather than trusting role names or network location.
The idea
Cloud identities include human accounts, workload identities, roles, and application principals. Permissions should be scoped to necessary resources and operations, with attention to temporary credentials and delegation. Some permissions can indirectly grant broader access by changing policies or assigning roles. Investigate effective access rather than checking only a friendly role name. Audit privileged operations and review unused or excessive permissions.
In practice
A deployment service can update one application but cannot grant itself administrator access or read unrelated customer data.
A common misunderstanding
A role’s name is not proof of its actual permissions, and a workload identity should not inherit unrestricted human-admin rights.
Check your understanding
Why review permission-changing actions carefully?
Think it through: They may let an identity expand its own access or grant persistent access to another principal.
Follow an identity's possible actions
Imagine a fictional academy deployment job updates one application. Its role name is “publisher,” but the underlying policy also allows changing identities and reading unrelated records. The effective permissions determine the risk, not the friendly label.
List the required resources and operations. Include indirect paths such as assuming another role, passing an identity to a workload, or changing a resource policy where the platform supports those behaviors. These can expand authority beyond the most obvious read and write operations.
Workload and human credentials differ
A deployment job should use an appropriate workload identity rather than inheriting a person's permanent administrator credentials. Temporary credentials can reduce some exposure, but their scope and issuance conditions still matter.
Suppose the job's environment is compromised. Ask what the obtained identity can do during its valid period and whether it can create a durable access path. Expiration alone is insufficient if permission-changing actions can establish another credential or principal.
Review usage with policy
Audit records help explain which actions occurred, but absence of recent use does not by itself establish that access is unnecessary or safe to remove. Confirm the workload's purpose and recovery dependencies with its owner.
For the academy, an infrequently used restore identity may be important during an outage. It should remain controlled and tested rather than broadly available or silently deleted because it is quiet.
For a safe exercise, define a publisher that updates one application and reads one build artifact. Add an unnecessary permission to change other roles, then describe the extra impact without exercising it on a real account. Remove the permission and verify the legitimate workflow in a lab. The outcome is a concrete account of effective authority, its lifecycle, and the evidence used to review it.
Keep exploring
References & further reading
Original explanations, with primary references for deeper study.
AWS: Shared Responsibility ModelAWS: IAM security best practices