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.

Open Infrastructure → Identity → RBAC.

The RBAC Models screen — each model shows its name, description, type and creation date.

The list is searchable and filterable by Type (Custom vs. System). To inspect a role, click its row — it opens read-only. Use Edit to change it, or Add Model to create a new one.

A model has a Name (required, 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 showing how many of its actions are granted (a green/yellow/grey badge), with:

• an All toggle that grants or revokes every action in the section at once, and
• individual checkboxes per action.

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 RBAC.
2. Go to Identity → Groups, open the relevant group, and set its permission 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.

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/manage_members on the NAC sections (nac_endpoints, nac_endpoint_groups, nac_sessions, nac_auth_profiles) and view on AAA and Network, 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.

Available actions vary per section; the permissions editor always shows the exact set each section supports.

• 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
• 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