Identity and access

Users

People sign in with an email and password, or through an external identity provider. Console: Admin › Platform › IAM › IAM Users.

stratumctl users create --email alice@example.com --display-name "Alice"
stratumctl users list
stratumctl users set-password u-alice --password '...'
stratumctl users update u-alice --state suspended

Without --password the server generates one. A user whose password an administrator set chooses a new one at the next sign-in.

Roles

A role binding grants a role to a user or a group at a scope: install, organization:<id> or project:<id>. An organization grant reaches every project in it.

Role	Scope	Can
platform-admin	install	Administer the whole cloud.
org-owner	organization	Manage the organization, its projects and its people.
project-admin	project	Everything in the project, including access.
project-editor	project	Create and change resources.
project-viewer	project	Read.

stratumctl role-bindings grant --user u-alice --role project-admin --scope project:p-web
stratumctl role-bindings grant --user u-ops --role platform-admin --scope install
stratumctl role-bindings list --user u-alice

Keep at least two people with platform-admin, each with their own password and MFA. Readiness warns while there is only one.

Groups

Members of a group inherit its role bindings and policies.

stratumctl groups create --name platform-eng
stratumctl groups add-member g-abc123 u-alice
stratumctl groups grant-role g-abc123 --role project-editor --scope-type project --scope-id p-web

IAM policies

For finer grants than roles, attach a custom policy: statements with an effect (permit or forbid), actions, resources (the whole scope or specific ARNs) and optional tag conditions. A forbid always wins over a permit.

[
  { "effect": "permit",
    "actions": ["compute:StartInstance", "compute:StopInstance"],
    "resources": { "kind": "scope" } },
  { "effect": "forbid",
    "actions": ["compute:DeleteInstance"],
    "resources": { "kind": "arns", "arns": ["arn:stratum:compute::p-web:instance/*"] },
    "conditions": [ { "key": "resource.tags.protected", "op": "eq", "value": "true" } ] }
]

stratumctl custom-policies create --name operators --scope-type project --scope-id p-web -f statements.json
stratumctl custom-policies attach cp-abc123 --target-kind user --target-ref u-alice

A resource policy goes the other way: attached to one resource, it says who may act on it.

stratumctl resource-policies set --resource-arn arn:stratum:network:local-1:p-web:vpc/vpc-abc123 -f rp.json

Test a grant before making it with the console’s Access Simulator.

Service accounts and tokens

Automation signs in as a service account with its own keys, not as a person:

stratumctl service-accounts create ci-deployer --project p-web
stratumctl service-accounts keys create --service-account sa-abc123 --project p-web

A person’s long-lived API token is stratumctl auth tokens create.

Two-factor authentication

Each user turns on two-factor authentication (an authenticator app, TOTP) in the console: the account menu, Security. It is then asked at every sign-in.

If the bootstrap administrator loses the second factor and the recovery codes, clear it as root on a node; the next sign-in enrolls a new one:

sudo stratum-bootstrap recover admin-mfa --yes

Sessions

A sign-in creates a session token. The account menu’s Security tab lists the user’s sessions, where and when each started, and Sign out everywhere ends all but the current one. Changing a password signs the user out everywhere else.

stratumctl auth status                     # this profile's endpoint, user and token validity
stratumctl auth tokens list                # personal access tokens
stratumctl auth tokens revoke <token-id>

External identity providers

Users can sign in through an OpenID Connect provider. Console: Admin › Platform › IAM › OIDC Providers.

stratumctl oidc-providers create --name corp --display-name "Corporate SSO" \
  --issuer-url https://sso.example.com/application/o/stratum/ \
  --client-id stratum --client-secret-ref <secrets-store reference>

The client secret is stored in the platform’s secrets store first; --client-secret-ref names it. Scopes default to openid, email and profile; --scope (repeatable) replaces them.

A first sign-in through the provider creates the user, unless --disable-jit.

Access requests

Admin › Platform › IAM › Access Requests is the queue for just-in-time elevation: a user asks for a role for a limited time, and an approver grants or refuses it. Approved grants expire by themselves.