Role Based Access Control in IOS

I don’t believe this is well known: Cisco IOS has Role Based Access Control (RBAC) which can be used to create and assign different levels of privileged access to the device. Without RBAC there are two access levels in IOS: a read-only mode with limited access to commands and no ability to modify the running config (also called privilege level 1) and enable mode with full administrative access. There is no middle ground; it’s all or nothing. RBAC allows creation of access levels somewhere between nothing and everything. A common use case is creating a role for the first line NOC analyst which might allow them to view the running config, configure interfaces, and configure named access-lists.

A “role” in IOS is called a “view” and since views control which commands are available in the command line parser, they are configured under the parser. A view can be assigned a password which allows users to “enable” into the view. More typically, the view is assigned by the RADIUS/TACACS server as part of the authorization process when a user is logging into the device.

A view is configured with the “parser view <view-name>” config command after which commands are added/removed to/from the view.

include-exclusive – makes <command> exclusive to this view and not usable by other views

all – enables use of all sub-commands of <command> (see example below)

A password can be assigned to the view by using the “secret” command:

(config-view)# secret <password>

To manually test a view, log in to the device and use the command “enable view <view-name>”. This will place your session in the view with access only to those commands included in the view. You can always confirm which view you’re in by using the “show parser view” command. For what it’s worth, there is a default view called “root” which is the equivalent to enable level access.

Here’s an example of a view for the NOC users that allows viewing the running config, configuring interfaces, and configuring named access-lists:

The command “commands exec include show” is automatically added to the config in order to allow the user to run “show running-config”. Same with “configure” and “ip”; each element of the command is added separately, it’s just how the parser works

In order to allow the user to shut/no shut an interface, they first have to be allowed to get into config mode, then allowed to get to interface config mode. The relevant commands are included in the view.

The “all” option is specified on the “ip access-list” and “interface” lines. Without “all”, the parser would be expecting the user to run “ip access-list” as a literal command. However there is no such command. Real commands are things like “ip access-list standard BLOCK_STUFF”. The “all” option allows all subcommands of “ip access-list” and all interfaces after the command “interface”.

Now to test it. In this example, I’m not using RADIUS or TACACS and instead will manually enable into the view.