Identity & Access
This page explains how you sign in to Null Autos and how the platform decides what you are allowed to do.
Authentication: how you sign in
Null Autos uses single sign-on (SSO) over OIDC. Depending on where you are, you authenticate one of several ways. The platform supports them all, so the same identity works from your laptop, a pipeline, or a cloud workspace.
| Method | When it is used |
|---|---|
| Browser SSO | Signing in to the portal, or nullctl on your laptop. Supports federation to your corporate identity provider. |
| GitLab personal access token | Direct API calls authenticated as a GitLab user. |
| GitLab CI job token | Automatically inside GitLab pipelines, with no secrets to manage. |
| Workspace token | Automatically inside a cloud workspace. |
| Service account | For in-cluster, machine-to-machine calls. |
nullctl and the SDKs handle picking the right method for you. See the
CLI Quickstart.
Single sign-on and federation
Because identity runs through SSO, your organization can federate to an existing identity provider so users sign in with their normal corporate accounts. Tenants are mapped to identity boundaries, and domain-based routing sends users to the right login automatically.
Authorization: what you are allowed to do
Once you are authenticated, the platform's authorization service decides what you can do. It uses relationship-based access control (ReBAC): instead of static role strings, permissions come from relationships between users and resources.
Roles
Every resource type (tenant, emulator, snapshot, target, application, group, and more) supports a consistent set of roles:
| Role | Typical capability |
|---|---|
| admin | Full control, including managing access |
| operator | Operate the resource (for example deploy, restart, connect) |
| member | Belong to a tenant and view its resources |
| viewer | Read-only visibility |
These resolve into computed permissions like can_manage, can_operate,
can_view, and can_read, which the API checks on each call.
Inheritance
Permissions flow down the resource hierarchy, so you do not have to grant access object by object:
- A system admin has admin everywhere.
- A tenant admin has admin over all resources in their tenant.
- A group can be granted access to specific resources, and every member of that group inherits it.
- A tenant member gets read visibility into the tenant's resources.
Groups
Groups are the practical way to manage access at scale. Add users to a group, grant the group access to a set of emulators or snapshots, and membership changes propagate automatically.
Checking your own access
You can always see who you are and what you can do:
- In the portal, your permissions drive what is visible.
- With the CLI:
nullctl get whoamiandnullctl get permissions. - Over the API:
GET /api/v1/whoamiandGET /api/v1/permissions/me.
See Security for the broader protection model.