Enforcing Role-Based Access Controls with ClusterControl

Since the release of ClusterControl version 1.8.2, we’ve introduced several advanced features and enhancements, particularly in the User Management System. These updates include improvements to New User Management and LDAP Integration.

A key existing capability in ClusterControl is Role-Based Access Control (RBAC) – also known as Group-Based or Team-Based Access Control – which plays a crucial role in managing user permissions efficiently.

For clarity, throughout this blog, we will refer to this functionality as Role-Based Access Control (RBAC), and the terms Roles and Teams will be used interchangeably.

Role-Based Access Control in ClusterControl

For those unfamiliar with ClusterControl’s Role-Based Access Control (RBAC), this feature allows organizations to restrict user access to specific database cluster functionalities, administrative actions, and tasks. With RBAC, you can control permissions for deployment (e.g., adding load balancers or existing clusters), management, and monitoring features.
By assigning roles, RBAC ensures that only authorized users can perform specific actions, reducing the risk of unauthorized access, human errors, or security breaches. Access control is fine-grained, meaning organizations can define permissions at a detailed level based on user roles.

ClusterControl implements a permissions framework to determine how users interact with management and monitoring functionalities, ensuring secure and efficient database operations.

Role-Based Access Control (RBAC) in ClusterControl is essential, particularly for DBA and admin users who rely on it for managing database operations efficiently. A ClusterControl DBA should be well-versed in this feature, as it enables them to delegate tasks, control user access to specific functionalities, and prevent unnecessary exposure of administrative features.

Through User Management, administrators can define who can perform which tasks within ClusterControl. For instance, teams such as Analysts, DevOps, or DBAs can be assigned roles with permissions tailored to their responsibilities for a given database cluster. This ensures that users only have access to the tools and features relevant to their role, improving security and operational control.

ClusterControl access control is depicted in  the following diagram,

Key Terms and Concepts in ClusterControl RBAC

Team: A Team can be assigned to one or more database clusters managed by ClusterControl. It may contain no users or multiple users.

• By default, when a new Team is created, the super admin account is always associated with it.
• Deleting the super admin user does not remove its association with the Team.

User & Cluster Assignment:

• Every User and Cluster must be assigned to a Team; this is a mandatory implementation in ClusterControl.
• The super admin account is automatically assigned to the Admin team, which is created by default.
• All database clusters are also assigned to the Admin team by default.

Role: A Role may have no users assigned or multiple users, depending on their ClusterControl role and permissions.

Roles in ClusterControl

Roles in ClusterControl are essentially called Teams in ClusterControl in the UI. It is set by default, especially when a user is created. These default roles follow:

• Super Admin – This is a hidden role, but it is the super administrator role, which means all features are available for this role. By default, the user you created on the registration page after a successful installation represents your Super Admin role. Additionally, when creating a new Team and logging in to the super admin user you created during registration, the super admin user shall be the owner of that team.

• Admin – By default, almost all the features are viewable. Being viewable means that users under the Admin role can perform 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 who are not intended to work on databases or administrative tasks. Those in the User role must perform some manual steps to see other clusters. If you create the user using s9s-tools with command s9s user and without setting the --group option, the user shall be assigned with this role by default.

• Nobody – This role is basically used internally but can also be set to a ClusterControl user. It’s a common and standard account present on most Unix-like systems, ensuring consistency across different environments. The nobody role is meant to be a catch-all low-privilege user. It ensures that it has the most minimal permissions on the system. Its purpose is to serve content without granting access to sensitive information within ClusterControl. If a user is assigned to this, it is merely a view-only account except that it cannot also see any clusters in the UI.

The Roles Admins, Users, and nobody are default and built-in roles that are integrated within ClusterContro. These roles cannot be edited since these roles are system-built roles by ClusterControl. In addition to that, Roles in ClusterControl are arbitrary so if an administrator would like to create a new Team or Role, they named it whatever it would be.

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.

Assign the users you would like to be part of that team,

Once created, it will show you the list of teams and clicking the ellipsis button will allow you to view, edit, and delete. Clicking the view option means you want to view the list of users and those manage clusters registered via ClusterControl. See below:

Now, let’s add a new user. Adding a new user has to be done under Users tab ➝ click Create user or team button, then make sure to choose Create user.

Just follow the steps on creating the user. You can specify the details and the team where the user shall belong to:

and then, choose the team.

Once the user is created, under the Users tab, in the view list, choosing the user you created and clicking the ellipsis button, you have the View list. By clicking and choosing View should allow the user to view about the user details that you set during creation, the team that the user is assigned to, its permission, and the clusters that are managed or with access level to that user. See below:

For example, for this user, it is assigned to a team named enterprise. Once the team enterprise is set to its cluster permission level with no access, this shall apply also to the user “Jack Ryan” with username “jackryan”. The example screenshot below shows the difference with the screenshot above.

Take note that any changes to its Role, shall be applied down to the user(s) that is assigned to it and shall be domain-specific in that particular instance.

Admin vs User Roles (Default Roles in ClusterControl)

Since we have two main roles that are built-in and added by default in ClusterControl, there are options that are set by default which you might not want or have limitations to your desired role. To know what are these, just go to User Management ➝ Tabs, then select the Team’s name. For example, the users team or role. See screenshot below:

Admin Role

By default, permissions have all been set to “No” except that Deploy clusters is set to “Yes”.

Whereas an admin role, shall have most permissions are set to yes and have all access to the clusters available or registered in ClusterControl. See screenshot below:

It might not be your desired role if you have more extensive users. In that case, as what we have shown earlier, you can create a new role or team in that case and try to refine in accordance with the requirements you need. Take note, this is not editable as clicking the Edit button is disabled as this is a system-built role.

Customizing the Role

You can modulate and apply a more refined role to your designed role via Team’s tab. During creation of a team/role or editing an existing team/role, you can go to step 3, i.e. Permissions and this can be apparent in the UI:

Only option Manage users and teams is not modifiable, other than that, you can set it to On/Off for these toggle switch buttons.

Going down in the UI, you see that Cluster permission level by default is set to “Manage”. Clicking this will show you the list of available permission levels. See below:

Under the Clusters permission level list, you can choose from Manage, View, No access, and lastly if you need more refined choose Custom. The description of the options are described in the drop down and as what is listed below:

• Manage. The users can view all clusters and their properties such as jobs, backups, charts, metrics, and settings. They can change the cluster settings, and manage the jobs. Manage is also the default option when creating a user. Otherwise, you have the option to edit that user and choose among the three options.
• View. The users can view the clusters and their properties such as jobs, backups, charts, metrics, and settings of the cluster. They cannot modify the clusters. Choosing View is similar to a user that has read-only access in a system.
• No access. The users are not allowed to view the clusters. No access is your choice if you only want the user to take a look at the ClusterControl and feel how it looks. It is similarly to the nobody role that we have described earlier in the blog.
• Custom. Apply a specific permission level for each cluster. Given that you have multiple clusters in your ClusterControl, let say you have 10 registered database clusters. You only want to give that user 3 clusters out of 10. Choosing Custom would allow you to set a refined option to what clusters that this user can only manage. The example screenshot below reveals how a Custom option would look like:

In the list of clusters, you can choose what cluster would you like to be managed or viewed. Otherwise, no access at all for that user upon creation or during editing to customize the desired permission level of that user.

Testing RBAC

In this example, I have the list of clusters in my staging environment below. This is viewed using my super admin account that I created during ClusterControl installation in the registration page.

Given that we have our role/team created for PostgreSQL dba’s only named “pg-dba”. This is shown below:

Above, it’s clearly apparent that we have one user only assigned, namely “paul.demo”. Viewing this user shall give me the following also:

and this user has only access to manage the “pgsql15” cluster.

Let’s log in to this user “paul.demo”,

we got to see only one cluster and that is only “pgsql15”,

At this point, the user “paul.demo” can essentially manage the cluster, deploy a new cluster, change controller and LDAP settings. In the next section, let’s adjust some of these and see how it reflects in ClusterControl.

Adjusting RBAC

When you apply changes to the specific team or role, it shall be applied immediately. The user(s) logged in require no need to logout but shall be applied dynamically. Meaning, it is an active setting causing the changes in an instant.

Adjusting the Role-based Access Control for the user cannot be applied in the Users tab of the User Management unless you will assign the user to another role. To adjust this, it can be done only in the Teams view, choosing the role that you want to adjust and those listed users shall be affected by the changes. In this example, we have a “pg-dba” team and let’s try to adjust the settings that shall be reflected also to the user “paul.demo”.

As an admin user, you can go to User Management ➝ Tabs, choosing the team pg-dba as shown below:

It will show the view of the Team details that was shown earlier above, then you can click the Edit button. Otherwise, clicking the ellipsis and choosing edit shall bring you to the UI to edit the settings of your team or role created. See below screenshot:

Since the privileges in the roles are mutable, as mentioned earlier, any changes shall be reflected directly. In the example screenshot below, we have adjusted some settings commonly Change controller configuration == “Off”, Change LDAP settings == “Off”, and Deploy clusters == “Off”, except that Managers users and teams is not mutable as it only applies to the super admin role.

Now, logged in as “paul.demo” user, considering I am clicking the LDAP settings configuration, and this is what I got:

Other than that, Deploy a cluster button is not visible in the upper right corner as well as the User management and Settings button are not visible as well.

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,

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.