Enforcing Role-Based Access Controls with ClusterControl

In Severalnines’ recent release of ClusterControl version 1.8.2 we have introduced a lot of sophisticated features and changes. One of the important features is the newly improved User Management System, which covers New User and LDAP Management.  A complementary existing capability in ClusterControl is its Role-Based Access Control (RBAC) for User Management, which is the focus of this blog.

Role-Based Access Control in ClusterControl

For those who are not familiar with ClusterControl‘s Role-Based Access Controls (RBAC), it’s a feature that enables  you to restrict the access of certain users to specific database cluster features and administrative actions or tasks. For example, access to deployment (add load balancers, add existing cluster), management, and monitoring features. This ensures that only authorized users are allowed to work and view based on their respective roles and avoids unwanted intrusion or human errors by limiting a role’s access to administrative tasks. Access to functionality is fine-grained, allowing access to be defined by an organization or user. ClusterControl uses a permissions framework to define how a user may interact with the management and monitoring functionality based on their level of authorization. 

Role-Based Access Control in ClusterControl plays an important role especially for admin users that are constantly utilizing it as part of their DBA tasks. A ClusterControl DBA should be familiar with this feature as it allows the DBA to delegate tasks to team members, control access to ClusterControl functionality, and not expose all of the features and functionalities to all users. This can be achieved by utilizing the User Management functionality, which allows you to control who can do what. For example, you can set up a Team such as analyst, devops, or DBA, and add restrictions according to their scope of responsibilities for  a given database cluster.

ClusterControl access control is depicted in  the following diagram,

Details of the terms used above are provided, below. A Team can be assigned to one or more of the database clusters managed by ClusterControl. A Team consists of empty or multiple users in a Team. By default, when creating a new Team, the super admin account will always be associated with it. Deleting superadmin doesn’t take it away from being linked to that new Team.

A User and a Cluster have to be assigned to a Team; it is a mandatory implementation within ClusterControl. By default, the super-admin account is designated to an Admin team, which has already been created by default. Database Clusters are also assigned to the Admin team by default.

A Role can have no User assigned or it can be assigned to multiple users in accordance with their ClusterControl role.

Roles in ClusterControl

Roles in ClusterControl are actually set by default. These default roles follow:

• Super Admin – It is a hidden role, but it is the super administrator (superadmin) role, which means all features are available for this role. By default, the user that you created after a successful installation represents your Super Admin role. Additionally, when creating a new Team the superadmin is always assigned to the new Team by default. 

• Admin – By default, almost all the features are viewable. Being viewable means that users under the Admin role can do management tasks. The features that are not available for this role are the Customer Advisor and SSL Key Management.

• User – Integrations, access to all clusters, and some features are not available for this role and are denied by default. This is useful if you want to assign regular users that are not intended to work database or administrative tasks. There are some manual steps to be done for those in the User role to see other clusters.

Roles in ClusterControl are arbitrary so administrators can create arbitrary roles and assign them to a user under Teams. 

How to Get Into ClusterControl Roles

You can create a custom role with its own set of access levels. Assign the role to a specific user under the Teams tab. This can be reached by locating User Management in the side-bar in the right corner. See the screenshot, below:

Enforcing Role-Based Access Controls with ClusterControl

Enforcing RBAC is user domain-specific, which restricts a user’s access to ClusterControl features in accordance with their roles and privileges. With this in mind,  we should start creating a specific user. 

Creating a User in ClusterControl

To create a user, start under the User Management ➝ Teams tab. Now, let’s create a Team first. 

Once created, there is a super-admin account which is linked by default once a Team is created.

Now, let’s add a new user. Adding a new user has to be done under a Team, so we can create it under DevOps.

As you might have noticed, the new user we created is now under the role User, which is added by default within ClusterControl. Then the Team is also under DevOps. 

Basically, there are two users now under the DevOps Team as shown below:

Take note that Roles are user domain-specific, so it applies access restrictions only to that specific user, and not to the Team where it belongs.

Admin vs User Roles (Default Roles in ClusterControl)

Since we have two roles added by default in ClusterControl, there are limitations that are set by default. To know what are these, just go to  User Management ➝ Access Control. Below is a screenshot that depicts the available features or privileges that a user belonging to the role can do:

Admin Role

User Role

The Admin role has many more privileges, whereas the User Role has some privileges that are restricted. These default roles can be modified in accordance to your desired configuration. Adding a Role also allows you to start and set which roles are  allowed or not. For example, we’ll create a new Role. To create a role, just hit the “+” plus button along the roles. You can see the new role we’ve created called Viewer.

All ticks are unchecked. Just check under the Allow column to enable the feature or privilege or check under the Deny column if you want to deny access. The Manage column allows the users in that role to do management tasks. Whereas the Modify column allows you to enable modifications that are only available to privileges or features under Alarms, Jobs, and Settings.

Testing RBAC

In this example, the following clusters are present in my controller as shown below:

This is viewable by the super administrator account in this environment. 

Now that we have RBAC set for the user we just created, let’s try to log in using the email and password we have just set.

This is what is created,

No clusters are available and viewable, and some privileges are denied as shown below such as Key Management Settings and the E-mail Notifications:

Adjusting RBAC

Since the privileges in the roles are mutable, it’s easy to manage them via User Management ➝ Access Control. 

Now, let’s allow the created user to view a cluster. Since our user has Access All Clusters denied, we need to enable it. See below,

Now, as we have stated earlier based on the diagram, Clusters are controlled by the Team. For example, there are the following cluster assignments,  below:

Since we need to assign the cluster to the right team, selecting the specific cluster and clicking the “Change Team” button will show the prompt allowing you to re-assign it to the right Team.

Now, let’s assign it to DevOps.

Now, logged back in as the newly created user, and we’ll be able to see the cluster.

Summary

Role-Based Access Control (RBAC) in ClusterControl is a feature that provides fine-grained restrictive access control for every user you have created in the ClusterControl, enabling greater security and more restrictive access control based on a user’s role.