Hello, my name is Andrew and I tend to get a lot of questions about NetScaler Console. The purpose of this series is to offer some pointers on what it is, what it can offer and why you should take some notice. This is the tenth and a bit post in a set which is designed to cover the top topics that will get you trained up.
Knowledge is power, right? 📖📖📖📖
31 days seems an arbitrary number. Today is all about NetScaler Console Role Based Access Control. Exciting stuff!
How does this normally come up?
I spoke with Customer X, we talked at length about the various NetScaler’s they will be deploying. During the discussion, I typically ask something like this:
As you have a few NetScaler’s and you are looking to have a number of different admins manage these, how would you look to achieve the correct level of granular access control as part of the management function?
There was a tumble weed moment! It became very quiet on the call, has my broadband died?
Oh yeah. This is where I step in and offer some pointers!
The answer is NetScaler Console. The next question is what kinds of admin functions do you have and what are kinds of role do you need to support? This piece will show you how that can be achieved with NetScaler Console and the Service based Console( on-premises or service).
Who would be interested in this?
Any Network Admin with multiple NetScaler’s deployed, or any customer looking at the new Universal hybrid Multi-cloud (UHMC from now on) offering from Cloud Software Group.
UHMC needs NetScaler Console to provide the licensing function to the NetScaler appliances. It is not optional, it's a requirement. One of the big benefits of UHMC is that customers can take a look outside the Citrix bubble and maybe look at new use cases for NetScaler.
Outside the Citrix bubble? That might mean more admins, maybe some different ones….gulp.
Mastering sounds 'heavy'?
Ultimately, this is substack, who would be crazy enough to write technical content on this platform?Â
What kind role based access Control can NetScaler Console offer?
I am glad you asked, interaction is so needed in pieces like this. One of the issues with any environment, is that different people have different skills and as such you might not want Stan having complete access to everything. He doesn’t need it for his role and the last time he was given it, multiple services ‘became broken’. It wasn’t his fault, but maybe this needs some careful planning.
Role based Access Control, RBAC from now on, is designed to provide an environment with number of different levels of access you can use to give people enough access to complete their tasks.
I was talking (over email) recently with Ali. Ali is the network admin and is quite switched on to what his company needs. He did struggle to find how to actually get RBAC running. Hence this post to help people like him.
How is the RBAC structured?
There are four elements that come together to provide RBAC
Users
Groups
Roles
Access Policies
Users
nsroot - The root user (nsroot) has full administrative privileges on the appliance - he wares a cape etc etc. The nsroot user is the super admin of NetScaler Console.
You can create additional users by configuring accounts for them. When you add new users to NetScaler Console, you can define their permissions by assigning the appropriate groups, roles, and policies.
Groups
The magic happens within the group setup, it is easy to miss. In NetScaler Console, a group can have both feature-level and resource-level access. For example, one group of users might have access to only selected NetScaler instances; another group with only a selected few applications, and so on. Choose what is needed.
This is the auth settings, this is where you define which instances(if any) or applications the Group will have access to.
This is a key pane to review!
Roles
In NetScaler Console, each role is bound to one or more access policies. You can define one-to-one, one-to-many, and many-to-many relationships between policies and roles. You can bind one role to multiple policies, and you can bind multiple roles to one policy.
For example, a role might be bound to two policies, with one policy defining access permissions for one feature and the other policy defining access permissions for another feature. One policy might grant permission to add NetScaler instances in NetScaler Console, and the other policy might grant permission to create and deploy StyleBooks and to configure NetScaler instances.
Access policies
Access policies define permissions. A policy can be applied to a single user or group, or to multiple users and multiple groups. Naturally, when you have a few admins, you will look to create groups to keep it simple, who has time for custom permissions for individuals?
NetScaler Console provides four predefined access policies:
adminpolicy. Grants access all NetScaler Console features. The user has both view and edit permissions, can view all NetScaler Console content, and can perform all edit operations. That is, the user can perform add, modify, and delete operations on the resources.
readonlypolicy. Grants read-only permissions. The user can view all content on NetScaler Console, but is not authorized to perform any operations.
appAdminPolicy. Grants administrative permissions for accessing the application features in NetScaler Console. A user bound to this policy can add, modify, and delete custom applications, and can enable or disable the services, service groups, and the various virtual servers, such as content switching, cache redirection, and HAProxy virtual servers.
appReadOnlyPolicy. Grants read-only permission for application features. A user bound to this policy can view the applications, but cannot perform any add, modify, or delete, enable, or disable operations.
Using the combination of Users/Roles/Groups/Policies there is quite a bit of flexibility to setup some granular controls to suit most deployments.
If it is not clear, here is a scenario.
Bob and Alice have been using NetScaler Console Service in the scenarios for the last few days.Â
Alice and Bob have been using NetScaler Console for the management of their NetScaler. Stan, the Application man and Bridget who runs his team do need a level of access to the NetScalers. By using some careful access policies tied to some specific group permissions Alice can give them the control that they need to do their jobs.
This also helps Bob and Alice, as they are not ‘checking’ things for the App team. They are delegated to get on and manage the application servers themselves.
Happy days, as this allows Bob and Alice to focus time on other tasks that are important to Acme.
The Call to Action
Let me know if this piece raises any questions/comments, drop them into the space below. I will endeavour to answer directly or update the post to better address the question(s).
Summary
Buckle up. The NetScaler Console is the best tool for many different jobs when working in conjunction with the NetScaler Appliance. They are the perfect tag team. 🤼. The NetScaler Console can offer a one-stop shop to see all your appliances from one place, and deploy and update them and track those updates in a consistent way
Let me show you how to make the most of it!
Have a good one.