Routine operations
ClickHouse Cloud’s control plane runs your BYOC deployment without reading customer data. The components that send data to ClickHouse-owned infrastructure carry only operational metadata:
Query traffic, table contents, and schemas never flow through these channels. Your full monitoring dataset — the Prometheus and Thanos stack, and your logs — stays in your own account; the bounded telemetry in the table above is the only observability data continuously exported into ClickHouse-owned systems. ClickHouse’s monitoring dashboards and, on approved escalation, its engineers can additionally query that stack and your logs in place over Tailscale, without anything being persisted on the ClickHouse side — see Troubleshooting access. See network boundaries for the complete inbound and outbound flow reference.
Troubleshooting access
When ClickHouse engineers need to diagnose a problem in your deployment, they request just-in-time access through an internal escalation and approval workflow. Approved access is granted via a time-bound certificate and routed over Tailscale — never the public internet.What engineers can see
Within ClickHouse, approved troubleshooting access is limited to system tables. This includes:system.query_log— query text and execution metadata for queries run against your servicesystem.tables,system.columns, and similar system tables — schema and metadata- Other
system.*tables used for diagnostics (e.g., parts, mutations, replicas)
What engineers can’t see
Engineers can’t read customer user tables. Within ClickHouse, access is scoped to system tables only.Infrastructure diagnostics
The same approval-gated escalation can separately grant time-bound access to infrastructure surfaces over Tailscale: the Kubernetes API server, and the in-cluster monitoring stack and logs. This is a distinct surface from the ClickHouse access above — it carries no customer table data, and nothing read through it is persisted on the ClickHouse side.How access is enforced
- Approval required: every access request goes through an internal approval system with designated approvers. Engineers can’t self-grant access.
- Time-bound certificates: a temporary, time-bound certificate is generated per approved session. Access expires automatically.
- Certificate-based authentication: certificates replace password-based access for all human access to BYOC instances.
- Read-only on system tables: the certificate identity is scoped to system table reads.
- Nothing persisted on the ClickHouse side: results read during a troubleshooting session — whether from system tables, the monitoring stack, or your logs — reach the engineer’s tooling to be displayed, but are not stored in or exported back to ClickHouse infrastructure.
Auditing
Engineer activity is visible to you and audited by ClickHouse:- Customer-visible (ClickHouse): every query a ClickHouse engineer runs on your instance appears in your own
system.query_log, including the query text and the certificate identity. You can audit this from your ClickHouse service directly. - Customer-visible (infrastructure):
system.query_logcannot show the infrastructure surfaces above. Kubernetes API calls appear in your cluster’s Kubernetes audit logs, cloud API calls in your cloud audit trail, and the Tailscale connections themselves in your flow logs where you have them enabled. See Auditing the boundary for where each of these lives per cloud, including which are on by default. - ClickHouse-side: ClickHouse’s security team internally logs and audits all access requests, approvals, and Tailscale connections.
Future controls
Customer-controlled approval — where you approve each engineer access request before it takes effect — is on the roadmap. Today, approval is handled through ClickHouse’s internal escalation process.Related
- BYOC network security — how Tailscale and the network boundaries work
- BYOC privilege — IAM roles created during BYOC setup