Users, roles & API tokens
Roles and the user tree
Section titled “Roles and the user tree”| Role | Can |
|---|---|
| admin | Everything, including settings, the OS catalogue, network, datacenters and other admins |
| reseller | Manage their own customers (sub-users) and the servers owned by them or their customers |
| user | Use the servers they own or were given access to |
Users form a tree: every user has a parent. A server is visible to its owner and to everyone above the owner in
the tree. Users can also get explicit server permissions for servers they don’t own, per server:
read, power, console, provision, ipam and write.
Suspension works per level: when a reseller suspends a server, the reseller and everyone above can still act on it, while the levels below see This server is suspended.
Signing in
Section titled “Signing in”Passwords are hashed with Argon2id, and failed logins are throttled. Every user can turn on two-factor authentication (TOTP) under Profile & security (the menu under your name, top right); admins and resellers should. Each code works only once: someone who sees a code you just used can’t sign in with it, so after turning 2FA on, wait for the next code before signing in elsewhere. The login history of each user is kept.
API tokens
Section titled “API tokens”Tokens look like <id>|<secret> and are sent as Authorization: Bearer <id>|<secret>. Only a hash of the
secret is stored, and the secret is shown once when the token is created. Each token has:
- scopes:
*(everything its user may do),servers:read,servers:power,servers:console,servers:provision,servers:write,ipam:read,ipam:write,users:read,users:write,admin, - an optional expiry date,
- an optional IP allow-list.
A token never has more rights than its user, and its scopes are enforced on every request: a token with
servers:read can read servers but gets 403 for a power action. Endpoints that don’t belong to one of the scopes
need admin (or *). Create tokens under Users → (user) → API tokens or with the API.
The API itself is documented at api.trixos.sh.
SSH keys
Section titled “SSH keys”Users can store SSH public keys and pick them when they reinstall a server or boot a rescue system.
Audit log
Section titled “Audit log”Every change, through the UI or the API, is written to the Audit log with who, when, from which address, what and the details. Each server also has its own audit tab.