In this guide, we’ll walk through some of the more advanced RBAC settings that can be applied to users and their roles. These additional settings can allow an Avi administrator to limit users with specific labels so they can only see applications they’re approved to see. The example we’ll use below is on the type of application, production or non-production. One user will have access to everything, the other user will have access to only non-production.
See the formal KB
Software Versions used in this demo
| Software | Version |
|---|---|
| Avi Controller & Service Engines | 22.1.5 |
Create Local Users in Avi
With a new Avi install, navigate to Administration -> Accounts -> Users. You should see just the default admin username created.
Application Super User
Let’s create a new user. For this first one, we’ll create an application super user who will have full access to all the applications, production and non-production. They will be able to create, edit, and delete the objects of these applications (Virtuals, Pools, Servers)
Click Create.
Name and username are both appsuperuser, and I used generate to generate the simple password. For User Profile, select the default “Default-User-Account-Profile”
Since we don’t have the appsuperuser role created yet, you can just save the user as is.
Application Junior User
Next we’ll create a junior application user. Again the goal here is to limit this user to only see applications that are non-production. We wouldn’t want them accidentally modifying or deleting a production Application.
Name and username are both appjunioruser. Create or Generate a password and use the same default user profile.
Create Roles in Avi
Navigate to Administration -> Accounts -> Roles. Click Create.
Super-User Role
The following images will show the settings I’ve applied to the super-user role. They are the EXACT same settings from the system default “Application-Admin” role.
As you can see for the Label Filters, I’ve left them blank. You can create this role 2 different ways.
- The first is as shown above where you don’t add any filters, so essentially this role will be able to see ALL applications whether they have a label or not.
- The alternative method is where you can add each of the various labels that you will have on your applications. The only tricky part with the latter method is you will have to always update this role with any new labels added to your applications, additionally there is a limit of 4 filters to a role, and 4 labels to an object.
Junior-User Role
The following images will show the settings I’ve applied to the super-user role. They are the same settings from the system default “Application-Admin” role, with the EXCEPTION that any objects that were No Access were moved to Read access. You will receive an error if you create a role with No Access objects and a filter. Filters disallowed for Roles with no access privileges
In the section “Label Filters” click ADD.
Add a label named “environment”. With key “app” and values “non-production”
You will see the label filter added, save the role.
Assign the Roles to the Users
Ok now that we have the 2 local users created and both Roles created. Let’s apply the roles to the users.
Navigate back to Administration -> Accounts -> Users
Click edit on the appsuperuser user and apply the role “super-user”.
Do the same thing for appjunioruser. Apply the role “junior-user”.
Apply a label to the Virtual Service
There is 1 last step needed before we can test the user accounts and their access, and it is to apply a label on the virtual service.
Navigate to Applications -> Virtual Services.
I’ve pre-created a virtual service as shown below. If you have not done this yet, please see my other guides on how to create a virtual. Click edit on the virtual.
On the Advanced tab, you will see the “Role-Based Access Control (RBAC)” section. Click ADD.
Key: app
Values: production
Click Save.
Test the Users
Super User
Let’s finish up the guide by doing a proper test of each user. I’d recommend always testing out your new roles before you productionalize them.
Login with the appsuperuser account. Remember, with this role we expect to see all the existing applications, and have the access to create new applications and delete existing ones.
Navigate to Applications -> Virtual Services.
In my example above I’ve created a virtual in advance, just to show you that you will be able to see and edit it. Additionally, the “Create Virtual Service” button is available.
Pools above, are editable. You are able to navigate into the pool and look at the configuration.
On the infrastructure side, I can see the settings of the Clouds, but unable to modify them.
Feel free to play around in other sections or tenants.
Application Admin
Login with the appjunioruser account. Remember, with this role we expect to only see non-production objects. So if an object is labeled something other than “app=non-production” then we should not see it. Correct? Let’s test it out.
Navigate to Applications -> Virtual Services.
So as you can see above, we don’t see the existing “vs-1”. This is expected since that particular VS had a label of “app=production”. We do have the ability to create new virtual services, because this is an application admin level role. The user can create their own objects, but can’t modify or delete any of the applications that are not labeled “non-production”.
Let’s check out the pools…
Ok what’s going on here? Why are we able to see the pool but not the virtual š
It is because the pool has it’s own set of labels, and since no labels were set, it will be visible to all roles that have at least Read access to Pools.
See above, no labels were set on the pool, thus the junior user was able to view and edit the pool.
So the corrected statement from above is this: A user with an attached role that has filters will only see the application objects that have matching labels, AND, any application object that has no labels set.
Labels and Filters in the API
I love automation in general. So for that reason I’ll try and throw some tidbits about the API and filtering when I can.
Roles
You can view the roles in the API using the following URL: https://avi-controller.home.lab/api/role/?name.in=super-user
name.in – does a search through the role names to see if they contain the values. You can add multiple, comma separated. Example below.
https://avi-controller.home.lab/api/role/?name.in=super-user,junior-user
{
"count": 2,
"results": [
{
"_last_modified": "1699892766181903",
"allow_unlabelled_access": true,
"name": "super-user",
"privileges": [],
"tenant_ref": "https://avi-controller.home.lab/api/tenant/admin",
"url": "https://avi-controller.home.lab/api/role/role-dd2e15b5-dfaa-4cbb-b80d-69a747325ab1",
"uuid": "role-dd2e15b5-dfaa-4cbb-b80d-69a747325ab1"
},
{
"_last_modified": "1699897142343991",
"allow_unlabelled_access": true,
"filters": [
{
"enabled": true,
"match_label": {
"key": "app",
"values": [
"non-production"
]
},
"match_operation": "ROLE_FILTER_EQUALS",
"name": "environment"
}
],
"name": "junior-user",
"privileges": [],
"tenant_ref": "https://avi-controller.home.lab/api/tenant/admin",
"url": "https://avi-controller.home.lab/api/role/role-11daf00c-060b-458e-92f5-7d8515237412",
"uuid": "role-11daf00c-060b-458e-92f5-7d8515237412"
}
]
}Virtual Service
With virtual service you can hit the API and provide the label and keys that you would like to test. Example: https://avi-controller.home.lab/api/virtualservice/?label_key=app&label_value=production
This will show you all the virtuals with those particular labels. Technically all you will need is the “label_value” since it looks through the virtual for either of those use cases, and if either are found, it will populate the virtual in the response.
Example: https://avi-controller.home.lab/api/virtualservice/?label_value=production
{
"count": 1,
"results": [] // 1 item
}Example: https://avi-controller.home.lab/api/virtualservice/?label_value=non-production
{
"count": 0,
"results": []
}