Skip to content
Stackship documentation Svenska

Access controlUsers

Access control

How the platform decides who may do what — principals, roles, scopes, deny assignments and just-in-time access.

Every call to the platform — from the portal, stsh, the API or an AI client — is checked against role-based access control. A principal holds roles at a scope, and a role is a list of actions. The call is allowed when one of the principal's roles grants the action at that scope, or above it, and no deny assignment blocks it.

Principals

Principal What it is
User A person who signs in
Group A set of users. A role assigned to a group applies to each of its direct members
Service principal A machine identity: a service account for CI/CD and integrations, or the managed identity the platform gives a workload

Service accounts are described in Service accounts, managed identities in Managed identities.

Actions and data actions

An action names one operation: <area>/<operation>, sometimes with a sub-area — apps/write, secretvault/read, boundaries/members/manage. Actions on a resource's configuration are control-plane actions. Actions on its content — reading a secret's value, streaming logs, opening a terminal, querying a database — are data actions, and a role grants them only in its separate list of data actions. Managing a resource therefore does not by itself let you read what is inside it.

A role can also subtract: NotActions and NotDataActions remove actions its wildcards would otherwise include. Two matching rules are worth knowing:

  • * stands for one part of an action name; a trailing * stands for everything after it. apps/* covers every Apps action, */* covers everything, and */read covers two-part actions ending in read (such as apps/read) but not kernel/clusters/read.
  • X/write also grants X/delete. The same applies when excluding: excluding apps/write excludes apps/delete too.

The actions that govern access control itself are described in Permissions; every action on the platform can be browsed on the Permissions step of creating a custom role, and the IAM reference in the RBAC docs lists every action and every built-in role with exactly what it grants.

Scopes and inheritance

A role is assigned at a scope, and the assignment applies to everything below it:

Scope Form
Platform root /
Boundary /boundaries/<boundary-id>
Resource group /boundaries/<boundary-id>/resourcegroups/<name>
Resource /boundaries/<boundary-id>/resourcegroups/<name>/resources/<type>/<name>

Contributor on a boundary applies to every resource group and resource in it; Secrets Reader on one vault applies to that vault only. A few actions — creating boundaries, the Lifecycle Manager, platform settings — are only ever checked at /; see Root-scoped actions.

How a request is decided

  1. Deny assignments are checked first. If one covers the principal, the action and the scope, the call is refused, whatever roles the principal holds — Owner included. See Deny assignments.
  2. Role assignments of the principal and of the groups it belongs to, at the scope or above, are checked next.
  3. Active just-in-time grants count as role assignments until they expire. See Just-in-time access.

There are no conditions on assignments: an assignment holds everywhere under its scope, at every time, until it is removed.

Services keep access decisions for 30 seconds and a user's group memberships for 60 seconds, so a change can take a minute or two to be felt everywhere.

Where you manage it

In the portal at https://portal.example.com, open Access control (IAM) in a boundary's sidebar. You need rbac/members/read; Reader, Contributor and Owner have it. The page has five tabs: Role assignments, Roles, Deny assignments, JIT access and Check access. The Access Control tab of a single resource, and of the boundary itself, shows and grants access at that one scope.

People, groups, service accounts and invitations are managed on the Identity page — see Users and invitations. Single sign-on is a platform administrator's task — see Single sign-on.

Pages