Skip to main content
Version 3.0

Security — ClickHouse

ChartVersion3.0.1TypeapplicationAppVersion25.8.11.66
CompatibilityKubernetes1.32+OpenShift4.19+Rancher2.10.x+

This page focuses on the security and access control aspects of tdp-clickhouse: passwords, default user, TDP user, additional profiles and LDAP authentication.

For integration with S3/MinIO configurations and storage policies, see Integrations — ClickHouse.

Prerequisites

  • LDAP server accessible from the Kubernetes cluster when LDAP is used.
  • tdp-clickhouse.clickhouse.extraConfig block prepared with <ldap_servers> and <user_directories> when LDAP is enabled.
  • Planning of ClickHouse roles and grants for users authenticated through LDAP.

Local password management

Default user

Configure tdp-clickhouse.clickhouse.defaultUser.password only when you need to set the default user password. If there is no such requirement, keep the value empty.

tdp-clickhouse:
clickhouse:
defaultUser:
password: "<PASSWORD>"

TDP user (optional)

When tdpUser.enabled: true, the chart creates a Secret (tdp-clickhouse-tdp-user) and runs a post-install/upgrade Job to apply grants. The Job waits for ClickHouse service endpoints and then executes commands in an available backend pod.

tdp-clickhouse:
clickhouse:
tdpUser:
enabled: true
password: "<PASSWORD>"

Additional profiles and users (extraUsers)

Use tdp-clickhouse.clickhouse.extraUsers for additional ClickHouse user and profile XML configuration. On this page, the field is used in the network access control context, as shown in the following example.

Network access control

By default, ClickHouse only accepts connections from 127.0.0.1/::1. To allow other networks (such as an Ingress Controller or other pods) to access ClickHouse, configure the <networks> block in extraUsers:

tdp-clickhouse:
clickhouse:
extraUsers: |
<yandex>
<profiles>
<default>
<query_cache_system_table_handling>ignore</query_cache_system_table_handling>
</default>
</profiles>
<users>
<default>
<networks>
<ip>::/0</ip>
</networks>
</default>
</users>
</yandex>

LDAP

The chart supports LDAP authentication via extraConfig (ClickHouse native XML). By default, LDAP is disabled.

Configuration via extraConfig

Enable LDAP by uncommenting and filling in the extraConfig block (and, optionally, ldapRoleInit) in a separate values file:

tdp-clickhouse:
clickhouse:
extraConfig: |
<yandex>
<user_directories>
<ldap>
<server>tdp_ldap</server>
<roles>
<tdp_ldap_role />
</roles>
</ldap>
<local_directory>
<path>/var/lib/clickhouse/access/</path>
</local_directory>
<users_xml>
<path>users.xml</path>
</users_xml>
</user_directories>
<ldap_servers>
<tdp_ldap>
<host>ldap.example.com</host>
<port>389</port>
<auth_dn_prefix>uid=</auth_dn_prefix>
<auth_dn_suffix>,cn=users,cn=accounts,dc=example,dc=com</auth_dn_suffix>
<base_dn>cn=users,cn=accounts,dc=example,dc=com</base_dn>
<user_filter>(uid={user})</user_filter>
<enable_tls>0</enable_tls>
</tdp_ldap>
</ldap_servers>
</yandex>

Adjust host, port, auth_dn_prefix, auth_dn_suffix, base_dn and user_filter to your environment. The auth_dn_prefix/auth_dn_suffix method constructs the bind DN directly from the user's UID, without requiring a service account.

LDAP TLS warning

In the example above, enable_tls: 0 represents just a starting point. If your LDAP server supports TLS, enable it in production and handle certificates according to your organization's policy.

Automatic creation of the LDAP role (ldapRoleInit)

Chart can create LDAP role automatically when ldapRoleInit.enabled: true. Databases and GRANTs continue to be managed manually after deployment:

-- Optional if ldapRoleInit.enabled=true
CREATE ROLE IF NOT EXISTS tdp_ldap_role;

-- Optional grants: apply only the necessary access
-- GRANT ALL ON tdp.* TO tdp_ldap_role;
-- GRANT SELECT ON default.* TO tdp_ldap_role;
-- GRANT SELECT ON system.* TO tdp_ldap_role;

LDAP Parameters

ParameterDescription
tdp-clickhouse.clickhouse.extraConfigXML with <ldap_servers> and <user_directories>
tdp-clickhouse.clickhouse.ldapRoleInit.enabledCreates the LDAP role automatically post-install
Separate value file

Place LDAP blocks in a separate file, for example values-ldap.yaml, to avoid exposing sensitive settings in the main repository.