Users and permissions: the model
One user, one organization
Every CreaRack user belongs to exactly one organization. Data is fully isolated per organization: when you log in, you only ever see your own racks, devices, monitoring and content. There is no way to reach another tenant’s data.
The three roles
Each user has a role that sets their baseline access across the whole product:
| Role | Intent |
|---|---|
| Read Only (Viewer) | Can look, cannot touch. The default for new users. |
| Operator | The day-to-day technician: can create and edit in every working module. |
| Admin | Full control, including user management and organization settings. |
Roles are deliberately coarse. The fine print lives one layer down, in module permissions.
Module permissions: four levels across ten modules
On top of the role, an Admin can set a per-module level for each user. The modules are Racks, Blueprints, Observatory, Terminal, Network, CNS, ITSM, Fleet, Signage and Users, and each one takes one of four levels:
| Level | What it grants |
|---|---|
| None | No access — the module disappears from the user’s navigation. |
| View | Read-only access to that module. |
| Edit | Can view and change things in that module. |
| Admin | Full control of that module, including its administrative actions. |
A per-module setting overrides the role default for that module only. Two examples:
- An Operator with Terminal = None keeps editing racks and maps but never sees the SSH terminal.
- A Read Only user with Observatory = Edit can manage monitoring targets while staying read-only everywhere else.
If no override is set, the role default applies. Admin defaults to Admin everywhere; Operator defaults to Edit everywhere except Users (View); Read Only defaults to View everywhere except Fleet and Users (None).
This enables least-privilege setups such as a network technician limited to Terminal and Observatory, or a facilities manager who only sees Racks and Blueprints.
Racks = None also applies to the API. A user without at least View on Racks can no longer reach rack data through the API either — rack cards, exports, QR labels, the stencil library and the rack trash all check the same permission, not just the screens that show them. With the default role permissions nothing changes; this only matters if you have set a user’s Racks permission to None by hand.
A device’s network configuration needs Network too. Opening a device’s SSH Config (the one-time setup that lets CreaRack manage it over SSH — see [[crearack—racks—ssh-desde-rack]]) now also checks the Network module permission, on top of Racks. A user with Racks access but Network = None can see and use the device otherwise, but cannot open or change its SSH configuration.
Temporary access
Sometimes a user needs more power for a maintenance window — not forever. A temporary access grant elevates a user on one module (or all of them) to a chosen level for 1 to 72 hours, with a mandatory reason for the audit trail.
Three properties define the model:
- It only elevates. A grant never reduces what the user already has.
- It wins while active. During the window it takes precedence over the user’s normal permissions.
- It expires on its own. When the clock runs out, permissions snap back automatically. An Admin can also revoke it early.
Typical uses: an external vendor during an installation, a one-off task for a junior technician, or a time-boxed audit.
How a permission check is resolved
When a user tries to do something, CreaRack evaluates in this order: active temporary access first, then the explicit per-module override, then the role default. The first layer that answers, decides.
Authentication
Access control assumes the right person is behind the account. CreaRack supports password login hardened with MFA — TOTP authenticator apps and passkeys. The concepts and setup live in [[crearack—settings—mfa-and-login-security]]. Changing your own password always asks for your current one first (an administrator resetting someone else’s does not need it), and you stay signed in after the change.
Managing all of this
The hands-on procedures — adding users, editing the permission grid, granting temporary access, impersonation — are in the how-to guide: [[crearack—settings—user-management]].
Related
- [[crearack—settings—user-management]] — step-by-step user administration
- [[crearack—settings—mfa-and-login-security]] — MFA, passkeys and login protection
- [[crearack—conceptos—glosario]] — quick definitions of every product term
Véase también
- [[crearack—settings—user-management]]
- [[crearack—settings—mfa-and-login-security]]
- [[crearack—conceptos—glosario]]