Table of Contents:
- Introduction
- Quick Refresher for RBAC rules for APIC
2.a.Defining the Provider
2.b.Creating Login Domain
2.c.Defining a role
2.d.Defining a Security Domain
2.e.Tie in Tenant to Security Domain
2.f. Configure AV Pairs in Radius Server
2.g. Testing out the configuration - RBAC for NDO
3.a. Create Login Domain and tie to Radius Server
3.b. On NDO, associate Tenants with Remote User
3.c. Testing out Results from NDO
3.d. Creating admin user with all privileges and admin user with read only privileges
3.e. Creating approver/deployer users - References
Introduction
In this article, I will go over RBAC for Nexus Dashboard Orchestrator with examples for Radius AV-Pairs needed for your use case. Nexus Dashboard Orchestrator is a app that runs on Nexus Dashboard Cluster (k8s cluster). As such the RBAC server (remote server for authentication) is defined on the Nexus Dashboard.
📙 One item to note is that Nexus Dashboard RBAC and ACI APIC & Cloud Network Controller (formerly cAPIC) RBAC are totally 2 different domains. Nexus Dashboard RBAC defines authentication/authorization parameters for Nexus Dashboard applications and APIC/CNC RBAC defines authentication/authorization parameters for APIC/CNC. When you onboard a site from Nexus Dashboard, you have to give it the user credentials for the Site (APIC/CNC). The user and credentials that you give can be local user defined on APIC/CNC or remote user (defined on Radius, etc for APIC/CNC login). When onboarding a site to Nexus Dashboard you shoud give it an admin equivalent user such that Nexus Dashboard Orchestrator is allowed to make necessary api calls to the APIC/CNC. The user, user-role and user-profile you define for Nexus Dashboard will be used for authentication/authorization on Nexus Dashboard Orchestrator while the user, domain/RBAC-Roles (privilege) you define in APIC will define what users can do on APiC.
Quick Refresher for RBAC rules for APIC
In this section I will give you a quick refresher on how RBAC roles for APIC is configured.
Defining the Provider
Step1: The first thing you do in APIC is define a provider for Remote Authentication server such as Radius as shown below.
Figure 1: Creating Radius Provider in APIC
Details of my Radius server parameters are shown below.
⚠️ Note that my Radius server is using UDP port 10000, normally the default port is UDP 1812
Figure 2: Details of my Radius Server
Creating Login Domain
Step 2: Next, you create a Login Domain typing in the Radius Server. In my example below, I named the login domain dmzrad
Figure 3: Creating the login domain
Details of the login domain tying in to the radius server is shown below.
Figure 4: Details of login domain
Defining a role
Step 3: Next, you create a Role in APIC as shown below. Let’s concentrate on the role for custom-privilege.
Figure 5: defining a custom-privilege role in APIC
This Role is given privileges as shown below.
Figure 5: Details of Role defined
Defining a Security Domain
Step 6: Next, you define a Security Domain. There are already some default security domains like all, common, mgmt. In my example, I’ve defined a security domain called Tenant1-SD
📙 Security Domain "all" is by default associated with every Tenant
Figure 6: Defining Secuirity Domain called Tenant1-SD
Tie in Tenant to Security Domain
Step 7: Next you tie in the object to the security domain. In my example below, I tied in Tenant1-SD to Tenant1. You will have to do this from the Tenant/Policy
Figure 7: Tying in the Security Domain to the Tenant object
Configure AV Pairs in Radius Server
All your configuration on the APIC side is done. Now, we will need to configure Radius Server with a user such that user sends the correct AV pair back to APIC when that user tries to login.
In my example below (using Free Radius), I’ve created 2 users:
- tenant1-rw: This will have full access to Tenant1
- tenant1-ro: This will have read-oly access to Tenant1
Figure 8: 2 users configured in Radius Server.
Let’s concentrate on line 2 of each of these users. Further let’s concentrate on the 1st part (boxed) part of Line2.
- The first line is the encrypted password
- The avpairs after the comma on the boxed part is for NDO. That way we can combine both the AVpairs for APIC and NDO in one line for ease of administration.
- The third line is for the IPN/ISN routers and not relevant in this discussion
- The fouth line are for CSR routers used for Cloud Integration. You can also ignore this for this discussion.
Let’s now discuss the AVPair format. AVPairs typically have this format:
shell:domains=<domain>/<writeRole1>|<writeRole2>/<readRole1>|<readRole2>
The first part of this is:
shell:domains=<domain>
This is where you would put in the value of domain. It could be all, or in our case we used "Tenant1-SD"
Cisco-AVPair = "shell:domains =Tenant1-SD
The second part of this is what’s inbetween the 1st 2 forward slashes "/ " :
- What’s between the 1’st 2 forward slashes are roles for "write" privilege
- If you had more than one role you wanted for "write" privilege, you would separate them with the pipe " | " symbol
In our example, for tenant1-rw we have custom-privilege in between the 1st 2 forward slashes. So, custom-privilege will be given write access.
/custom-privilege/
The third part of this is what’s after the 1st 2 forward slashes "/ " :
- What’s after the 1’st 2 forward slashes are roles for "read" privilege
- If you had more than one role you wanted for "read" privilege, you would separate them with the pipe " | " symbol
In our example, for tenant1-ro we have custom-privilege afer the 1st 2 forward slashes. So, custom-privilege will be given read access.
📙 There is nothing inbetween the 1st 2 slashes, so, nothing gets write access
//custom-privilege
Testing out the configuration
Let’s first try with user "Tenant1-rw"
Below, I log in to the APIC with "Tenant1-rw". Below you will see that I have typed in tenant1-rw in the User-ID space and chosen the login domain that we had created "dmzrad"
Figure 9: Loging in to APIC with user Tenant1-rw
Once you login, you will now only see Tenant1 only.
As you can see I can create a VRF, in Tenant1, since my user has "write" privilege.
Figure 10: Tenant1-rw user has write privilege
Let’s now try with user "Tenant1-ro"
Below, I log in to the APIC with "Tenant1-ro". Below you will see that I have typed in tenant1-ro in the User-ID space and chosen the login domain that we had created "dmzrad"
Figure 9: Loging in to APIC with user Tenant1-ro
Once you login, you will now only see Tenant1.
As you can see I cannot create a VRF, in Tenant1, since my user has "read-only" privilege. "Create VRF" is greyed out.
Figure 10: Tenant1-ro user has read-only privilege
RBAC for NDO
Create Login Domain and tie to Radius Server
Step1: On Nexus Dashboard define your login domain and radius server. In the example below, I’ve created the login login domain called "raddb" which has my radius server tied to it.
Figure 11: Defining Login Domain and tying to Radius Server in Nexus Dashboard
Details of login domain is shown below.
📙 I’ve used UDP port 10000 for my radius server, because my radius server is listening on that. Default value is UDP 1812.
Figure 12: Details of login domain
Creating AVPairs on Radius Server
As explained in Section 2.f, we will use the same Radius Config that was shown there. However, we will concentrate on the later part of line 2 which is the NDO AV Pairs.
Figure 13: AV Pairs for NDO
Let’s concentrate on line 2 of each of these users. Further let’s concentrate on the later part (boxed) part of Line2.
- The first line is the encrypted password
- The AVPairs after the comma on the boxed part is for NDO. Before the comma is the AVPairs for APIC. That way we can combine both the AVPairs for APIC and NDO in one line for ease of administration.
- The third line is for the IPN/ISN routers and not relevant in this discussion
- The fouth line are for CSR routers used for Cloud Integration. You can also ignore this for this discussion.
Let’s now discuss the AVPair format. AVPairs typically have this format:
shell:domains=<domain>/<writeRole1>|<writeRole2>/<readRole1>|<readRole2>
The first part of this is:
shell:domains=<domain>
This is where you would put in the value of domain. In the case of NDO, the only supported value (as of this writing) is all.
shell:domains=all
The second part of this is what’s inbetween the 1st 2 forward slashes "/ " :
- What’s between the 1’st 2 forward slashes are roles for "write" privilege
- If you had more than one role you wanted for "write" privilege, you would separate them with the pipe " | " symbol
In our example, for tenant1-rw we have tenant-policy and app-user in between the 1st 2 forward slashes. So, tenant-policy and app-user will be given write access.
/tenant-policy|app-user/
📙 The roles like tenant-policy and app-user are pre-defined on ND. You cannot create your own roles. There are 9 pre-defined roles in total as you can see from CCO Documentation: Cisco Nexus Dashboard User Guide,Release 2.1.x.
Figure 14: 9 pre-defined roles in ND for NDO
The third part of this is what’s after the 1st 2 forward slashes "/ " :
- What’s after the 1’st 2 forward slashes are roles for "read" privilege
- If you had more than one role you wanted for "read" privilege, you would separate them with the pipe " | " symbol
In our example, for tenant1-ro we have tenant-policy and app-user afer the 1st 2 forward slashes. So, tenant-policy and app-user will be given read access.
📙 There is nothing inbetween the 1st 2 slashes, so, nothing gets write access
all//tenant-policy|app-user
On NDO, associate Tenants with Remote User
The next step is to login with some admin user on ND, open the NDO app and associate the relevant Tenants with the remote users.
As you can see below, I have associated both users "tenant1-rw" and "tenant1-ro" with Tenant1
Figure 15: Associating Tenant1 with both users "tenant1-rw" and "tenant1-ro"
⚠️ Before "tenant1-rw" and "tenant1-ro" shows up for association, you will need to login to ND with each of these users.
Testing out Results from NDO
First, let’s login to ND as user "tenant1-rw"
Figure 16: logging in to ND with user "tenant1-rw"
Once logged in, go to NDO. Here you will see a limited number of options.
For instance from Application Managemment you will not get the option to create a new Tenant as shown below.
Figure 17: tenant1-rw user is not able to create new tenant
Also, notice that even though I have more schemas, only Tenant1-Schema is showing up. That is because only Tenant1-Schema is assoiated in user profile with user tenant1-rw
Figure 18: Only schemas associated with "Tenant1" show up
Now, let’s create and deploy VRF1 from NDO (with "tenant1-rw" user ). Once done you will be able to see that the VRF deployed.
Figure 19: VRF Deployment from NDO with "tenant1-rw" user
Now, let’s login to ND as user "tenant1-ro"
Now, let’s go to NDO logged in as "tenant1-ro" user. Once logged in, you will see that the option to create a new VRF is not present. This user is also not allowed to delete anything That is because this user only has read permissions.
Figure 20: User "tenant1-ro" has no options to create/modify/delete
If user "tenant1-ro" tries to clone a template you will see that this user will be denied access
Figure 21: User "tenant1-ro" cannot clone template
Creating admin user with all privileges and admin user with read only privileges
Following the above logic you can create admin user with all privileges and admin user with read only privileges. The Radius AVPairs configured are shown below. The underlined AVPairs are for the write and read-only users.
Figure 22: Admin User with Write priveleges and Admin user with read-only priveleges
Creating approver/deployer users
Sometimes you may want some employees to create configuration, but not be able to deploy the configuration. Someone else will need to doublecheck the configuations suggested and approve or deny the configurations. For that purpose NDO supports approver/deployer roles.
- A user with write permission can create the configuration.
- One or more approvers (as desired) can approve the configuration
- Deployer can deploy or deny the configuration
In the below example, I have configured a user in Radius called approver and a user called deployer
Figure 23: AVPairs for Approver/Deployer
After creating the roles, you will need to go to NDO/Infrastructure/Change Control and enable Change Control and specifty the number of approvers.
Figure 24: Enabling Change Contol on NDO
Next the user cofigures/makes changes and sends for approval
Figure 25: User creates/makes changes and sends for approval
Next, the approver logs in and sees that there are some approvals pending
Figure 26: Approver sees Pending Approval
Approver can look at details,approve or deny the change.
Figure 27: Approver looks at details
Figure 28: Approver views changes
Figure 29: Approver views changes in graphical/json view
Figure 30: Approver approves or denies
Next, deployer logs in and deploys or denies
Figure 31: Deployer deploys or denies
References
CCO Documentation: Cisco Nexus Dashboard User Guide,Release 2.1.x.