Skip to main content
IAM actions apply to account roles, service accounts, policies, and sessions. Grant them through account policies. Organization accounts, people, groups, and organization policies use Workspace actions.

​
Policy, role and group CRNs use immutable names

Account roles, policies, and service accounts use immutable names in resource CRNs. Workspace groups and organization policies also use immutable names, with their organization UUID in the path:
The empty account slot on a system policy is intentional. It is not an account named platform. Path parameters such as {role_id} remain UUIDs. Trust-policy principal CRNs are a separate use: concrete machine identities are bound to UUIDs so a recreated name does not inherit trust.

​
The actions

The API reference and this table use the service’s authorization actions. none means another authentication mechanism applies, as described below. iam:PassRole is also required when assigning a role to an instance or an instance pool. The role must belong to the target account.

​
Attaching and detaching require both resources

iam:AttachPolicy and iam:DetachPolicy require the same action on both the account policy and target role or service account. A grant covering only policies or only identities is insufficient.
A system policy needs coverage of its own crn:iam:::policy/<Name> CRN too. Each resource check uses that resource’s tags. Boundaries and session policies must permit both checks. Explicit deny on either resource prevents the change. Organization policy attachments use separate Workspace routes and a different dual check: see organization delegation.

​
Listing cannot be narrowed

Top-level lists authorize a collection CRN, such as crn:iam::production:role/*. They do not authorize each returned row separately. An allow on one concrete role CRN therefore does not grant list access. Relationship lists authorize their parent instead, such as a role when listing its account policies. Name and CRN query filters choose rows; they do not change the permission required to list them.

​
Sub-resources are governed by their parent

Inline policy authorization uses the parent identity’s CRN plus /inline-policy/<name>, or /inline-policy/* for its list:
Account boundary operations use crn:iam::production:permission-boundary/<principal-uuid>. Setting a boundary also requires permission to read the selected policy. Workspace user boundaries use their own organization-scoped resource shape. Inline policy and boundary management are sensitive permissions. Someone who can replace a boundary can raise its ceiling; do not include those actions in a delegation intended only to manage policies below a fixed ceiling.

​
Protecting organization delegation

Account administrator permissions do not let someone acquire organization authority indirectly. Sensitive operations on an identity that already has organization grants also require Workspace delegation authority for those grants. These include passing a role, changing its trust, issuing service account credentials, and changing identity boundaries.

​
Sessions and authentication

Account session reads and revocation authorize crn:iam::<account-handle>:sts-session/<session-uuid>. The selected account must own the session. Personal sign-in sessions do not appear in this collection. The revoke endpoint also reads the session for its response, so grant iam:GetSTSSession together with iam:RevokeSession. The public region catalog has no policy action. OAuth token exchange validates credentials, and token revocation validates the supplied session. Web-identity assumption verifies the external identity and target trust; it does not require an existing caller’s iam:AssumeRole permission. Ordinary AssumeRole does.