Skip to main content
ClickHouse accounts let you manage access to a ClickHouse database. Users connect through Web Access or the CLI, and every statement they run is recorded in the session. Sessions reach ClickHouse over its HTTP interface, on port 8123 or 8443, rather than the native protocol on 9000. Every request passes through the gateway in your own network, and the credential never reaches the client.

​
Prerequisites

  • A ClickHouse user for Infisical to connect as.
  • The HTTP interface enabled on the target. http_port (8123) is on by default in a stock ClickHouse configuration. https_port (8443) needs a certificate configured, and is what ClickHouse Cloud exposes.
  • A gateway that can reach that port. A gateway that predates ClickHouse support refuses the session with a version error.

​
Creating an account

1

Start adding an account

Go to Privileged Access Management → Accounts and select Add Account.
2

Select a folder and template

Choose which folder to add the account to, then select a ClickHouse template.
3

Enter connection details

4

Enter credentials

5

Save

Select Create. Infisical signs in to ClickHouse through the gateway and runs one statement to confirm the credential works before saving the account.

​
Permissions

What a session can do comes from the ClickHouse grants on the account’s user, so grant that user only what the people using the account need. Web Access reads the database, table and column lists from system.databases, system.tables and system.columns, which every user can read for the objects they already have access to.
Every session opens on the account’s Database, whatever a client asks for. That is a starting point, not a limit: a session can still read any database the user has a grant on, and Web Access lists them all. Scope the grants, not the Database field. Sessions connect with the user’s default roles. The gateway drops the role URL parameter, which would otherwise activate a role with no statement to record, so use SET ROLE instead and it’s recorded like any other statement. Command blocking matches the text of each statement, so a statement that builds SQL at runtime can run something a pattern would otherwise reject. Use ClickHouse grants for restrictions that have to hold.

​
Connecting

Web Access provides a browser-based interface with two tools:
  • Data Explorer — browse tables, view data, filter and sort, export to CSV/JSON
  • SQL Editor — write and run SQL queries
To connect:
  1. Go to Privileged Access Management → Accounts
  2. Find the account and select the rocket icon (or select Launch Session from the menu)
  3. Select Connect in Browser
ClickHouse has no schema layer inside a database, so the Data Explorer sidebar lists databases where it lists schemas for other account types.
The Data Explorer shows the first 1,000 rows a statement produces and tells you when there are more, and caps a statement at 30 seconds. Neither limit applies to the CLI, so use it with your own client for a long query or a full result set.
ClickHouse applies row changes as asynchronous mutations rather than as statements that take effect when they return, so the Data Explorer grid is read-only for every table. Run ALTER TABLE ... UPDATE or DELETE FROM from the SQL Editor instead. The column marked as a key in the grid is the table’s sorting key, which ClickHouse calls the primary key: it’s an index, not a unique constraint.

​
Recording

Every statement a session runs is recorded, along with the outcome of each one, and appears under Session Logs on the session. Web Access and the CLI both reach ClickHouse through the gateway, so recording works the same for either. Recordings are encrypted with a per-session key and written to the storage backend the template selects, the same as any other account type. The template’s Command Blocking policy applies to ClickHouse as well: a statement matching one of its patterns is rejected before it reaches ClickHouse, and the rejection is recorded. Session Log Masking patterns are applied to the recording before it’s written. Applying that policy means reading the statement first, so on an account that blocks commands a request body over one megabyte is refused, and one compressed with anything other than gzip or deflate is rejected outright. Send large inserts in smaller batches, or use an account without the policy, where the body streams through and only its first megabyte is recorded.

​
Next steps

Sessions

View and manage sessions.

Access requests

Require approval before a session starts.