Security — ClickHouse
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.extraConfigblock 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.
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
| Parameter | Description |
|---|---|
tdp-clickhouse.clickhouse.extraConfig | XML with <ldap_servers> and <user_directories> |
tdp-clickhouse.clickhouse.ldapRoleInit.enabled | Creates the LDAP role automatically post-install |
Place LDAP blocks in a separate file, for example values-ldap.yaml, to avoid exposing sensitive settings in the main repository.