Access Control Management (ACM) and Role-Based Access Control (RBAC)
Role-based Access Control (RBAC) is a method of restricting access to part of the configuration to authorized users. RBAC allows an administrator to define the rules for a group of users that restrict which commands users of that group are allowed to run.
RBAC is performed by first creating a group assigned to the Access Control Management (ACM) rule set, adding a user to the group, creating a rule set to match the group to the paths in the system, then configuring the system to allow or deny those paths that are applied to the group.
Users are allowed to be in one of three class of users with defined privilege levels:
Operator—Allowed to execute commands that are defined in the DANOS CLI. Not allowed to into config mode.
Administrator—Allowed to execute arbitrary Linux commands in addition to commands that are defined by the DANOS CLI and to enter configuration mode.
Superuser—Allowed to execute commands with root privileges through the
sudo
command in addition to having administrator class privileges.
By default, all users that are defined to be in the superuser or the administrator class belong to a common group called vyattacfg. This group allows a rule set to be defined that pertains to both the superuser and administrator classes without defining two group matches. The operator class users belong to the vyattaop group.
DANOS allows a superuser to create new groups based on your requirements. We recommend creating a group with the highest level of privileges, called a security group. A superuser can set rules so that only members of the security group are allowed to modify the ACM and login information. This prevents administrators from inadvertently compromising the system image or the ACM list.
Path matching
System configuration is modelled after a tree structure and enables the user to filter any path of that tree. The system supports only absolute addressing that begins with/as the root and uses the wildcard operator (*) as the path language.
Operational mode paths are absolute and do not match their children if a wildcard operator (*) is not included at the end of the path. Therefore, not using the wildcard operator restricts the user to specific commands.
In the following example, rule 1 restricts the use of the show command to only show interfaces and rule 2 denies all other show commands.
rule 1 {
action allow
path "/show/interfaces"
}
rule 2 {
action deny
path "/show/*"
} |
Example of a rule set in operational mode
Operational mode has a rule set like the configuration mode that allows administrators to specify which operation mode commands a user is allowed to run. For example, as a protocol administrator, the user needs to execute only the show interfaces and show ip families of commands and, therefore, should not be allowed to run other administrative actions.
To define the operation mode rules for the protocol administrator group (protoadmin), perform the following steps in configuration mode.
Create a rule allowing all operations on /show/ip for the protoadmin group.
danos@R1# set system acm operational-ruleset rule 10 action 'allow'
danos@R1# set system acm operational-ruleset rule 10 command '/show/ip/*'
danos@R1# set system acm operational-ruleset rule 10 group 'protoadmin' |
Create a rule allowing all operations on /show/interfaces for the protoadmin group.
danos@R1# set system acm operational-ruleset rule 20 action 'allow'
danos@R1# set system acm operational-ruleset rule 20 command '/show/interfaces/*'
danos@R1# set system acm operational-ruleset rule 20 group 'protoadmin' |
Create a rule allowing all operations on /configure for the protoadmin group.
Deny all operations on all other paths for the protoadmin group.
The following example shows the operational mode rule set that is configured above.
The following example shows system login
information regarding the protoadmin group with a user called john as a member of that group.
Example minimal RBAC configuration