In the previous blog post, http://blogs.citrix.com/2011/12/26/using-role-based-access-controlrbac-to-securely-manage-the-netscaler-configuration/ We had looked in to how to configure the users and cmdspec so that tighter administration control can be enforced in Netscaler. In this blog, we will see a special use case to enforce tighter control in Load balancing virtual server.

In today’s Application centric world the ADC entities are also defined based on Application and it is represented by an endpoint LB/CS vserver on NetScaler. Every Application has defined App owner and though different Apps belong to same Enterprise, ownership remains distinct. This means that one App owner should not be allowed to access to alter resources for other App and vice-versa. Thus we need to have a model to allow a RBAC user to bind and unbind services to the vserver and change particular vserver parameters only. The RBAC user should be allowed to do this only for the targeted vserver and there should be restriction on other vservers. The rationale behind allowing both bind/unbind commands along with set command is blocking either one of them won’t have much impact as the user can make the vserver go down with any one of the commands (bind/unbind or set) itself.

This can be enforced using the below command spec,

(^(bind|unbind)\s+lb\s+vserver\s+v1\s+(s1|s2).*$)|(^show\s+lb\s+vserver(\s+v1|)$)|(^show\s+service(\s+(s1|s2)|)$)|(^set\s+lb\s+vserver\s+v1.*)

which is tested in 9.3 and 10.0 Netscaler releases.

I will go over the steps below on how to arrive at this cmdspec.

Let’s consider the vserver name as v1 and service name as s1 and s2. The bind/unbind command need to be allowed only for vserver v1 for services s1 and s2. It is covered through (^(bind|unbind)\s+lb\s+vserver\s+v1\s+(s1|s2).*$).

In GUI, we need to display the vserver and service so that bind/unbind/set operations can be performed on that. The display of service and vserver is achieved by (^show\s+lb\s+vserver(\s+v1|)$)|(^show\s+service(\s+(s1|s2)|)$)

 

Once the cmdspec is created, it can be tested for commands as shown in below screenshot. Commands in green are allowed where as in red are the ones which are not allowed.  Based on this cmdspec, only bind/unbind of lb vserver for service s1, s2 is allowed. Binding service s3 to lb vserver v1 is not allowed and shown as red colour. Similarly, set lb vserver is allowed only for vserver v1 and not for vserver v2.

After binding the command policy to the user, we should login as that user in NetScaler GUI and check how the command policy is effective for the user.

 

In the above screenshot we can see that only service s1 and s2 are displayed although there are other services available in Netscaler. Also in below screenshot we can see that only lb vserver v1 is displayed for this user.

——————————————————————————————————————————————————————————————————————————————————————————————–

As only authorized entities are displayed in GUI, user with this command policy will not be able to see other config entities for which he is not authorized. The same cmdspec used here can be altered as per the need to extend the RBAC protection for other entities easily through NetScaler Configuration GUI.

This way RBAC can be used to provide tighter control on configuration entities and can be easily managed.