Routine operations
ClickHouse Cloud’s control plane runs your BYOC deployment without reading customer data. The components that send data out of your VPC carry only operational metadata:| Component | What leaves your VPC |
|---|---|
| State exporter | Service state (health, status) to an SQS queue owned by ClickHouse Cloud. |
| Billing scraper | CPU and memory metrics to an S3 bucket owned by ClickHouse Cloud. |
| AlertManager | Cluster health alerts to ClickHouse Cloud. |
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
With approved troubleshooting access, engineers can read ClickHouse system tables only. 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. Access is scoped to system tables only.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.
- No data exported: logs and query results from troubleshooting sessions are never exported back to ClickHouse infrastructure.
Auditing
Engineer activity is visible to you and audited by ClickHouse:- Customer-visible: 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. - 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