User Roles
Every member of a namespace holds one role. The role decides what they can do to the namespace itself.
| Role | Can |
|---|---|
| Observer | View device and session details. Nothing else. An observer cannot connect to a device, except by native SSH in a legacy namespace |
| Operator | Device-related operations — connecting, viewing details, managing devices — but not removing a device. Also has session details |
| Administrator | Nearly everything the owner can, but cannot delete the namespace, and has no billing actions |
| Owner | Everything |
These are the roles a person holds. An automation holds none: it is an API key, and where it may reach over SSH comes from the policies naming it. See SSH Access.
Roles do not grant device access
Worth stating plainly, because the names suggest otherwise.
An operator is not automatically allowed to reach any device. Device access comes from access policies, evaluated per connection. A member with the operator role and no matching policy connects to nothing.
What the role controls is the console: what they see, what they can change, whether they can remove a device.
A role never grants device access, but it can withhold it. The observer role holds no connect permission. In a new namespace an observer is refused before their policies are read, and the refusal covers the whole connection, including file transfer and port forwarding. The browser terminal refuses them in both. Native SSH in a legacy namespace carries no user identity, so the role cannot be enforced there. Grant an observer a policy and they still connect to nothing. Make them an operator and the policy decides.
Roles as policy subjects
The two systems meet here, and it is the most useful pattern in the whole model. A policy can name a role as its subject:
| Name | Effect | Subject | Devices | Logins |
|---|---|---|---|---|
| Operators to fleet | allow | Role: operator | tag production |
deploy |
Now the role is doing both jobs: it says what somebody can do in the console, and — through the policy — what they can reach. Adding a member as an operator grants both at once.
Choosing
Observer for people who need to look — support staff triaging, someone reviewing a session recording.
Operator for the people doing the work. The inability to remove a device is the point: they can operate the fleet without being able to erase parts of it.
Administrator for people who manage the namespace day to day. The two exclusions — deleting the namespace and billing — are the ones you want to keep to the owner.
Owner for exactly one person.
API keys carry roles too
An API key is created with a role, and it must be equal to or less than the role of whoever creates it. An operator cannot mint an administrator key. Changing a key’s role later takes the same authority from whoever edits it.
A key never acts as an owner. The highest role it acts with is administrator, so an owner’s key is an administrator key. A key keeps its role when its creator’s role changes, except that demoting the creator to observer deletes their keys. A key stops working when its creator leaves the namespace.
See API keys.
Where to go next
- Members — Adding people.
- Access Policies — Granting device access by role.