Privilege model

​

What the connector can do

​

Outbound connections

​

ClickHouse grants

CREATE USER IF NOT EXISTS `pcm_scraper` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';

GRANT SELECT ON `system`.`asynchronous_metric_log` TO `pcm_scraper`;
GRANT SELECT ON `system`.`metric_log` TO `pcm_scraper`;
GRANT SELECT ON `system`.`server_settings` TO `pcm_scraper`;
GRANT SELECT ON `system`.`tables` TO `pcm_scraper`;
GRANT SELECT ON `system`.`warnings` TO `pcm_scraper`;
GRANT SELECT ON `system`.`user_directories` TO `pcm_scraper`;
GRANT READ ON REMOTE TO `pcm_scraper`;
GRANT SYSTEM FLUSH LOGS ON *.* TO `pcm_scraper`;

CREATE USER IF NOT EXISTS `pcm_troubleshooter` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';

GRANT SELECT ON `system`.`asynchronous_metrics` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`build_options` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`clusters` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`columns` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`databases` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`detached_parts` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`disks` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`events` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`formats` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`functions` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`grants` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`merges` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`metrics` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`mutations` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts_columns` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts_summary` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`processes` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`replicas` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`replication_queue` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`roles` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings_profile_elements` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings_profiles` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`storage_policies` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`table_engines` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`tables` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`users` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`user_directories` TO `pcm_troubleshooter`;

​

Kubernetes RBAC

​

What the connector cannot do

• No writes to ClickHouse data or state. The grants above contain no INSERT, no DDL, and no user-management, settings, or process-control privileges; the single system-class grant, the scraper’s SYSTEM FLUSH LOGS, only makes log tables persist what they already buffer. The connector cannot modify data, schemas, users, or settings.
• No exec. The RBAC contains no pods/exec; the connector cannot run commands in your pods.
• No delete, no patch. The RBAC allows two mutations: the exact-name update on the connector’s own mTLS Secret, and create on serviceaccounts/token, which mints short-lived tokens for the connector’s own ServiceAccounts and modifies no stored object.
• No cluster scope. Every Role is bound in a namespace; the connector cannot list or read resources outside the namespaces you granted.
• Nothing inbound. ClickHouse Cloud never opens a connection into your environment. The only command path is the troubleshooter’s outbound WebSocket, and the troubleshooter refuses every command unless a support session you enabled is active. Even during a session, the scope is bounded on both sides: ClickHouse queries are limited to the table allowlist, with query_log and text_log denied by the validator regardless of configuration, and Kubernetes access is separately limited to the read-only views and pod logs the namespace-scoped Roles grant.

​

What requires your action

• Support sessions. Interactive troubleshooting happens only inside a session you enable, time-boxed to 4 hours by default and 24 hours at most. Disabling takes effect immediately. See support sessions.
• The operator allowlist. Every gateway request must carry an OIDC token whose attested email is on your allowlist. An empty allowlist is closed. You manage the list; see the configuration guide.
• Gateway exposure. The session gateway is off unless you enable it, and reachable only by port-forward unless you opt into an Ingress. On a VM, its self-signed certificate must be fingerprint-pinned by each operator before the session commands will talk to it.
• Network egress. Under an enforcing CNI, the connector has no egress until you allowlist the endpoint CIDRs in the chart’s NetworkPolicy.

​

How access is attributed

• Deployment identity. The mTLS client certificate’s common name is your org ID, with a single DNS name bound to your endpoint host, so every API connection is attributable to your org. Renewal is automatic and in-daemon; no operator handles the key material.
• Request integrity. Every API request additionally carries an HMAC-SHA256 signature (Authorization: HMAC-SHA256 AccessKey=..., Signature=..., Timestamp=...) computed over the method, path, timestamp, and body hash, using the key pair issued at enrollment.
• Operator identity. Gateway calls are attributed to the email attested by the operator’s OIDC ID token, verified against your identity provider’s JWKS; a self-reported name is never trusted where a token is available.
• Audit trail. Every gateway call and every troubleshoot command, accepted or blocked, is appended to the NDJSON audit log: gateway entries with the attested operator email, VM local session changes with the invoking host user, and session commands with the org identity carried on the authenticated channel. Read it with clicklink clctl troubleshoot audit tail; see the CLI reference.

​

Data minimization defaults

• query_log is excluded from scrapes by default. Its columns carry raw SQL with literal values, which can contain personal data or secrets, so it does not leave your boundary unless you add it deliberately.
• The troubleshooter reads only allowlisted tables, and the validator denies query_log and text_log unconditionally, so query history is never readable. The default allowlist does include system.processes (live query text); trim the session table allowlist (troubleshooter.allowedTables on Kubernetes, troubleshooter.allowed_tables on a VM) if that must stay hidden during sessions.
• All troubleshooter output is redacted with built-in patterns for IPv4 and IPv6 addresses, bearer tokens, AWS access keys, emails, JWTs, SSH private keys, and connection-string credentials, plus any patterns you define. The daemon refuses to start with an invalid patterns file rather than run unredacted.
• Credentials are minimized at rest. Provisioning SQL contains bcrypt hashes, never plaintext passwords; the enrollment token is never written to the command line, disk, or logs; keys live in Kubernetes Secrets or files with mode 0600.