User roles — RBAC, privilege levels, the role-per-concern pattern

Role-based access control (RBAC) restricts what each user can do on the router. The principle of least privilege says every user gets the minimum privileges needed to do their job. On VyOS 1.5 LTS, RBAC is implemented through the system login user <name> role configuration; the operator defines roles, binds them to users, and grants only the privileges each user actually needs.

This lesson covers the RBAC model on VyOS 1.5 LTS, the built-in roles (admin, operator, disable), the role-per-concern pattern, the principle of least privilege, and the production failure modes where role misconfigurations lock the operator out.

The RBAC model

flowchart LR
  U1["User alice<br/>role admin"] --> R1["admin<br/>configure, show, restart, reset"]
  U2["User bob<br/>role operator"] --> R2["operator<br/>show, restart"]
  U3["User charlie<br/>role disable"] --> R3["disable<br/>no access"]
  U4["User dave<br/>role monitor"] --> R4["monitor<br/>show only"]
  R1 --> SYS["VyOS router"]
  R2 --> SYS
  R3 --> SYS
  R4 --> SYS

Each user has exactly one role. Each role defines a set of privileges: which commands the user can run, which configuration trees the user can edit, and which operational commands the user can execute.

Built-in roles

VyOS 1.5 LTS has four built-in roles:

• admin — full access. Can configure, commit, save, rollback, view, restart, reset.
• operator — operational access. Can view (show), restart services, view logs. Cannot edit configuration.
• disable — no access. Cannot log in (the user exists but cannot authenticate).
• user — equivalent to operator on older VyOS versions; aliased to operator in 1.5.

A typical production user mapping:

• The senior network engineer is the admin. They can configure, commit, save.
• The NOC operator is the operator. They can show and restart services but cannot edit configuration.
• A deprecated user (e.g., a former employee) is disable. They cannot log in even if the credentials are still valid.
• The monitoring system may have a user with a custom role (covered below) that can only show specific commands.

Configuring users with roles

configure
set system login user alice authentication plaintext-password '<password>'
set system login user alice role 'admin'
set system login user bob authentication plaintext-password '<password>'
set system login user bob role 'operator'
set system login user charlie authentication plaintext-password '<password>'
set system login user charlie role 'disable'
commit
save

Each user has a username, an authentication method (plaintext password, hashed password, or SSH key), and a role. The role determines the user’s privileges.

Configuring users with SSH keys

configure
set system login user alice authentication plaintext-password '<temp-password>'
set system login user alice authentication public-keys alice@workstation key '<public-key>'
set system login user alice authentication public-keys alice@workstation type 'ssh-ed25519'
set system login user alice role 'admin'
commit
save

The user has both a password (for fallback) and an SSH key (for primary authentication). The SSH key is the preferred method; the password is a fallback in case the key is lost.

The principle of least privilege

The discipline:

• Every user gets the minimum role needed for their job.
• The NOC operator is operator, not admin. They cannot edit configuration; they can only view.
• The monitoring system is a custom role that can only show specific commands (e.g., show system, show interfaces). It cannot read sensitive data.
• The senior engineer is admin. They can edit configuration.

The principle is not about making the operator’s life harder; it’s about reducing the blast radius of a compromised credential. An attacker who steals the monitoring system’s credentials can only read what they’re authorised to read; they cannot push a configuration change.

flowchart TD
  A["Credential compromised"] --> B{"User role?"}
  B -- "monitor<br/>(read-only)" --> C["Attacker can read<br/>system state only"]
  B -- "operator<br/>(show + restart)" --> D["Attacker can read<br/>and restart services"]
  B -- "admin<br/>(full)" --> E["Attacker can read,<br/>edit config, save, lock<br/>everyone out"]

The diagram shows the blast radius: the higher the role, the more an attacker can do with a stolen credential.

Custom roles — the role-per-concern pattern

For more granular control, the operator can define custom roles:

configure
set system login role network-monitor privilege 1
set system login role network-monitor rule 1000 action allow
set system login role network-monitor rule 1000 command 'show'
set system login role network-monitor rule 1010 action allow
set system login role network-monitor rule 1010 command 'monitor'
set system login user monitoring authentication public-keys monitor@prometheus type 'ssh-ed25519'
set system login user monitoring authentication public-keys monitor@prometheus key '<public-key>'
set system login user monitoring role 'network-monitor'
commit
save

The custom role network-monitor allows only show and monitor commands. The monitoring user is bound to this role. The monitoring system can SSH in, run show commands, and exit — but cannot edit configuration.

The role definition uses rules with command patterns. Each rule has an action (allow or deny) and a command pattern (which commands the rule applies to). Rules are processed in order; the first match wins.

How the result is validated

show system login user
show system login role
ssh -i ~/.ssh/id_rsa alice@<host> show configuration
ssh -i ~/.ssh/id_rsa bob@<host> configure set

The first two show the user and role configurations. The third logs in as alice (admin) and reads the configuration. The fourth attempts to edit configuration as bob (operator) — this should be rejected with a permission denied error.

A working RBAC configuration:

• admin user can run all commands.
• operator user can run show and operational commands but cannot edit configuration.
• disable user cannot log in.
• Custom role users can run only the commands in their role’s rules.

vyos@R1:~$ ssh -i ~/.ssh/id_rsa bob@<host> show version
Version: VyOS 1.5-rolling-202408020557
... [OK, operator can show]

vyos@R1:~$ ssh -i ~/.ssh/id_rsa bob@<host> configure
Permission denied (operator role cannot configure).
... [REJECTED, operator cannot configure]

Role auditing

show system login user
show system login role
show log auth.log | match 'sudo|role'

The first shows the user-to-role mapping. The second shows the role-to-rule mapping. The third shows the authentication log with role enforcement events.

The audit must verify:

• Every user has the correct role.
• No user has admin unless they actually need full access.
• Deprecated users are disable, not deleted (preserves the audit trail).
• The role’s rules match the principle of least privilege.

How it fails

The production failure modes a routing engineer must recognise:

• Operator user bound to admin role. The NOC operator has role admin. The operator’s credentials are stolen; the attacker has full access. The fix: bind the NOC operator to role operator.
• Disable role set but credential still valid. A former employee has role disable but their SSH key is still in the configuration. The credential still works on other systems with shared keys. The fix: remove the SSH key.
• Custom role too permissive. A custom role allows show instead of specific commands. The user can read sensitive configuration. The fix: refine the role to specific commands.
• Default admin user (vyos) is the only admin. All operators log in as vyos. There is no per-operator audit trail. The fix: create per-operator admin users; reserve vyos for break-glass.
• Role for monitoring system is admin. The monitoring system has admin credentials; a compromised monitoring host can edit the router configuration. The fix: create a custom role with read-only access.

Rollback

The recovery from a broken RBAC configuration:

• All admins locked out: connect via OOB and modify the role to admin for the break-glass user.
• Custom role too restrictive: connect via OOB and edit the role rules to allow the needed commands.
• Disable role set on the wrong user: connect via OOB and change the role to admin (temporarily) until the user’s role is fixed.

The VyOS configuration rollback (rollback N) restores the previous revision if the RBAC change locks the operator out.

Production discipline

Cross-course references

• XLVII-VyOS-MgmtPlane (vyos-xlvii-01-ssh-hardening, vyos-xlvii-02-api-auth) cover the SSH and API authentication that uses these roles.
• XXVII-Linux-Auth (Linux course) covers the underlying Linux user / role model.
• LIII-VyOS-Security (vyos-liii-01-routing-protocol-authentication) covers the routing-protocol authentication that also uses these users.

Quiz