Role Based Access Control
The product features a Role-Based Access Control (RBAC) mechanism to manage user permissions effectively. This system ensures that users have access only to the functions necessary for their roles, enhancing both security and operational efficiency. The product supports two static roles: admin and monitor.
The admin role has full access to all system configurations and management functionalities.
The monitor role provides read-only access, allowing users to view system information and monitor operations without making any changes.
Users can define new accounts with one of the available roles and modify the role of existing users as needed.
admin@nvos
:~$ nv set system aaa user new_monitor role monitor
The roles of the default accounts (admin and monitor) cannot be changed
In addition to the default roles that NVOS provides, you can create your own roles to restrict authorization, giving you more granular control over what a user can manage on the switch. For example, you can assign a user the role of network manager and provide the user privileges for interface management, service management and system management. When the user logs in and executes an NVUE command, NVUE checks the user privileges and authorizes the user to run that command.
Elements of Custom Role-Based Access Control
Custom role-based access control consists of the following elements:
Element | Description |
Role | A virtual identifier for multiple classes (groups). You can assign only one role for a user. For example, for a user that can manage interfaces, you can create a role called |
Class | A class is similar in concept to a Linux group. Creating and managing classes is the simplest way to configure multiple users simultaneously, especially when configuring permissions. A class consists of:
|
Action | The action for the class: |
You can assign a maximum of 64 classes to a role.
You can configure a maximum of 128 command paths for a class.
When you configure a command path, you allow or deny a specific schema path and its children. For example the command path
/interface/
allows or denies access to all interface commands, whereas the command path/interface/eth0
allows or denies access to eth0 commands.
Example Role Permissions
The following example describes the permissions for a role (role1
) that consists of three classes: class1
, class2
, class3
.
class1 has the allow
class action and the following command path permissions:
Command Path | Permissions |
|
|
| ro |
class2 has the allow
class action and the following command path permissions:
Command Path | Permissions |
|
|
|
|
/vrf/ | rw |
class3 has the deny
class action and the following command path permissions:
Command Path | Permissions |
| ro |
The following table shows the permissions for a user assigned the role role1
. In the table, R is read only (RO), W is write, and X is action (ACT).
Path | Allow | Deny | Permissions |
| RWX | Implicit deny | |
| RWX | Implicit deny | |
All unspecified paths are implicit deny | |||
| RWX | The permissions specified | |
| RWX | The permissions specified | |
All unspecified children of | RWX | ||
All unspecified children of | RWX | ||
| R | WX | The permissions specified |
| R | WX | Inherited from parent |
| R | WX | Inherited from parent |
All unspecified children of | R | WX | |
/ib/ | RX | W | The permissions specified |
/ib/ibdiagnet | RX | W | Inherited from parent |
| RW | X | The permissions specified |
All unspecified children of | RW | X |
To assign a custom role to a user account:
Create a role and classes for the role.
Assign the action (allow or deny) for each class.
Add command paths and permissions for each class.
Assign a role to a user.
You assign a custom role to an existing user account.
The following example creates and assigns the three classes described above for role role1
.
class1
has permissions to manage all interfaces and to show all the tree of ib:
admin@nvos
:~$ nv set system aaa role role1 class
class1
admin@nvos
:~$ nv set system aaa class
class1 action allow
admin@nvos
:~$ nv set system aaa class
class1 command-path /interface
/ permission all
admin@nvos
:~$ nv set system aaa class
class1 command-path /ib/ permission ro
admin@nvos
:~$ nv config apply
class2
has permissions to show system commands, perform actions on ib cmd and show and set configuration of vrf:
admin@nvos
:~$ nv set system aaa role role1 class
class2
admin@nvos
:~$ nv set system aaa class
class2 command-path /system/ permission ro
admin@nvos
:~$ nv set system aaa class
class2 command-path /ib/ permission act
admin@nvos
:~$ nv set system aaa class
class2 command-path /vrf/ permission rw
admin@nvos
:~$ nv config apply
class3
denies permission of ro
on eth0 interface, this explicit definition on the child causes it to stop inheriting the parent read and action permissions.
admin@nvos
:~$ nv set system aaa class
class3 action deny
admin@nvos
:~$ nv set system aaa class
class3 command-path /interface
/eth0/ permission ro
admin@nvos
:~$ nv set system aaa role role1 class
class3
admin@nvos
:~$ nv config apply
The following command assigns user ib_user
the role role1
:
admin@nvos
:~$ nv set system aaa user ib_user role role1
admin@nvos
:~$ nv config apply
To delete a custom role and all its classes, you must first unassign the role from the user, then delete the role:
admin@nvos
:~$ nv unset system aaa user ib_user role role1
admin@nvos
:~$ nv unset system aaa role role1
admin@nvos
:~$ nv config apply
To delete a class from a role, run the nv unset system aaa role <role> class <class>
command:
admin@nvos
:~$ nv unset system aaa role role1 class
class2
admin@nvos
:~$ nv config apply
To show the user accounts configured on the system, run the NVUE nv show system aaa user
command.
admin@nvos
:~$ nv show system aaa user
Username Full-name Role state
-------- -------------------- ------- -------
admin System Administrator admin enabled
ib_user role1 enabled
monitor System Monitor monitor enabled
To show information about a specific user account including the role assigned to the user, run the NVUE nv show system aaa user <user>
command:
admin@nvos
:~$ nv show system aaa user ib_user
operational applied
------------------ ----------- -------
state enabled enabled
role role1 role1
full-name
password * *
hashed-password *
ssh
[authorized-key]
To show all the roles configured on the switch, run the NVUE nv show system aaa role
command:
admin@nvos
:~$ nv show system aaa role
Role Name Class
--------- --------
admin nvaction
nvapply
sudo
monitor nvshow
role1 class1
class2
class3
To show the classes applied to specific role, run the nv show system aaa role <role>
command:
admin@nvos
:~$ nv show system aaa role role1
operational applied
------- ------------------------ -------
groups adm,class1,class2,class3
[class
] class1 class1
[class
] class2 class2
[class
] class3 class3
To show all the classes configured on the switch, run the nv show system aaa class
command:
admin@nvos
:~$ nv show sys aaa class
Class Name Command Path Permission Action
---------- ---------------- ---------- ------
class1 /ib/ ro allow
/interface
/ all
class2 /ib/ act allow
/system/ ro
/vrf/ rw
class3 /interface
/eth0/ all deny
nvaction / act allow
nvapply / rw allow
nvshow / ro allow
sudo / all allow
To show the configuration and state of the command paths for a class, run the nv show system aaa class <class>
command:
admin@nvos
:~$ nv show system aaa class
class3
applied
-------------- ----------------
action deny
[command-path] /interface
/eth0/