Security — ClickHouse

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

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

Local password management

Default user

The ClickHouse default user has broad privileges. In production, set a strong password and never version real credentials in Git:

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

Recommendation

Avoid using the default user for routine application access. Whenever possible, prefer a dedicated user with grants limited to the minimum necessary.

TDP user (optional)

When tdpUser.enabled: true, the chart creates a Secret (tdp-clickhouse-tdp-user) and runs a post-install Job to apply grants.

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

Use this pattern when you want to separate technical/application access from administrative access with the default user.

Additional profiles and users (extraUsers)

For additional profiles and users via native ClickHouse XML, use extraUsers:

tdp-clickhouse:
  clickhouse:
    extraUsers: |
      <clickhouse>
        <profiles>
          <default>
            <query_cache_system_table_handling>ignore</query_cache_system_table_handling>
          </default>
        </profiles>
      </clickhouse>

Default user access control

By default, the default user can be exposed broadly if the network configuration is permissive. In environments with external exposure or multiple networks, explicitly control that access:

tdp-clickhouse:
  clickhouse:
    defaultUser:
      allowExternalAccess: true   # false = only local connections on the pod
      hostIP: 0.0.0.0/0           # replace with a restricted CIDR in production

When to adjust hostIP

• Use an internal CIDR when only cluster services should access ClickHouse.
• Avoid 0.0.0.0/0 in exposed production environments.
• Whenever possible, complement with cluster network policies and namespace segmentation.

Production best practices

• Restrict hostIP to the CIDR range that is actually required.
• Do not share credentials across teams and applications.
• Store passwords in Kubernetes Secrets or in private values files.

LDAP

The chart supports LDAP authentication via extraConfig (native ClickHouse XML). By default, LDAP is disabled and values.yaml contains only a commented example block.

Prerequisite

The LDAP server must be reachable from the Kubernetes cluster.

Create the LDAP bind Secret

Before installing or upgrading the chart with LDAP enabled, create the Secret with the bind user's password:

Terminal input

kubectl -n <namespace> create secret generic tdp-clickhouse-ldap-bind \
  --from-literal=LDAP_BIND_PASSWORD='<LDAP_BIND_PASSWORD>'

Configuration via extraConfig and podTemplate

Enable LDAP by uncommenting and filling in the extraConfig, podTemplate, and optionally ldapRoleInit blocks in a separate values file:

tdp-clickhouse:
  clickhouse:
    extraConfig: |
      <yandex>
        <user_directories replace="replace">
          <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>
            <bind_dn>uid=svc_clickhouse,ou=users,dc=example,dc=com</bind_dn>
            <bind_password from_env="LDAP_BIND_PASSWORD" />
            <base_dn>ou=users,dc=example,dc=com</base_dn>
            <user_filter>(uid={user})</user_filter>
            <enable_tls>0</enable_tls>
          </tdp_ldap>
        </ldap_servers>
      </yandex>

    podTemplate:
      spec:
        containers:
          - name: clickhouse
            env:
              - name: LDAP_BIND_PASSWORD
                valueFrom:
                  secretKeyRef:
                    name: tdp-clickhouse-ldap-bind
                    key: LDAP_BIND_PASSWORD

Adjust host, port, bind_dn, base_dn, and user_filter to your environment.

LDAP TLS

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

Automatic LDAP role creation (ldapRoleInit)

The chart can create the LDAP role automatically when ldapRoleInit.enabled: true. Databases and GRANTs are still managed manually after deploy:

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

-- Optional grants: apply only the access you need
-- 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.podTemplate	Injects LDAP_BIND_PASSWORD via Secret into the container
tdp-clickhouse.clickhouse.ldapRoleInit.enabled	Creates the LDAP role automatically on post-install

Separate values file

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