ClusterControl is a management platform for open source databases. It is a feature-rich product which allows users to perform multiple management tasks, including ones that may result in a data loss (rebuilding nodes, restoring backups and so on). In larger organizations you may find it important to split the responsibility between different people, teams or departments while using complex software like ClusterControl. Luckily, ClusterControl comes with advanced user management, including role defining and setting ACL’s. In this blog we would like to show you its potential by dealing with a typical use case.
Let’s assume we have a company with multiple teams that run different projects. The database clusters are dedicated to a given project. Teams are mixed, some people are more experienced than others. We have people who are performing the maintenance tasks on the databases, we have as well developers, who are working on maintaining and extending the applications created by the given team. Company also has a DevOps team that is responsible for maintenance of all of the database clusters across the company. How can we put all of this together?
First of all, we have to create proper teams. We can do it on a per-project basis, adding also the DevOps team as well.
As a next step, we may want to create roles that we will use further.
SuperAdmin, Admin and User roles are built-in, the main difference between them is that the Admin will be able to see all of the clusters assigned to his team while the User will only be able to see clusters created by himself. SuperAdmin, obviously, has access to all of the clusters created in the ClusterControl. In addition to those three we will create a Developer role that will be a read-only role with access to the monitoring and alerting features of ClusterControl. It is intended to give some insight regarding the database performance for the development teams. The only additional action, that is not possible to do via UI, would be to assign the Developer role and “admin” status, so users with those roles could see all of the clusters assigned to their team. We can do it directly in the ClusterControl database:
MariaDB [dcps]> select * from roles; +----+-------------+-----------+ | id | role_name | role_type | +----+-------------+-----------+ | 1 | Super Admin | s | | 2 | Admin | a | | 3 | User | u | | 4 | Developer | u | +----+-------------+-----------+ 4 rows in set (0.00 sec) MariaDB [dcps]> update roles set role_type='a' where id=4; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 MariaDB [dcps]> select * from roles; +----+-------------+-----------+ | id | role_name | role_type | +----+-------------+-----------+ | 1 | Super Admin | s | | 2 | Admin | a | | 3 | User | u | | 4 | Developer | a | +----+-------------+-----------+ 4 rows in set (0.00 sec)
Then we should create users and assign them to the teams:
For the members of DevOps team we will assign them with a SuperAdmin role – they should be able to access all of the clusters, no matter which team they belong to.
Once this is done, the last step would be to assign existing clusters to the teams:
Once this is done, our setup is ready.
This user has access to all of the clusters assigned to Project A. It can also perform all of the management functions on those clusters.
Next, we have a developer working on the same project: [email protected]. His view of the cluster looks slightly different:
It can see the same clusters but the access to the features is now strictly limited.
Finally, DevOps team member, [email protected]:
As expected, DevOps team has full access to all of the clusters created in ClusterControl.
We haven’t really touched on this, but it is worth mentioning that all of this setup can as well be prepared for LDAP users. ClusterControl has an option to integrate with existing LDAP or AD setups and use users defined in those to manage the access rights in the ClusterControl.