Skip to main content
IAM manages roles, service accounts, account policies, and temporary sessions. Each belongs to one account. The API is global at iam.basaltic.sh: the same account identity can work across regions, within its permissions. Workspace manages organizations, people, groups, and organization policies. A global endpoint does not mean an organization-wide resource.

Roles and credentials

Access keys, trust policies, assumed roles, and instance identities.

Writing policies

The document format, conditions, and worked examples.

Permission boundaries

Limit the account permissions a role or service account can receive.

Permissions

IAM actions and the resources they authorize.

Account access for people

User and group assignments, followed by an explicit role assumption.

Troubleshooting access

Check account scope, policy scope, trust, and session limits.

​
The identity model

Groups belong to the organization and contain users only. Their organization policies apply to members. Their account role assignments let members request those roles, subject to trust. Service accounts never join groups. A role session uses the target role’s permissions. It does not combine the source user’s, service account’s, or previous role’s permissions with them.

​
Resource names

Policies identify resources with CRNs:
The region is empty for global services. Account IAM CRNs contain the account handle. Workspace organization resources leave the account slot empty and include the organization UUID in the resource path. Shared system account policies use crn:iam:::policy/<Name>. * is the only wildcard. The colon and slash layout is matched literally. See resource references for names, UUIDs, and exact list filters.

​
How a request is authorized

The credential first binds the caller to an organization and, for machine and role credentials, an account. A different X-Account-Id cannot move an identity to another account. Use AssumeRole for an explicit account transition. The action chooses the policy domain:
  • workspace:*, billing:*, quota:*, and audit:* use organization policies.
  • Account service actions use the role’s or service account’s account policies.
  • A human’s account role assignment permits the AssumeRole exchange; ordinary account operations require the resulting role session.
Within that domain, an explicit deny wins. Otherwise an allow is required. An optional session policy can only narrow the result. Account permission boundaries cap account permissions; a user’s Workspace boundary caps their organization permissions. Account policies and boundaries cannot grant or restrict a separately delegated organization policy. Organization owners use explicit Workspace Administrator grants and assigned account Administrator roles. Ownership never bypasses policy evaluation. Permission changes must preserve the owner’s required administrator access; see account access.
An account policy allowing * is still an account policy. It cannot grant billing, organization administration, or other organization actions. Delegate those separately through Workspace.

​
Failing closed

Two behaviours are worth knowing because they are deliberate rather than incidental:
If a permission boundary is set but the boundary or its policy cannot be loaded, the request is denied. A boundary that exists but cannot be read might be capping this very action, so the safe answer is no.
An unrecognised condition operator never matches. On an allow statement that means the statement is skipped. On a deny statement it is treated as a hard deny when the action and resource match — otherwise a typo in a guardrail would silently disable it.

​
Next

Writing policies

Statements, actions, resources, conditions, and a set of examples to start from.

Roles and credentials

How a program gets credentials in the first place.