Best Practices

What we’ve learned about keeping your ClickHouse® clusters and data secure

We’ll look at security from three perspectives here, all of which are essential:

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:

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

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:

The account list

Figure 1 - The account list

Click the button to set login properties for all accounts in your organization. You’ll see this dialog, opened to the General tab:

The General tab of the Login Settings dialog

Figure 2 - The General tab of the Login Settings dialog

(We’ll cover the User Sync tab below in the section Configure automatic user registration below).

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.)

Enable 2FA for password logins

This option is enabled if anyone is allowed to log in with a password. (In Figure 2 above, no one is allowed to use passwords, so the option is disabled.) Turning on 2FA sends an email to users every time they ask to log in. First of all, the user will see this dialog in the ACM:

The 2FA login message

Figure 3 - The 2FA login message in the ACM

The user will receive an email with a login link, something like this:

The 2FA login email

Figure 4 - The 2FA login email

Clicking the link in the email logs the user in. As you would expect, this link can only be used once.

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. If you’re an Okta customer, read on; otherwise you’ll need to contact Altinity support to configure Altinity.Cloud for your provider. If you’re curious about the technical details, see the Auth0 integration page.

Okta customers can automatically create users authenticated by Okta. Click the button as show in Figure 1 above, then go to the User Sync tab in the dialog:

The User Sync tab of the Login Settings dialog with no options selected

Figure 5 - The User Sync tab of the Login Settings dialog with no options selected

Initially no options are selected in the dialog as shown in Figure 5. If you select Deny access if not in Okta and/or Enable Okta role sync, the dialog will look like this:

The User Sync tab of the Login Settings dialog

Figure 6 - The User Sync tab of the Login Settings dialog

The options are:

Deny access if not in Okta

If enabled, only users authenticated by Okta are allowed to access your Altinity.Cloud account.

Enable Okta user sync

This option lets you map user roles in Okta to user roles in your Altinity.Cloud account. You define those mappings at the bottom of the panel.

Okta Domain

The domain for your Okta account. Do not include https:// in front of this value, and don’t include .okta.com at the end.

Okta API Token

The API Token generated at Okta.com for your Okta account. The prompt below the entry field contains a link to the Okta documentation for creating API tokens.

Pairing Okta roles and Altinity.Cloud roles

The area at the bottom of the dialog lets you define pairs of roles, one from Okta roles and one from Altinity.Cloud. Depending on the new user’s role, you can also define which Altinity.Cloud environments they can access.

In Figure 6 above, there are two role pairs: admin is paired with orgadmin, and average_joe is paired with envuser. if a new Altinity.Cloud user is created from an Okta user with the admin in Okta, they will have the orgadmin role in Altinity.Cloud and will have access to every environment in the account.

The second role pair above creates a new user with the envuser role. Selecting envuser as the paired role displays a list of all the environments in your Altinity.Cloud account. You can select which environments the new user can access. If Figure 6, all new envuser accounts can access the altinity-maddie-tf and altinity-minikube-monday environments.

As you would expect, clicking the button lets you add a new role pair, and clicking the icon deletes one.

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.

View of two clusters, one of which has IP restrictions disabled

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

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)

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:

VPC endpoint enabled

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.

Setting IP restrictions

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.