Securing ClusterControl

This guide provides ways to secure your ClusterControl installation.

Firewall and security group

Depending on the deployment options, ClusterControl might disable firewalls to minimize the possibilities of failure during the cluster deployment. Once the process is completed, it is important to secure the ClusterControl node and the database cluster. We recommend isolating your database infrastructure from the public Internet and allowing only known hosts or networks to connect to the database cluster.

See Firewall and Security Groups for the full list of ports ClusterControl requires to be open.

SSH

SSH is very critical for ClusterControl. It must be possible to SSH from the ClusterControl server to the other nodes in the cluster without a password, thus the database nodes must accept the SSH port configured in the CMON configuration file. The following best practices are recommended:

• Permit very few people in the organization to access the servers. The fewer the better.
• Lock down SSH access so it is not possible to SSH into the nodes from any other server than the ClusterControl server.
• Lock down the ClusterControl server so that it is not possible to SSH into it directly from the outside world.

File permission

CMON configuration and log files contain sensitive information, such as the mysql_password value or the sudo password used for SSH privilege escalation. Ensure the CMON configuration file (e.g., /etc/cmon.cnf and /etc/cmon.d/cmon_{clusterid}.cnf, if present) has permission 700. CMON log files (e.g., /var/log/cmon.log and /var/log/cmon_{clusterid}.log) should have permission 740. Both the configuration and log files should be owned by root.

HTTPS

By default, the installation script installs and configures a self-signed certificate for ClusterControl GUI. You can access it by pointing your browser to https://{ClusterControl_host}/. If you would like to use a properly signed SSL certificate, replace the tls_cert and tls_key path inside /usr/share/ccmgr/ccmgr.yaml and restart the ClusterControl Proxy service. Details at ClusterControl Proxy → Configure Custom SSL Certificates.

Access control and identity

Securing the host is only part of the picture. ClusterControl also provides application-level controls for managing who can access the system and what they're allowed to do once they're in:

• Role-based access control ^Enterprise: Group users into teams with defined permissions instead of sharing a single admin account. See Users and Teams.
• LDAP/Active Directory authentication ^Enterprise: Authenticate users against your corporate directory, with LDAP groups mapped to ClusterControl permissions, instead of maintaining separate local passwords. See LDAP.
• Audit logging: Record logins, queries, data modifications, and schema changes on the managed database nodes for security and compliance purposes. Currently supported for MariaDB Replication/Galera, PostgreSQL, and TimescaleDB. See Audit Logs.

Secrets and encryption

• HashiCorp Vault integration ^Enterprise: Store and load database and cluster credentials from an external Vault server instead of in plaintext inside the CMON configuration files described under File permission above. See HashiCorp Vault Integration.
• Certificate management ^{Enterprise Advanced}: Generate, import, and organize a CA and server/client certificates from the GUI, then assign them to a cluster to enable SSL/TLS encryption between the controller and the database nodes. See Certificates.
• Backup encryption: Enable the encryption option when scheduling a backup to have ClusterControl auto-generate and manage an AES-256 encryption key for it. See Create Backup.