In this tutorial I’ll demonstrate how easy it is to create new local users in Avi and apply custom RBAC settings to them.
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.
Read-Only User
Let’s create a new user. For this first one, we’ll create a Read-Only user to demonstrate a user’s restricted access. The goal of this user and role will be to give a user access to Avi to see pretty much everything. They can see system settings, operational settings, logs, applications, health checks, etc. They can see everything, but they won’t be able to modify anything.
Click Create.
Name and username are both readonly, 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 Read-Only role created yet, you can just save the user as is.
Application User
Next we’ll create an application user. We want this user to be able to edit their own applications. Things like virtual service configuration, pool and server configuration, health monitors, etc. However, we don’t want them modifying any system level settings, or the infrastructure itself.
Name and username are both appadmin. Create or Generate a password and use the same default user profile.
Create Roles in Avi
Read-Only Role
Navigate to Administration -> Accounts -> Roles. Click Create.
As you can see in the image above I named the new role “readonly” and I set ALL of the objects to Read. There are 3 access settings for the standard RBAC in Avi. An object can either be Write, Read, or No Access. So since this user needs to have just Read-Only access, we can set all of the objects in this role to Read. Save the role
Application User
So remember the goal for this role was to give the user access to their applications, but not for system and infrastructure level settings.
Conveniently Avi has already created a default role for this use case, Application-Admin.
If you look through the the various settings of this Role, you will see that it enables to user to modify and create applications and their associated objects like Pools, Pool Groups, Health Monitors. But it limits their access to do administrative tasks or modify any important infrastructure settings.
For this use case I will be assigning our “appadmin” to use this specific Role. However, in production environments, best practice would be to not use the default roles, and instead create a new role that mimics the settings of this role.
Assign the Roles to the Users
Ok now that we have the 2 local users created, and both Roles created (the Application-Admin is a default role), we can apply them to the users.
Navigate back to Administration -> Accounts -> Users
Click edit on the appadmin user.
Set the Roles for all Tenants to “Application-Admin” and click save. Do the same for the readonly account.
Test the Users
Read-Only
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 readonly account
Navigate to Applications -> Virtual Services.
In my example above I’ve created a virtual in advance, just to show you that you will not be able to edit it. Additionally, the “Create Virtual Service” button is not available.
Pools above, are not editable. However, you are able to navigate into the pool and look at the configuration. See below.
Same 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
Ok, we know read-only works, let’s test out the appadmin user.
Navigate to Applications -> Virtual Services. You will see the “Create Virtual Service” button as well as an edit button on any virtuals that were previously created.
Same with Health Monitors. I can edit the existing, and create new ones. You might be thinking “Hey, I don’t want my application admin modifying globally used health monitors.” We have a fix for that, tenants. See my guide on tenants.
And onto the infrastructure side, i’m unable to modify anything, as expected.
Conclusion
The advanced RBAC available in Avi out of the box is quite impressive. For most enterprises, the RBAC and tenant capabilities should provide ample functionality to limit certain segments of users from various CRUD operations.