Skip to main content
Workspace serves organization resources at workspace.basaltic.sh. Grant workspace:* actions in organization policies. Billing, quota, and audit actions are also evaluated in the organization policy domain. Account IAM policies never grant these actions, even with an action wildcard. Users inherit organization policies directly and through user groups. Roles and service accounts receive only organization policies explicitly delegated to them. A role session uses the role’s grants, not those of its source.

​
Resource names

Groups and custom policies use immutable names. Accounts, users, and invitations use UUIDs. An account’s display name is not its handle or its CRN identity. Top-level lists authorize their collection, not each result; query filters do not replace authorization. User and group inline policies append /inline-policy/<name> to the principal CRN. A user’s permission boundary appends /permission-boundary/default. Setting that boundary also requires workspace:GetPolicy on the chosen policy.

​
The actions

The table includes primary actions. Additional target-account checks for organization delegation and role assignment are described below. Human members can read their own organization through membership. Machine identities need workspace:GetOrganization. Organization listing returns the human’s memberships. Personal sign-in, invitation acceptance, and switching the active organization remain IAM authentication flows.

​
Attaching organization policies to people

workspace:AttachPolicy and workspace:DetachPolicy require authorization on both the organization policy and target user or group. Use the concrete CRNs of both resources; system policies have their separate system CRN namespace.

​
Delegating organization policies

A role or service account can carry organization permissions for billing collectors, onboarding jobs, or other automation. Its console policy tab has separate Account policies and Organization policies tables. The organization attachment endpoints are on Workspace, not IAM: POST accepts policy_id, the organization’s policy UUID. DELETE appends that UUID to the path. GET lists the organization’s policy attachments. The target’s UUID is resolved within the current organization and its owning account; it does not move the caller’s identity into that account. The same caller must satisfy both checks: Combining two credentials is not supported. Use an identity that holds the required organization grant and target-account permission, or an organization owner performing initial setup. An account role with no organization grants cannot attach them to itself. Sensitive changes that transfer an already delegated identity’s authority also require Workspace delegation permission. Account policy administration alone cannot obtain organization access by passing a role or issuing a new credential.

​
Account role assignments

Role assignments bind an organization user or group to a role in one account. They supply the source permission for a human’s AssumeRole exchange. Target trust is still required, and assignment creation never changes trust. Creating an assignment requires workspace:AssignAccountRole plus iam:GetRole for the target role. Listing and removing assignments use workspace:ListAccountRoleAssignments and workspace:RemoveAccountRoleAssignment. The current human can discover their effective assignments through GET /v1/account-roles. This is distinct from the administrative account list; a user need not receive workspace:ListAccounts simply to choose an assigned role. See account access.