Identity
Part of Cloud identity and access
Designing roles with the minimum required permissions
Build cloud roles from required tasks, resource scope and duration, then check the grant and its holder's other access.
Start with a defined task when designing a cloud role. List required actions, resources and the environment where the task runs. Choose a grant that covers that work, then check its scope and the holder's other access before approving it.
Write a role brief
Name the task, its owner, the intended person or workload and when access should end or be reviewed. Separate reading, changing, deleting and managing permissions. For an illustrative report exporter, reading approved data and writing to one destination might be required; changing identity settings would need its own justification. The actual service permissions depend on the data path.
Include what must remain unavailable. A person able to assign roles may be able to expand access, so permission management deserves explicit review. Check group membership, inherited assignments and other roles: adding one narrow role does not restrict broader access the identity already has.
Question / Record in the role brief
- What must the holder do?
- Required actions and a representative task
- Where may it happen?
- Named resources and environment
- Who receives the grant?
- Identity and accountable owner
- For how long?
- End date or review trigger
- What should remain unavailable?
- Unrelated or sensitive actions to check
Set the workable resource scope
Apply the grant where the task occurs. In Azure RBAC, a role assignment has a principal, a role and a scope. The scope can be a specific resource, a resource group or a subscription.
Choose the smallest scope that covers the task. For example, access to a single storage account can be assigned at that resource rather than across a subscription.
For other providers, inspect the actions, resources and conditions their policy model supports. Check whether an existing role fits before maintaining a custom role. If a broad grant is temporarily needed while discovering the task, give the exception an owner and review date.
Cloud Provider Role Scope Options
- Azure RBAC
- Scope can be resource, resource group, or subscription.
- AWS IAM
- Policy actions tied to specific resources, conditions, and service-specific permissions.
- Google Cloud IAM
- Role recommendations based on usage over last 90 days (or since grant).
Treat activity as a clue
AWS IAM Access Analyzer can generate a policy candidate from CloudTrail activity. AWS says action-level detail is available for some services and a generated policy may need further actions and resource identifiers. Google Cloud's IAM role recommendations compare permissions with usage over the last 90 days, or the shorter period since a role was granted. Neither view proves that an infrequent job or recovery action is unnecessary.
Compare a proposed reduction with scheduled work, exceptional procedures and the owner's account of the task. Review the resulting policy before use.
Check the grant and maintain it
Use policy inspection and a controlled representative task to check required access. Assess unrelated sensitive actions with the provider's policy tools or safe checks appropriate to the environment; do not exercise a destructive action merely to see whether it is denied. If the task fails, identify the action and resource involved before widening the grant.
Record the role's purpose, scope, owner and any temporary exception. Revisit it when the task, application or holder's duties change.
