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 to 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 into 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 do not intend 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 the command s9s user and without setting the --group option. The user shall be assigned 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 integrated within ClusterContro. They cannot be edited since they are system-built roles by ClusterControl. In addition, Roles in ClusterControl are arbitrary, so if an administrator would like to create a new Team or Role, they name it whatever they 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 sidebar 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 who manage clusters registered via ClusterControl. See below:

Now, let’s add a new user. You must do this under the Users tab ➝ Click the Create user or team button, then make sure to choose Create user.

Just follow the steps to create the user. You can specify the details and the team to which 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. Clicking and choosing View should allow the user to view 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 an access level to that user. See below:

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

Please note that any changes to its Role will be applied to the user(s) assigned to it and will 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 that you might not want or that have limitations to your desired role. To know what these are, 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, all permissions are set to “No” except Deploy clusters, which is set to “Yes.”

Whereas an admin role shall have most permissions 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 we have shown earlier, you can create a new role or team in that case and try to refine it 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 the Team tab. During the 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:

The 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 options is described in the drop-down and as listed below:

• Manage. Users can view all clusters and their properties, such as jobs, backups, charts, metrics, and settings. They can also change the cluster settings and manage 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. Users can view the clusters and their properties, such as jobs, backups, charts, metrics, and settings. They cannot modify the clusters. Choosing View is similar to a user having read-only access to a system.
• No access. The users are not allowed to view the clusters. If you only want the user to take a look at the ClusterControl and feel how it looks, no access is your choice. It is similar to the nobody role that we described earlier in the blog.
• Custom. Apply a specific permission level for each cluster. Given that you have multiple clusters in your ClusterControl, let’s 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 this user can only manage. The example screenshot below reveals what a Custom option would look like:

In the list of clusters, you can choose what cluster you would 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 on 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, and change controller and LDAP settings. In the next section, let’s adjust some of these and see how they are reflected in ClusterControl.

Adjusting RBAC

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

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

As mentioned earlier, since the privileges in the roles are mutable, 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 are not mutable as they only apply 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, the Deploy a cluster button in the upper right corner is not visible, and neither are the User management or Settings buttons.

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 ClusterControl. This enables greater security and more restrictive access control based on a user’s role.

To keep up to date with all ClusterControl news, follow us on X and LinkedIn and subscribe to our newsletter.