> ## Documentation Index > Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt > Use this file to discover all available pages before exploring further. # IAM permissions > Account IAM actions, resource names, and safeguards for delegated organization access. 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](/workspace/permissions). ## 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: ``` crn:iam::production:role/deploy crn:iam::production:policy/read-reports crn:iam::production:service-account/deploy-bot crn:iam:::policy/Administrator crn:workspace:::organization//group/report-readers ``` 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. | Call | Action | | -------------------------------------------------------------------------------- | -------------------------------- | | `GET /v1/regions` | `none` | | `GET /v1/service-accounts` | `iam:ListServiceAccounts` | | `POST /v1/service-accounts` | `iam:CreateServiceAccount` | | `GET /v1/service-accounts/{service_account_id}` | `iam:GetServiceAccount` | | `PATCH /v1/service-accounts/{service_account_id}` | `iam:UpdateServiceAccount` | | `DELETE /v1/service-accounts/{service_account_id}` | `iam:DeleteServiceAccount` | | `GET /v1/service-accounts/{service_account_id}/credentials` | `iam:ListCredentials` | | `POST /v1/service-accounts/{service_account_id}/credentials` | `iam:ManageCredentials` | | `DELETE /v1/service-accounts/{service_account_id}/credentials/{credential_id}` | `iam:ManageCredentials` | | `GET /v1/service-accounts/{service_account_id}/policies` | `iam:ListServiceAccountPolicies` | | `POST /v1/service-accounts/{service_account_id}/policies` | `iam:AttachPolicy` | | `DELETE /v1/service-accounts/{service_account_id}/policies/{policy_id}` | `iam:DetachPolicy` | | `GET /v1/roles` | `iam:ListRoles` | | `POST /v1/roles` | `iam:CreateRole` | | `GET /v1/roles/{role_id}` | `iam:GetRole` | | `PATCH /v1/roles/{role_id}` | `iam:UpdateRole` | | `DELETE /v1/roles/{role_id}` | `iam:DeleteRole` | | `GET /v1/roles/{role_id}/policies` | `iam:ListRolePolicies` | | `POST /v1/roles/{role_id}/policies` | `iam:AttachPolicy` | | `DELETE /v1/roles/{role_id}/policies/{policy_id}` | `iam:DetachPolicy` | | `GET /v1/policies` | `iam:ListPolicies` | | `POST /v1/policies` | `iam:CreatePolicy` | | `GET /v1/policies/{policy_id}` | `iam:GetPolicy` | | `PATCH /v1/policies/{policy_id}` | `iam:UpdatePolicy` | | `DELETE /v1/policies/{policy_id}` | `iam:DeletePolicy` | | `GET /v1/policies/{policy_id}/service-accounts` | `iam:GetPolicy` | | `GET /v1/policies/{policy_id}/roles` | `iam:GetPolicy` | | `POST /v1/assume-role` | `iam:AssumeRole` | | `POST /v1/assume-role-with-web-identity` | `none` | | `POST /v1/oauth/token` | `none` | | `POST /v1/oauth/revoke` | `none` | | `GET /v1/sts-sessions` | `iam:ListSTSSessions` | | `GET /v1/sts-sessions/{session_id}` | `iam:GetSTSSession` | | `DELETE /v1/sts-sessions/{session_id}` | `iam:RevokeSession` | | `PUT /v1/service-accounts/{service_account_id}/permission-boundary` | `iam:SetPermissionBoundary` | | `GET /v1/service-accounts/{service_account_id}/permission-boundary` | `iam:GetPermissionBoundary` | | `DELETE /v1/service-accounts/{service_account_id}/permission-boundary` | `iam:RemovePermissionBoundary` | | `GET /v1/service-accounts/{service_account_id}/inline-policies` | `iam:ListInlinePolicies` | | `PUT /v1/service-accounts/{service_account_id}/inline-policies/{policy_name}` | `iam:PutInlinePolicy` | | `GET /v1/service-accounts/{service_account_id}/inline-policies/{policy_name}` | `iam:GetInlinePolicy` | | `DELETE /v1/service-accounts/{service_account_id}/inline-policies/{policy_name}` | `iam:DeleteInlinePolicy` | | `PUT /v1/roles/{role_id}/permission-boundary` | `iam:SetPermissionBoundary` | | `GET /v1/roles/{role_id}/permission-boundary` | `iam:GetPermissionBoundary` | | `DELETE /v1/roles/{role_id}/permission-boundary` | `iam:RemovePermissionBoundary` | | `GET /v1/roles/{role_id}/inline-policies` | `iam:ListInlinePolicies` | | `PUT /v1/roles/{role_id}/inline-policies/{policy_name}` | `iam:PutInlinePolicy` | | `GET /v1/roles/{role_id}/inline-policies/{policy_name}` | `iam:GetInlinePolicy` | | `DELETE /v1/roles/{role_id}/inline-policies/{policy_name}` | `iam:DeleteInlinePolicy` | `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. ```json theme={null} { "version": "2024-01-01", "statements": [{ "effect": "allow", "actions": ["iam:AttachPolicy", "iam:DetachPolicy"], "resources": [ "crn:iam::production:policy/read-reports", "crn:iam::production:role/reports" ] }] } ``` A system policy needs coverage of its own `crn:iam:::policy/` 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](/workspace/permissions#delegating-organization-policies). ## 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/`, or `/inline-policy/*` for its list: ``` crn:iam::production:role/deploy/inline-policy/read-artifacts ``` Account boundary operations use `crn:iam::production:permission-boundary/`. 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:::sts-session/`. 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.