Best Practices
We’ll look at security from three perspectives here, all of which are essential:
- Securing access to Altinity.Cloud
- Securing access to your ClickHouse® clusters
- Securing access to your ClickHouse data
The documentation covers specific topics that relate to security. They are referenced throughout this page, but here’s a list if you want to go directly to a particular topic:
- Account Management
- Role-based access and security tiers
- Integrating an identity provider with your Altinity.Cloud account
- Configuring connections and IP whitelisting
- Controlling Altinity access to ClickHouse
- Setting up an Amazon VPC endpoint
Finally, see the Security page the Altinity Operations Guide for an even more in-depth discussion of security topics.
Securing access to Altinity.Cloud
Your Altinity.Cloud account makes it easy to create and manage your ClickHouse clusters, so securing access to Altinity.Cloud is crucial. There are a few straightforward steps you can take to do this:
- Use an external identity provider
- Disable password logins
- Configure automatic user registration
- Use different roles for different users
Use an external identity provider
Altinity.Cloud supports integration with external identity providers via Auth0. Altinity customers use a variety of identity providers, including Google, Microsoft Azure Active Directory, Okta, and Keycloak.
For complete details on setting up an external identity provider, see the Integrating SSO via Auto0 into the Altinity.Cloud login page.
Disable password logins
Once you’ve set up an external identity provider, it makes sense to disable password logins altogether. This removes the possibility of password leakage. This can be done easily in the Altinity Cloud Manager. Click the Accounts tab on the left to see the Accounts list:
Figure 1 - The account list
Click the button to set login properties for all accounts in your organization. You’ll see this dialog:
Figure 2 - The Login Settings dialog
The options are:
Opened
If selected, user registration can be performed through the identity provider. In other words, the ACM will automatically create an account for a previously unknown user authenticated through the identity provider. If not selected, this environment is closed and every new user must be created by an Administrator.
Block password logins
If selected, only Auth0 logins will be accepted; a user cannot log in directly with a username and password.
Block API access
If selected, all API access to your Altinity.Cloud account will be blocked.
Allow password for admins
Note: We strongly advise that you not use this option. This allows admins to log in with a password, which fails to stop the exposure of passwords. We recommend that you require Auth0 logins for all users, including admins. If for some reason your identity provider is not available, contact Altinity support so we can restore access for an admin account. (After authenticating whoever is contacting us, of course.)
Configure automatic user registration
If you use an identity provider, you can set up your Altinity.Cloud account to create a new Altinity.Cloud account for a previously unknown user who authenticated through your identity provider.
You’ll need to contact Altinity support to configure how your Altinity.Cloud account works with your identity provider. For all the details, see the Auth0 integration page.
Use different roles for different users
Obviously every user should have no more access to your Altinity.Cloud account than they need. See the details of account roles and security tiers to determine the right level of access for each user you create.
In addition, if you use an identity provider, you can define a mapping between roles in your Altinity.Cloud account and roles in your identity provider. (You might map the Okta admin role to the Altinity.Cloud orgadmin role, for example.) Those roles should be mapped to give every user no more access than they need as well. Contact Altinity support to configure how your Altinity.Cloud account works with your identity provider. For all the details, see the Auth0 integration page.
Securing access to your ClickHouse clusters
Altinity.Cloud provides HTTP and TCP access endpoints to your ClickHouse clusters. This traffic is encrypted in transit, and certificates are renewed every three months. If a ClickHouse cluster has sensitive data, you should avoid using a public load balancer. The public load balancer provides a public endpoint for third-party attackers.
You can limit the IP addresses that can connect to your ClickHouse clusters. Looking at the clusters view in the Altinity Cloud Manager, the green lock icon means IP restrictions are enabled, while the
red triangle icon means that IP restrictions are not enabled.
Figure 5 - View of two clusters, one of which has IP restrictions disabled
Hovering over the red triangle gives a stern warning:
![IP restrictions disabled warning message](/images/altinitycloud/ip_restrictions_disabled_warning.png)
Figure 6 - IP restrictions disabled warning message
There are several ways to secure the endpoints of your ClickHouse clusters:
- Use VPC endpoints (AWS) or Private Service Connect (GCP)
- VPC peering (Bring Your Own Cloud only)
- IP whitelisting
Use VPC Endpoints (AWS) or Private Service Connect (GCP)
The best way to secure access to a ClickHouse cluster from within your cloud infrastructure is with a VPC Endpoint (AWS) or a Private Service Connect (GCP). In this scenario Altinity.Cloud configures an internal load balancer and connectivity between the ClickHouse cluster and your VPC.
When a VPC endpoint is enabled, the public load balancer is automatically turned off, and the cluster view in the ACM displays the VPC endpoint icon:
Figure 7 - VPC endpoint enabled
The Connecting to Altinity.Cloud documentation has complete details on setting up an Amazon VPC endpoint. Documentation for setting up a GCP Private Service Connect is coming soon; contact Altinity support for help in the meantime.
VPC peering (BYOC only)
Altinity.Cloud also supports VPC peering when managing resources in your account. Please contact Altinity support to configure VPC peering.
IP whitelisting
The Launch Cluster Wizard makes it easy to set up an IP whitelist. The Connection Configuration tab enables IP restrictions by default, and the default whitelist is simply the IP address from which you’re accessing the ACM.
Figure 8 - Setting IP restrictions
Once your ClickHouse cluster is configured, you can configure the cluster to edit the addresses on the whitelist or disable IP restrictions completely. Complete details are in the Configuring Connections section of the Configuring a Cluster section of the User Guide.
Securing access to your ClickHouse data
Once you’ve secured access to your Altinity.Cloud account and your ClickHouse clusters, there are steps you can take inside ClickHouse itself to protect your data.
The Security page in the Operations Guide has guidelines to secure ClickHouse systems in general, with recommendations for hardening your network, storage, and users. Much of the information in the Operations Guide doesn’t apply to Altinity.Cloud customers because Altinity.Cloud handles network and storage hardening for you automatically. Some of our security features include:
- Your ClickHouse clusters are isolated; they’re all in separate Kubernetes clusters.
- Your storage is isolated as well, and it users each cloud provider’s encryption features.
- TLS is enabled.
- VPC endpoints are supported.
- Intercluster communications are secured.
For user hardening, you can increase ClickHouse security at the user level with the following techniques:
- User configuration: Setup secure default users, roles and permissions through configuration or SQL.
- Secure passwords: Store user information as hashed values.
- Set quotas: Limit how many resources users can use in given intervals.
- Use profiles: Use profiles to set common security settings across multiple accounts.
- Database restrictions: Narrow the databases, tables and rows that a user can access.
See The Security page in the Operations Guide for all the details.