Skip to main content
IAM decides who may do what. Every other Basaltic API asks it the same question before acting: may this principal perform this action on this resource? It is a global service — iam.basaltic.sh, no region segment. One identity works in every region.

Writing policies

The document format, every condition operator, and worked examples.

Roles and credentials

Access keys, trust policies, assumed roles, and workload federation.

Permission boundaries

Capping what a policy can ever grant, and safe delegation.

How a request is decided

The five steps, in the order they actually run.

​
The identity model

Organization

The top of the tree. Users, groups, service accounts, roles and policies all belong to one organization and are never visible outside it.

Account

A resource container inside the organization. Instances, volumes and zones belong to an account; identities do not.
Four kinds of principal can make a request: Groups collect users and service accounts, so a policy attached to a group reaches both. Policies attach to users, service accounts, groups and roles.
A user is a person and does not hold an access key. Anything programmatic — a script, a CI job, a deployed workload — is a service account or an assumed role. See roles and credentials.

​
Resource names

Policies name resources by CRN:
Two slots are empty on purpose. Region is empty for a global service — IAM, DNS, certificates and billing. Account is empty for resources that belong to the organization rather than to an account, which is every IAM identity.
A CRN never carries an organization id. The organization comes from the authenticated request, which makes cross-organization access impossible by construction rather than by a check somebody has to remember to write.
* is the only wildcard, and the colon/slash layout is compared literally — a pattern written in any other shape matches nothing.

​
How a request is authorized

Every service calls the same authorizer. It runs these five steps in order:
1

Bind the principal to the organization

Before anything is evaluated, the principal is confirmed to belong to the organization the request names. This is what stops a wildcard policy from authorizing against a CRN in someone else’s organization.
2

Organization owner short-circuit

An organization owner has implicit full access, subject only to an explicit deny. Permission boundaries do not apply to an owner. A session policy on temporary credentials still does — credentials advertised as scoped-down must not inherit the bypass.
3

Collect and evaluate the effective policies

Everything attached to the principal, directly and through its groups. An assumed role authorizes as the role, so the role’s policies are what get evaluated, not the caller’s.The result is one of three: explicit deny, explicit allow, or nothing matched.
4

Intersect with the session policy

If the caller is using temporary credentials that carry a session policy, an allow survives only if the session policy also allows it. This is an intersection, never an expansion — a session policy can never grant something the identity does not already have.
5

Apply the permission boundary

If the principal has a boundary, the action must be allowed by the boundary as well. Same intersection rule.
If the decision is still allow, the request proceeds. Otherwise it is denied and the denial is logged for audit.

​
The rule that decides everything

An explicit deny always wins. It beats any allow, from any policy, anywhere in the evaluation — including an organization owner’s implicit access. Nothing overrides it, and there is no ordering or priority you can use to work around it.
Access is otherwise denied by default: if no statement matches, the answer is no. A principal with no policies attached can do nothing.

​
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.