Roles & permissions

Taranac’s RBAC (role-based access control) governs who may do what inside the admin console — view the dashboard, edit a RADIUS profile, delete a network device, export logs, and so on. It is the control plane for your own operators, not for the endpoints and users that authenticate through Taranac.

Permissions in Taranac flow through three objects:

1. Permission model (also called an RBAC model or role) — a named set of allowed actions, e.g. auditor.
2. Group — users are organised into groups; a group is linked to one permission model.
3. User — an administrator inherits the permissions of every group they belong to.

A user is never assigned a role directly. You assign a permission model to a group, then put users in that group. This is the same group object used for TACACS+/RADIUS authorisation, so one group can carry both an admin role and network-access settings.

Permission model  ──assigned to──▶  Group  ──contains──▶  User (administrator)

When a user logs in, Taranac computes their effective permissions by merging the models of all their groups (see Permission resolution).

A permission model is a matrix of sections and actions:

• A section is a feature area — users, devices, tacacs_profiles, nac_endpoints, audit_logs, and so on.
• An action is something you can do within that section — typically view, create, edit, delete, plus section-specific ones such as export, manage_members, lock_unlock, revoke, or rotate_key.

Each action is simply on or off. A model that grants devices.view and devices.edit but not devices.delete lets its members open and modify network devices but not remove them.

Sections are grouped into categories for display:

A group can be flagged as an admin group (is_admins). Members of an admin group have full, unconditional access to everything; their permission model, if any, is ignored. The initial admin account created on first boot belongs to such a group.

Taranac seeds three ready-made permission models on first start. They are convenience templates — fully editable and deletable like any model you create yourself.

All three are generated from the live permission registry at seed time rather than written out by hand, so they cover every module’s sections — including modules added after the installation was built.

Open Infrastructure → Identity → RBAC.

The RBAC Models screen — the three seeded roles on a fresh installation.

The list carries Name, Description, Used by and Created, is searchable across name and description, sorts on name and creation date, and lets you hide columns from the ⚙ toggle. Click a row to open the model; Add Model creates a new one. Opening a model gives you the editor directly if you hold rbac.manage — with only rbac.view the same page opens read-only.

Since 1.1.0 every model carries a Used by count, and clicking it opens the where-used drawer listing exactly what points at the model:

• Groups that have the model assigned. Since migration 0023 this is a RESTRICT foreign key: a model assigned to any group cannot be deleted out from under it. The earlier behaviour silently blanked the group’s permission model.
• LDAP configurations that name the model as their default role or in a per-group override (since 1.2.1). These live in settings rather than in a foreign key, so before 1.2.1 they were invisible to the where-used view and the model could be deleted, leaving the configuration pointing at nothing.

Both are blocking references. The delete is refused with the holders itemised by name — unassign or repoint them first, then delete.

A model has a Name (required, unique, up to 100 characters) and an optional Description, followed by the permissions matrix. The matrix is organised by category; each section is a collapsible card — all collapsed to start with — badged with how many of its actions are granted out of how many exist (grey for none, yellow for some, green for all), with:

• an All toggle that grants or revokes every action in the section at once, and
• a switch per action, labelled and described by the backend rather than by the UI.

Tick exactly the actions the role should allow, then Save.

Roles take effect only once attached to a group:

1. Create or edit the permission model under Infrastructure → Identity → RBAC.
2. Go to Infrastructure → Identity → Groups, open the relevant group, and set its RBAC model.
3. Add the administrators to that group under Groups → members.

Changes apply at the user’s next login, because effective permissions are computed during authentication.

Since 1.2.8, opening a group whose own Web console access is set to Deny shows the RBAC model picker read-only, hinting “Kept, but not applied while this group denies the console.” A role granted to people who cannot reach the console grants nothing, but the assignment stays visible — nothing was deleted, and that has to be something you can see. Switch the access back and the role applies again. This follows the group’s own mode, not the resolved one: a group left on System default has decided nothing yet, so its picker stays editable — you may well be preparing a role before opening the console to it. The mode itself is documented under Web console access.

When a non-admin administrator logs in, Taranac:

1. Loads every group the user belongs to.
2. If any group is an admin group → grants full access (RBAC bypassed).
3. Otherwise merges the permission models of all their groups using a logical OR: an action is allowed if any group grants it.
4. If the user is in no groups — or in groups that have no permission model — they have no permissions and cannot use the console.

You can inspect any user’s merged result; the console exposes their effective permissions, which is the quickest way to answer “why can this person do X?”.

Read-only auditor. Compliance staff who must see everything but change nothing. Assign the auditor role (read-only everywhere, plus log/audit export) to their group. They can review configuration, sessions and logs and pull exports for evidence, but every create/edit/delete button is rejected.

NAC operator. A team that runs day-to-day network access — onboarding endpoints, adjusting endpoint groups, watching sessions — but should not touch AAA policy or system settings. Create a custom model granting view/create/edit on nac_endpoints and nac_auth_profiles, the same plus manage_members on nac_endpoint_groups, view/manage on nac_sessions, and view on the AAA and Network sections — leaving Security and System off.

Full administrator. Platform owners. Put them in the admin group (is_admins) — they bypass RBAC and hold every permission implicitly. Keep this group small.

Help-desk / limited operator. Front-line staff who reset and unlock accounts but never delete them. Start from operator (which already excludes deletion) or build a model granting users.view, users.edit, users.lock_unlock and little else.

The four CRUD verbs carry most of the matrix; the rest are section-specific.

Available actions vary per section; the permissions editor always shows the exact set each section supports, with the label and description the owning module declared.

• Users & groups — create groups, manage membership, and attach a permission model
• LDAP directories — map directory groups, where only the admin flag, MFA requirement and permission model are editable on synced groups
• Multi-factor authentication — enforce MFA per group at login
• AAA policy and NAC overview — network-access policy, which is distinct from console RBAC
• Config Tracker credentials — where the separately-audited reveal permission applies
• Reports — the run / build / schedule / export split on the reports section
• Licensing — the License section (view / manage) gates who can see and replace the Pro license
• High availability — the Cluster section (view / manage) gates cluster status, join tokens and node decommission
• Taranac on GitHub