Understanding RBAC for Nexus Dashboard Orchestrator

Posted on by Soumitra Mukherji

Table of Contents:

  1. Introduction
  2. 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
  3. 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
  4. 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.
file
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
file
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
file
Figure 3: Creating the login domain

Details of the login domain tying in to the radius server is shown below.
file
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.

file
Figure 5: defining a custom-privilege role in APIC

This Role is given privileges as shown below.
file
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

file
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
file
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

file
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"

file
Figure 9: Loging in to APIC with user Tenant1-rw

Once you login, you will now only see Tenant1 only.
file

As you can see I can create a VRF, in Tenant1, since my user has "write" privilege.
file
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"

file
Figure 9: Loging in to APIC with user Tenant1-ro

Once you login, you will now only see Tenant1.
file

As you can see I cannot create a VRF, in Tenant1, since my user has "read-only" privilege. "Create VRF" is greyed out.
file
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.
file
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.

file
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.
file
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.

file
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

file
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"
file
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.
file
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

file
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.
file
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.

file
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

file
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.
file
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
file
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.
file
Figure 24: Enabling Change Contol on NDO

Next the user cofigures/makes changes and sends for approval
file
Figure 25: User creates/makes changes and sends for approval

Next, the approver logs in and sees that there are some approvals pending

file
Figure 26: Approver sees Pending Approval

Approver can look at details,approve or deny the change.
file
Figure 27: Approver looks at details

file
Figure 28: Approver views changes

file
Figure 29: Approver views changes in graphical/json view

file
Figure 30: Approver approves or denies

Next, deployer logs in and deploys or denies
file
Figure 31: Deployer deploys or denies

References

CCO Documentation: Cisco Nexus Dashboard User Guide,Release 2.1.x.

Go To TOP

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.