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.

Everything about an admin group is the administrators’ business: changing any of its fields (its enable password and MFA requirement included), deleting it, revealing its enable password, and adding or removing its members are all refused to anyone who is not an administrator, whatever their role grants. Whether the person making the change is an administrator is read from the database at that moment, not from their session — an administrator who has just been removed from the admin group cannot use the session they still hold to put themselves back.

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.

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. This is a RESTRICT foreign key: a model assigned to any group cannot be deleted out from under it.
• LDAP configurations that name the model as their default role or in a per-group override. These live in settings rather than in a foreign key, and the where-used view reads them too, so the model cannot be deleted while a configuration still names it.

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.

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 is 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?”.

A permission such as users.edit says which kind of change you may make. It does not, on its own, say to whom. Without a second check, users.edit would be enough to take over a richer account: change its email, resend the welcome link to that address, set a password, and act as that person. Group membership and role editing would be ladders in the same way. So every change to identities is judged twice — by the permission the action needs, and by the rules below. Administrators (members of an admin group) pass all of them.

The comparison is made between sets of section.action permissions read from the database at the moment of the change: what the target holds through all of their groups, against what you hold through all of yours. A permission that a stored model still lists but that no module declares any more counts for nobody. Nothing here depends on session tokens, so a demotion takes effect on the very next change the demoted person attempts.

A refusal names what is missing, so the fix is visible from the message:

When a group’s MFA setup links are sent with Reset and resend to all, a member you may not change is skipped and the rest of the group still gets its links; the confirmation counts how many were sent out of how many members.

A directory configuration decides who lands in which group on the next sync and with which role, and its sync can deactivate or delete the accounts it owns. Writing one is therefore judged like all of those writes at once:

• The default role and every role in the per-group role mapping must be roles you fully hold — the same test as adding a member to a group. A role that an admin group uses can only be named by an administrator.
• Creating, editing or deleting the configuration needs every permission of every group it can populate (its own directory groups, plus orphaned directory groups left behind by a deleted configuration), and every web permission of every account it owns or could adopt.
• A configuration that feeds an admin group is administrator-only to edit or delete.

See LDAP directories.

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. Such a role manages network-only accounts and anyone holding no more than it does; an account with richer console rights — and any administrator — is refused to it (see Who may change whom). Add mfa.manage if the desk also handles lost phones.

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