Role-Based Access Control¶
TrueNAS uses a role-based access control (RBAC) system to restrict which API methods a session may call. Roles are grouped into privileges, and privileges are linked to local or directory-service groups. When a user authenticates, the TrueNAS resolves that user’s group memberships to a set of active roles, which are then checked against every API call the user makes.
Privilege management is performed via the privilege.* API namespace
(privilege.create, privilege.update, privilege.delete,
privilege.query).
Role Concepts¶
Individual roles (builtin=true)¶
Individual roles are fine-grained roles attached directly to individual API
methods. Examples: DISK_READ, SHARING_SMB_WRITE, ACCOUNT_READ.
They are provided to allow selective expansion of access beyond what the
predefined group roles cover. Custom privileges can combine any set of these
roles to grant precisely the access required for a given use case.
Predefined group roles (builtin=false)¶
Predefined group roles are the four top-level roles surfaced in the UI and API for privilege assignment:
FULL_ADMINREADONLY_ADMINSHARING_ADMINREPLICATION_ADMIN
READONLY_ADMIN is the minimum role required for UI access. A privilege
that grants only individual roles — without including at least
READONLY_ADMIN — will not be sufficient to log in to the web interface.
Use privilege.roles (filter builtin=false) to retrieve the current list
of predefined group roles at runtime.
Role inclusion¶
Roles can declare that they include other roles. Inclusion is expanded
transitively, so a user assigned SHARING_ADMIN automatically gains all of
the individual roles that READONLY_ADMIN expands into, plus the additional
write roles specific to sharing.
As a general convention, write roles include their corresponding read role.
For example, ACCOUNT_WRITE includes ACCOUNT_READ, so granting write
access to a subsystem always implies read access to that same subsystem.
Roles are additive and cannot be scoped down. There is no way to grant a
role while simultaneously excluding a subset of what it includes — for
example, it is not possible to assign FULL_ADMIN while blocking
ACCOUNT_WRITE. If finer-grained control is required, build a custom
privilege from individual roles rather than starting from a broad predefined
group role.
Predefined Group Roles¶
Role |
Description |
Notable included roles |
|---|---|---|
|
Unrestricted access to all API methods |
All roles |
|
Read-only access across all subsystems |
All |
|
Manage datasets and all file-sharing protocols |
|
|
Manage replication, snapshots, and keychain credentials |
|
FULL_ADMIN¶
FULL_ADMIN grants unrestricted access to every API method. It cannot be
scoped down — a session holding this role may call any method regardless of
what other roles are present or absent.
The local root and truenas_admin accounts implicitly hold this privilege.
Under GPOS STIG mode, any method not covered by a role becomes unreachable for all users.
READONLY_ADMIN¶
READONLY_ADMIN expands into every *_READ individual role defined in the
system. A session with this role can call any *.query or
*.get_instance endpoint and any other read-only method, but cannot create,
update, or delete any resource or change any configuration.
This role corresponds to the built-in READONLY_ADMINISTRATOR privilege.
GPOS STIG has no effect on this role — all *_READ individual roles are
GPOS-available.
REPLICATION_ADMIN¶
REPLICATION_ADMIN provides write access to the replication subsystem:
Replication tasks (push and pull)
Periodic snapshot tasks
ZFS snapshots
Keychain credentials (SSH keypairs and cloud credentials used by replication)
A session with REPLICATION_ADMIN cannot manage datasets or pools
directly, configure sharing protocols, manage user accounts, or change system
settings.
There is no built-in local group for REPLICATION_ADMIN; it must be
assigned through a custom privilege entry.
GPOS STIG has no effect on this role — all included roles are GPOS-available.
Individual Roles Reference¶
The table below lists all individual roles available for use in custom
privileges. Roles marked unavailable under STIG cannot be granted to any
session when system.security has enable_gpos_stig=true.
Subsystem |
Roles |
Notes |
|---|---|---|
Local Accounts |
|
|
API Keys |
|
|
Auth Sessions |
|
|
Boot Environments |
|
|
Certificates |
|
|
Cloud Backup |
|
|
Cloud Sync |
|
|
Containers / LXC |
|
All |
Dataset |
|
|
Directory Services |
|
|
Disk |
|
|
Apps / Docker |
|
All |
Enclosure / JBOF |
|
|
Failover |
|
|
Filesystem |
|
|
IPMI |
|
|
Keychain Credentials |
|
|
KMIP |
|
|
|
||
Network |
|
|
Pool |
|
|
Privilege |
|
|
Replication |
|
|
Reporting |
|
|
Services |
|
|
Sharing — FTP |
|
|
Sharing — iSCSI |
|
|
Sharing — NFS |
|
|
Sharing — NVMe-oF |
|
|
Sharing — SMB |
|
|
Sharing — WebShare |
|
|
Sharing (aggregate) |
|
Each expands into all |
Snapshots |
|
|
SSH |
|
|
Support |
|
|
System Audit |
|
|
System Settings |
|
|
TrueCommand |
|
|
TrueNAS Connect |
|
|
Virtual Machines |
|
All |
ZFS Resources (filesystems, zvols) |
|
GPOS STIG Mode¶
When system.security has enable_gpos_stig=true, the GPOS STIG profile
is active. Under this profile certain write roles become unavailable,
meaning sessions that hold only those roles lose write access to the
corresponding subsystems. The matching read roles remain available in all
cases.
The stig field in privilege.roles output indicates which STIG profiles
permit a role. A value of null means the role is not permitted under any
STIG profile; a non-null value identifies the profile(s) that allow it.
Unavailable role(s) |
Affected area |
|---|---|
|
API key management ( |
|
Virtual machines |
|
Containers and LXC |
|
Docker back-end |
|
Applications catalog |
|
TrueCommand integration |
|
TrueNAS Connect cloud service |
For FULL_ADMIN specifically, see the note in the FULL_ADMIN section above.
Managing Privileges¶
Use the following API methods to manage privileges:
privilege.create— create a new privilege and link it to one or more local or directory-service groupsprivilege.update— modify an existing privilege (change roles or group membership)privilege.delete— remove a custom privilegeprivilege.query— list all privileges, including the three built-in onesprivilege.roles— list all roles; pass[["builtin", "=", false]]as the filter argument to return only the predefined group rolesauth.me— returns the currently authenticated session, including the full list of roles that have been granted to it
Note
Enterprise license requirement. Linking a privilege to a directory-service group (Active Directory or LDAP group) requires an Enterprise license. On Community Edition, privileges can only be assigned to local Unix groups.
Note
Secret field redaction. API responses automatically redact fields
marked secret in the schema (for example, credentials and passwords)
for any session that does not hold the FULL_ADMIN role. Such fields
are replaced with a redacted placeholder rather than being omitted, so the
response structure remains consistent.