ClickHouse Users Configuration
This section explains how to configure per-user ClickHouse connections in KAWA. By default, all queries are executed using a single default ClickHouse user defined in the JDBC URL. KAWA supports assigning dedicated ClickHouse users to specific KAWA users, enabling fine-grained access control at the warehouse level (quotas, row policies, read-only access, etc.).
Terminology: In this document, "principal" refers to a KAWA user account. The terms are used interchangeably.
Important: The default user should not have restrictive limitations, as it is used by KAWA for administrative operations (listing tables, managing schemas, etc.). When you need to impose limits on a specific user, create a separate ClickHouse user and assign it to that user's KAWA account.
1. Environment Variables
1.1 ClickHouse Environment Variables
The two key variables for this feature are highlighted below. The remaining variables are listed for reference.
KAWA_CLICKHOUSE_JDBC_URL
Default JDBC connection URL
KAWA_CLICKHOUSE_ADDITIONAL_USERS
JSON array of additional ClickHouse users
KAWA_CLICKHOUSE_IS_POST_23_DOT_8
Whether ClickHouse version is >= 23.8 (true/false)
KAWA_CLICKHOUSE_ALLOW_LIVE_CONNECT
Allow live connect (true/false)
KAWA_CLICKHOUSE_CLUSTER
Cluster name (optional)
KAWA_CLICKHOUSE_STORAGE_POLICY
Storage policy (optional)
KAWA_CLICKHOUSE_VALIDATION_ALLOW_DATA_DELETION
Allow data deletion during schema validation
1.2 JDBC URL Format
jdbc:clickhouse://hostname:port/database?user=username&password=passwordExample:
1.3 Additional Users Format
The value of KAWA_CLICKHOUSE_ADDITIONAL_USERS is a JSON array of objects, each containing a user and password field:
Each entry creates a separate connection pool to ClickHouse. The user value must correspond to an existing ClickHouse user.
Important: Changes to
KAWA_CLICKHOUSE_ADDITIONAL_USERStake effect only after restarting the KAWA server, as the variable is read at startup and used to create connection pools.
2. Assigning a ClickHouse User to a KAWA User
Once additional users are defined in the environment variable, you need to specify which KAWA user (principal) should use which ClickHouse user. This is done via the Python SDK using the ReplacePrincipalDbUser command.
2.1 Running the Command
Parameters:
principalId— The numeric ID of the KAWA user (principal).dbUser— The name of the ClickHouse user from theKAWA_CLICKHOUSE_ADDITIONAL_USERSarray.
Restrictions: This command is available to KAWA administrators only.
Note: Calling
ReplacePrincipalDbUserdoes not require a KAWA restart — the mapping is updated in the database and takes effect immediately.
2.2 Removing the Assignment
To revert a user to the default connection, pass None as the dbUser value:
Note: The backend parameter type is
Optional<String>. PassingNonefrom the Python SDK sends an empty optional, which clears the ClickHouse user assignment for that principal.
3. How It Works
When a user makes a request:
KAWA checks the user's
dbUserfield.If set (e.g.,
analyst_readonly) → uses the corresponding connection pool.If the user is not found in the additional users list → falls back to the default connection.
If
dbUseris not set → uses the default connection.
4. Bulk Assignment via CSV
For assigning ClickHouse users to multiple principals at once, you can use a CSV file with a Python script.
File user_mapping.csv:
Script assign_ch_users.py:
5. ClickHouse Configuration Examples
5.1 Creating the Default KAWA User
5.2 Read-Only User
This user can only read data and cannot create or modify tables.
5.3 User with Row-Level Security (Row Policy)
This user will only see rows where region = 'EMEA'.
5.4 User with Quotas
5.5 Settings Profiles
6. End-to-End Example
Step 1. Create ClickHouse users (no KAWA restart needed):
Step 2. Add them to the environment variable and restart KAWA (required for new connection pools to be created):
Step 3. Assign to KAWA users via Python SDK (no restart needed, takes effect immediately):
Step 4. Verify: when KAWA user #5 executes a query, it will use the analyst connection, and ClickHouse will enforce the SELECT-only restriction.
Last updated
Was this helpful?

