ClickHouse 控制平面与您的 BYOC VPC 之间的连接
ClickHouse Cloud 控制平面会维护多种类型的连接，以运行和支持您的 BYOC 部署：云提供商 API 与 Kubernetes API
两条不同的控制路径很容易混淆。它们在流量来源、身份验证方式以及是否适用于 Tailscale 方面存在差异：
简而言之：只有 Kubernetes API 流量和故障排查流量可以使用 Tailscale。上述管理调用始终源自 ClickHouse Cloud 的网络，并终止于提供商端点 — 无法通过 Tailscale 路由这些调用，因为它们从一开始就不会进入您的网络。
云提供商 API 也会从另一个方向被调用，即由运行在您自己集群内的控制器发起 — 负载均衡器控制器、CSI 驱动、autoscaler、DNS 控制器以及 cert-manager。这些调用使用集群内身份，并通过您自己的出站路径发出，因此它们在您的审计记录中会以不同于管理调用的身份和来源地址出现。请参阅出站连接。
基于网络来源的权限边界
如果您的组织根据网络来源限制 IAM role 承担或 Cloud API 调用 (例如，使用aws:SourceIp 或 aws:SourceVpc 的 AWS SCP 或角色信任条件) ，这些条件会阻止 ClickHouse 的自动化操作：这些调用实际来自 ClickHouse Cloud 的网络，而非您的网络。请将 ClickHouse 创建的角色排除在此类条件之外；或者，如果必须按来源设置允许列表，请联系 ClickHouse 获取当前的出站 IP 范围。
以下部分介绍如何使用 Tailscale 私有网络进行故障排查和可选的管理访问。
Tailscale 私有网络
Tailscale 在 ClickHouse Cloud 的管理服务与你的 BYOC 部署之间提供零信任的私有网络连接。借助这一安全通道，ClickHouse 工程师无需入站公网访问或复杂的 VPN 配置，即可执行故障排查和管理操作；agent 本身仅发起出站连接，并且需要出站互联网访问权限才能连接到 Tailscale 协调服务。概述
- 管理操作：ClickHouse 管理服务与您的 BYOC 基础设施进行协同
- 故障排查访问：ClickHouse 工程师访问 Kubernetes API 服务器和 ClickHouse 系统表以进行诊断
- 指标访问：ClickHouse 的集中式监控仪表盘会访问部署在您的 BYOC VPC 内的 Prometheus 栈中的指标，使 ClickHouse 工程师能够了解该环境的可观测性状态。
BYOC 中 Tailscale 的工作原理
对于每个需要通过 Tailscale 访问的服务或端点，ClickHouse BYOC 会部署：-
Tailnet 地址注册：每个端点都会注册一个唯一的 tailnet 地址 (例如，Kubernetes API 服务器的
k8s.xxxx.us-east-1.aws.byoc.clickhouse-prd.com) -
Tailscale agent 容器：一个 Tailscale agent 容器会在你的 Kubernetes 集群中运行，负责：
- 连接到 Tailscale 协调服务器
- 注册服务，使其可被发现
- 与 Nginx pod (容器组) 协调网络设置
-
Nginx pod (容器组) ：一个 Nginx pod (容器组) ，用于：
- 终止来自 Tailscale 的 TLS 流量
- 将流量路由到 Kubernetes 集群内相应的 IP 地址
网络连接过程
-
初始连接：
- 两端的 agent (ClickHouse 工程师的环境和你的 BYOC Kubernetes 集群) 都会连接到 Tailscale 协调服务器
- 集群中的 agent 会注册 Kubernetes 服务，使其可被发现
- ClickHouse 工程师必须先在内部申请相应权限，才能看到该服务
-
连接模式：
- 直连模式：agent 会尝试通过 NAT 穿透隧道建立直接连接
- 中继模式：如果直连模式失败，通信会回退到通过 Tailscale DERP (分布式加密中继协议) 服务器中继
-
加密：
- 所有通信都会进行端到端加密
- 每个 agent 都会生成自己的公钥/私钥密钥对 (类似于 PKI)
- 无论使用直连模式还是中继模式，流量都会保持加密
安全功能
仅出站连接：- Kubernetes 集群中的 Tailscale agent 会向 Tailscale 协调/中继服务器发起出站连接
- 无需入站连接——无需在安全组规则中允许流量入站到 Tailscale agent
- 这可减少攻击面，并简化网络安全配置
- 在 Tailscale 将工程师路由到客户端点之前，工程师必须先通过内部审批流程申请访问权限
- 访问具有时效性，并会自动过期
- 所有访问都会经过审计并记录日志
管理服务访问
默认情况下，ClickHouse 管理服务通过 API 服务器的公网端点访问您的 BYOC Kubernetes 集群，而各云平台对该端点的管控方式各不相同 — 在 AWS 上通过仅包含 ClickHouse NAT gateway 地址的 IP 允许列表，在 GCP 和 Azure 上则通过云 IAM。有关各云平台的详细信息，请参见 Kubernetes API server exposure。 可选的专用终结点配置：- 您可以将 Kubernetes API 服务器配置为仅使用专用终结点
- 在这种情况下，管理服务将通过 Tailscale 访问 API 服务器 (类似于人工进行的故障排查访问) ，或者在 AWS 上通过 VPC Lattice 访问 (参见 Kubernetes API Private Connection)
- 默认情况下，会保留公网端点作为紧急调查和支持需求的备用机制；在验证私网访问后，可与 ClickHouse 协调将其完全禁用
网络流量流向
- 您的 Kubernetes 集群中的 Tailscale agent → Tailscale 协调服务器 (出站)
- 工程师机器上的 Tailscale agent → Tailscale 协调服务器 (出站)
- 在 agent 之间建立直连或中继连接
- 加密流量通过已建立的隧道传输
- 您的 Kubernetes 集群中的 Nginx pod (容器组) 终止 TLS 并将流量路由到内部服务
- Tailscale 连接仅用于管理和故障排查
- 查询流量和客户数据绝不会经过 Tailscale
- 所有客户数据始终保留在您自己的云账户中
网络边界
本节以 firewall 视角审视 BYOC deployment：涵盖所有跨越 BYOC 网络边界的 connection，无论流向如何。本节内容适用于 AWS、GCP 和 Azure；各云平台行为存在差异之处，会明确指明具体云平台。 本节使用的术语：- 入站：进入 BYOC 网络的流量——即 AWS 上的 VPC、GCP 上的 VPC 网络或 Azure 上的 VNet。
- Outbound：源自 BYOC 网络并发送至外部目标端的流量。
- 公网：可从 public internet 访问的端点。
- 私网：仅可通过私有路径访问的端点——VPC/VNet peering、AWS PrivateLink、GCP Private Service Connect、Azure Private Link 或 Tailscale。
各云提供商的对应资源
本页其余部分使用与云平台无关的通用名称。下表列出它们在各提供商中的对应资源：
在所有云平台上，通往公网的出站流量都会经由一小组固定的 NAT 地址离开你的 BYOC 网络，因此你可以在自己的出站管控策略中固定这些地址。请向 ClickHouse 团队获取你所部署环境当前使用的具体地址。在 AWS 和 GCP 上，通往提供商自身存储 API 的流量是个例外：它走上表中对应行的私有路径，不会经过 NAT gateway。
入站连接
这些负载均衡器上有时还能看到另外两个端口，但它们并不面向客户端：TCP 15021 用于服务商自身对入口网关的健康检查，不承载查询流量；MySQL 接口 (端口 3306) 目前在 BYOC 中未开放 —— 参见 FAQ。
入口网关的证书由 cert-manager 通过公共 ACME 证书颁发机构 (Let’s Encrypt) 以 DNS-01 验证方式签发，并以 Kubernetes secret 的形式存储在你自有的集群中。入口网关与 ClickHouse pod 之间的流量始终保留在你的 BYOC 网络内部 —— 参见网络内部流量。
两个负载均衡器中默认启用哪一个，取决于你的网络模型。使用 ClickHouse 托管 VPC 时，每个服务都会获得公网负载均衡器，并由 IP 访问列表保护，同时还可额外启用私网负载均衡器。使用客户管理的 VPC 时，默认设置正好相反：仅启用私网负载均衡器，除非你自行添加，否则服务不会有任何公网入口暴露面。参见连接到你的 BYOC 服务。
只要启用了公网路径，我们都强烈建议配置 IP 过滤器；你也可以添加私有路径 —— 参见私有网络设置 —— 然后彻底禁用公网访问。请注意，IP 过滤在入口代理层强制执行，因此扫描时负载均衡器端口可能显示为开放，但来自未列入名单来源的连接仍会被拒绝。
除上述监听器之外，不存在 SSH、堡垒机，也没有常驻的管理凭据。查询流量在任何方向上都不会经过 ClickHouse 自有的基础设施：你的客户端直接连接到你自有网络内的入口。还可按部署启用额外的协议端口 —— 目前的例子有基于证书身份验证的原生访问和 Arrow Flight —— 因此在依据本表编写防火墙规则之前，请与你的 ClickHouse 团队确认自身部署的确切端口集合。
Kubernetes API 服务器 暴露
ClickHouse 管理服务 如何访问 Kubernetes API 服务器，以及该访问受到哪些限制，因云平台而异：- AWS (EKS)：公网端点 通过 cluster 的公网访问 CIDR 列表限制为仅允许 ClickHouse 的 egress CIDR 范围。也可以通过 Tailscale 或 VPC Lattice 切换为仅私网访问 —— 参见 Kubernetes API Private Connection。
- GCP (GKE)：节点始终为私有。控制平面 通过其基于 DNS 的端点 (
*.gke.goog) 访问，授权依据是被模拟的 服务账号 上的container.clusters.connectIAM permission，而非 IP 允许列表。请求终止于 Google 的前端，而非你的 VPC 网络内部，但它仍是通往你的 cluster 控制平面 的一条访问路径，因此应按 inbound 访问来审查。单独的基于 IP 的 公网端点 可以禁用，禁用后基于 DNS 的端点将成为通往 控制平面 的唯一路径 —— 参见 Kubernetes API Private Connection。 - Azure (AKS)：API server 通过其公网 FQDN 访问，并由 Microsoft Entra ID 与 Azure RBAC 共同授权。API server 的授权 IP 地址范围默认不启用；如果你的 policy 有此要求，请联系 ClickHouse。也可以将该 cluster 创建为通过 Azure Private Link 访问的私有 cluster，并禁用其公网 FQDN —— 参见 Kubernetes API Private Connection。
只有 Kubernetes API 和故障排查流量可以迁移到私有路径。发往你的云提供商 API 的 management 调用源自 ClickHouse Cloud 的网络，无法经由该路径路由 —— 参见 Cloud provider APIs vs the Kubernetes API，其中也涵盖了你自己 cluster 内部的 controllers 发起的 provider API calls。
故障排查访问
入站、私网 在所有云平台上，ClickHouse Cloud 工程师均仅通过 Tailscale 接入你的部署进行故障排查，绝不经由公网。访问采用即时预配和基于证书的方式：工程师通过内部审批流程提出申请，平台为其签发短期有效的专属凭据，并在到期后自动失效。不存在共享的管理身份，也不存在长期访问权限。完整策略 (包括工程师可读取哪些表) 请参阅 ClickHouse data access。出站连接
计费抓取器
出站，私网 计费抓取器从 ClickHouse 采集用量数据，并将其发送到 ClickHouse Cloud 所有的 bucket——在 AWS 上为 S3，在 GCP 上为 Cloud Storage，在 Azure 上为 Blob Storage。 它以 sidecar 形式与 ClickHouse server 容器一同运行，并定期从 ClickHouse 系统表中抓取 CPU 和内存指标。记录以不透明的 service 标识符和 pod (容器组) 名称为键。同区域请求会通过私网路径访问 Provider equivalents 中列出的提供商存储 API，因此在 AWS 和 GCP 上，此类流量不会经过公网。告警
出站、公网 AlertManager 已配置为在你的 ClickHouse cluster 处于不健康状态时向 ClickHouse Cloud 发送告警。BYOC 的告警载荷经过刻意精简，仅包含告警名称和一个 service 标识符。 完整的监控数据集在各个云上都保留在你自己的账户中。这里需要区分两件事，因为二者的边界并不相同：- 持续导出。 计费抓取器中描述的精简用量与健康状况遥测数据，以及这些告警载荷，是唯一写入 ClickHouse 自有系统的可观测性数据。BYOC 构建中已禁用向 ClickHouse Cloud 的 Prometheus 远程写入。
- 就地读取。 ClickHouse 的监控仪表板，以及经批准的处理流程下的 ClickHouse 工程师，会通过 Tailscale 查询集群内的 Prometheus 栈和你的日志 —— 参见 Tailscale 私有网络。查询结果为了展示必然会传至 ClickHouse 侧的工具，但不会在那里持久化，底层数据也绝不会离开你的账户。
服务状态
Outbound，公网 状态导出器会将 ClickHouse 服务和 Backup 的状态信息 (即运行状态事件，而非备份内容本身) 发送到由 ClickHouse Cloud 托管的 queue：AWS 上为 SQS，GCP 上为 Pub/Sub，Azure 上为 Service Bus。正是依靠这一机制，ClickHouse Cloud 控制台才能展示运行在你账户中的服务的 status。网络内部流量
集群内部各组件之间的流量——ClickHouse 与 ClickHouse Keeper 之间、operator、入口到 ClickHouse Pod (容器组) 、监控抓取——始终不会离开您的 BYOC 网络。各云提供商均会在网络层对其自有实例之间的流量进行加密：参见 AWS、GCP 和 Azure。 默认情况下，egress 在安全组 (Security Group) 、firewall 规则和网络安全组层面均不受限制；实际建立连接的目标端仅限于 Outbound connections 中列出的地址。此外，还可为每个 service 启用可选的 egress firewall，改为强制实施目标端允许列表——如有需要，请联系 ClickHouse team。审计边界
由于整个 data plane 都运行在你自己的账户中，本页描述的各类流量都可以用你自己的工具进行观测。部分来源默认开启，其余则需要你自行启用：- 云审计追踪 (CloudTrail、Cloud Audit Logs 或 Azure Activity log) ：ClickHouse 自动化执行的每一次 role assumption、服务账号模拟 或服务主体登录，以及借此发起的每一次 cloud API 调用。
- 流日志 (VPC Flow Logs、VPC flow logs 或 NSG flow logs) ：上述穿越你自有网络的连接——客户端入口、每一条出站流量以及 Tailscale 通道。如需保留这些日志，请自行启用。对 Kubernetes API 服务器 的管理访问是个例外：在使用公网端点时，该访问终止于提供商托管的 control-plane 端点，而不是你的网络内部，因此不会出现在流日志中。此时请改为在 Kubernetes 审计日志和云审计追踪中查找；只有将 API server 切换为专用终结点后，它才会出现在流日志中。
- Kubernetes 审计日志：在 AWS 上，包含审计日志在内的 EKS control-plane 日志会投递到你账户中的 CloudWatch 日志组；在 GCP 和 Azure 上，请联系支持团队确认或为你的 cluster 启用 control-plane 审计日志。
- 数据桶和备份桶上的对象存储访问日志，以及在已启用的情况下，长期监控保留桶上的访问日志。
- 你自己的
system.query_log：由 ClickHouse 自动化或工程师执行的每一条语句，并附带对应的 identity。