Skip to main content

​
ClickHouse コントロールプレーンとお客様の BYOC VPC 間の接続

ClickHouse Cloud のコントロールプレーンは、お客様の BYOC デプロイメントを運用・サポートするために、いくつかの種類の接続を維持します。

​
クラウドプロバイダー API と Kubernetes API

混同しやすい 2 つの異なる制御経路があります。これらは、トラフィックの発信元、認証方法、Tailscale を適用できるかどうかが異なります。 要するに、Tailscale を使用できるのは Kubernetes API とトラブルシューティングのトラフィックのみです。上記の管理呼び出しは常に ClickHouse Cloud のネットワークから発信され、プロバイダーのエンドポイントで終端されます。そもそもお客様のネットワークに入らないため、Tailscale を介してルーティングすることはできません。 クラウドプロバイダー API は、逆方向、つまりお客様自身のクラスター内で稼働するコントローラー (ロードバランサーコントローラー、CSI ドライバー、オートスケーラー、DNS コントローラー、cert-manager) からも呼び出されます。これらの呼び出しはクラスター内の ID を使用し、お客様自身の エグレス経路を通って外部へ出るため、監査証跡には管理呼び出しとは異なる ID および異なる送信元アドレスで記録されます。Outbound connectionsを参照してください。

​
ネットワーク送信元に基づく権限境界

組織でネットワーク送信元に基づいて IAM ロールの引き受けや Cloud API 呼び出しを制限している場合 (たとえば、aws:SourceIp または aws:SourceVpc を使用する AWS SCP やロールの信頼条件) 、それらの条件によって ClickHouse の自動化がブロックされます。これらの呼び出しは、正当にもユーザー側ではなく ClickHouse Cloud のネットワークから発信されるためです。このような条件から ClickHouse が作成したロールを除外するか、送信元に基づく許可リストが必要な場合は、現在の egress IP 範囲について ClickHouse にお問い合わせください。 次のセクションでは、Tailscale private network をトラブルシューティングおよび任意の管理アクセスに使用する方法について説明します。

​
Tailscale Private Network

Tailscale は、ClickHouse Cloud の管理サービスとお客様の BYOC デプロイメント間を結ぶ、ゼロトラストのプライベートネットワーク接続を提供します。このセキュアなチャネルにより、ClickHouse エンジニアは、インバウンドのパブリックネットワークアクセスや複雑な VPN 構成を必要とせずに、トラブルシューティングや管理操作を実施できます。エージェント自体はアウトバウンド専用の接続を確立し、Tailscale 協調サービスに到達するにはアウトバウンドのインターネットアクセスが必要です。

​
概要

Tailscale は、ClickHouse のコントロールプレーン (ClickHouse の VPC 内) とお客様の BYOC データプレーン (お客様の VPC 内) の間に、暗号化されたプライベートネットワークトンネルを確立します。この接続は、以下の用途にのみ使用されます。
  • 管理操作: ClickHouse の管理サービスがお客様の BYOC インフラストラクチャと連携するため
  • トラブルシューティングアクセス: ClickHouse のエンジニアが診断のために Kubernetes API サーバーおよび ClickHouse システムテーブルにアクセスするため
  • メトリクスアクセス: ClickHouse の集中管理された監視ダッシュボードが、お客様の BYOC VPC 内にデプロイされた Prometheus スタックのメトリクスにアクセスし、ClickHouse のエンジニアがその環境のオブザーバビリティを確保できるようにするため
Tailscale は、管理およびトラブルシューティング操作専用です。クエリトラフィックや顧客データへのアクセスに使用されることは決してありません。すべての顧客データはお客様自身のクラウドアカウント内に保持され、Tailscale 接続を通じて送信されることは一切ありません。

​
BYOC における Tailscale の仕組み

Tailscale 経由でアクセスする必要がある各サービスまたはエンドポイントごとに、ClickHouse BYOC は以下をデプロイします。
  1. Tailnet アドレスの登録: 各エンドポイントは一意の tailnet アドレスを登録します (例: Kubernetes API サーバーの場合は k8s.xxxx.us-east-1.aws.byoc.clickhouse-prd.com)
  2. Tailscale エージェントコンテナー: Kubernetes クラスター内で Tailscale エージェントコンテナーが実行され、以下を担当します。
    • Tailscale の協調サーバーへの接続
    • サービスを登録して検出可能にすること
    • Nginx ポッドとのネットワーク設定の調整
  3. Nginx ポッド: Nginx ポッドは以下を行います。
    • Tailscale からの TLS トラフィックの終端
    • Kubernetes クラスター内の適切な IP へのトラフィックのルーティング

​
ネットワーク接続プロセス

Tailscale での接続確立は、次の手順で行われます。
  1. 初期接続:
    • 両端の Tailscale エージェント (ClickHouse エンジニアの環境とお使いの BYOC Kubernetes クラスター) が Tailscale の協調サーバーに接続します
    • クラスター側のエージェントが Kubernetes サービスを登録し、検出できるようにします
    • ClickHouse エンジニアがそのサービスを確認できるようにするには、社内でエスカレーションする必要があります
  2. 接続モード:
    • ダイレクトモード: エージェントは NAT トラバーサル トンネル経由で直接接続の確立を試みます
    • リレーモード: ダイレクトモードで接続できない場合、通信は Tailscale DERP (Distributed Encrypted Relay Protocol) サーバー経由のリレーモードにフォールバックします
  3. 暗号化:
    • すべての通信はエンドツーエンドで暗号化されます
    • 各 Tailscale エージェントはそれぞれ独自の公開鍵と秘密鍵のペアを生成します (PKI と同様)
    • トラフィックは、ダイレクトモードとリレーモードのどちらを使用する場合でも暗号化されたままです

​
セキュリティ機能

アウトバウンド接続のみ:
  • Kubernetesクラスター内のTailscaleエージェントは、Tailscaleの協調/リレーサーバーに対してアウトバウンド接続を開始します
  • インバウンド接続は不要です — セキュリティグループのルールで、Tailscaleエージェントへのインバウンドトラフィックを許可する必要はありません
  • これにより、攻撃対象領域が縮小され、ネットワークセキュリティの設定が簡素化されます
アクセス制御:
  • Tailscaleが顧客のエンドポイントへルーティングできるようになる前に、エンジニアは社内の承認ワークフローを通じてアクセスを申請する必要があります
  • アクセスには有効期限があり、自動的に失効します
  • すべてのアクセスは監査され、記録されます
データアクセスに関する完全なポリシー — エンジニアが参照できる内容、証明書ベース認証、顧客側の監査 — については、ClickHouse data access を参照してください。

​
管理サービスからのアクセス

デフォルトでは、ClickHouse の管理サービスは API サーバーのパブリック エンドポイント経由でお使いの BYOC Kubernetes クラスターにアクセスします。このエンドポイントの制御方法はクラウドごとに異なり、AWS では ClickHouse の NAT ゲートウェイアドレスのみを含む IP 許可リストによって、GCP と Azure ではクラウドの IAM によって制御されます。クラウドごとの詳細は Kubernetes API サーバーの公開 を参照してください。 オプションのプライベート エンドポイント設定:
  • Kubernetes API サーバーがプライベート エンドポイントのみを使用するように設定できます
  • この場合、管理サービスは Tailscale 経由で API サーバーにアクセスします (人によるトラブルシューティングアクセスと同様です)。AWS では、VPC Lattice 経由でもアクセスできます (Kubernetes API Private Connection を参照)
  • デフォルトでは、パブリック エンドポイントは緊急時の調査やサポートに備えたバックアップ手段として維持されます。プライベートアクセスが検証された後は、ClickHouse と連携して完全に無効化できます

​
ネットワークトラフィックの流れ

Tailscale の接続フロー:
  1. お使いの Kubernetes クラスター内の Tailscale エージェント → 協調サーバー (アウトバウンド)
  2. エンジニアのマシン上の Tailscale エージェント → 協調サーバー (アウトバウンド)
  3. エージェント間で直接またはリレーによる接続が確立されます
  4. 確立されたトンネルを通じて暗号化されたトラフィックが流れます
  5. お使いの Kubernetes クラスター内の Nginx ポッドが TLS を終端し、内部サービスにルーティングします
顧客データは送信されません:
  • Tailscale 接続は、管理とトラブルシューティングにのみ使用されます
  • クエリトラフィックや顧客データが Tailscale を経由することはありません
  • すべての顧客データはお客様自身のクラウドアカウント内に保持されます
BYOC で Tailscale がどのように実装されているかについて、さらに技術的な詳細は、Building ClickHouse BYOC on AWS のブログ記事を参照してください。接続後に ClickHouse のエンジニアが閲覧できる内容と、ClickHouse がそのアクセスをどのように監査するかについては、ClickHouse data accessを参照してください。

​
ネットワーク境界

このセクションでは、BYOC デプロイメントをファイアウォールの観点から説明します。つまり、BYOC ネットワークの境界を越える接続を、方向を問わずすべて対象とします。内容は AWS、GCP、Azure に適用され、クラウドごとに挙動が異なる場合は該当するクラウド名を明示します。 本セクション全体で使用する用語:
  • Inbound: BYOC ネットワーク (AWS の VPC、GCP の VPC ネットワーク、Azure の VNet) に入ってくるトラフィック。
  • Outbound: BYOC ネットワークを始点とし、外部の宛先へ送信されるトラフィック。
  • Public: パブリックインターネットから到達可能なエンドポイント。
  • Private: VPC/VNet ピアリング、AWS PrivateLink、GCP Private Service Connect、Azure プライベートリンク、または Tailscale といったプライベート経路経由でのみ到達可能なエンドポイント。

​
プロバイダーごとの対応

このページの以降では、クラウドに依存しない名称を使用します。次の表は、それらを各プロバイダーの名称に対応付けたものです: パブリックインターネットへのエグレスは、いずれのクラウドでも少数の固定された NAT アドレスを経由して BYOC ネットワークから出ていくため、これらを自社のエグレス制御で指定できます。ご利用のデプロイメントにおける現在の値は、ClickHouse チームにお問い合わせください。AWS と GCP では、プロバイダー自身のストレージ API へのトラフィックだけは例外で、上の表の行に示したプライベート経路を通り、NAT ゲートウェイを経由することはありません。

​
受信接続

これらのロードバランサーでは 2 つのポートが見えることがありますが、いずれもクライアント向けではありません。TCP 15021 は ingress gateway に対するプロバイダー自身のヘルスチェックに使用され、クエリトラフィックは通りません。また MySQL インターフェイス (ポート 3306) は現在 BYOC では公開されていません — よくある質問を参照してください。 ingress gateway の証明書は、cert-manager がパブリックな ACME certificate authority (Let’s Encrypt) から DNS-01 検証を用いて発行し、お客様自身のクラスター内に Kubernetes Secret として保存されます。ingress gateway と ClickHouse ポッド間のトラフィックは BYOC ネットワーク内にとどまります — ネットワーク内トラフィックを参照してください。 2 つのロードバランサーのどちらがデフォルトで有効になるかは、ネットワークモデルによって異なります。ClickHouse 管理 VPC では、各サービスに IP アクセスリストで保護された public load balancer が割り当てられ、それと併せて private load balancer を有効化できます。顧客管理 VPC ではデフォルトが逆になり、private load balancer のみが有効で、明示的に追加しない限りサービスにパブリックな受信経路は存在しません。BYOC サービスへの接続を参照してください。 パブリック経路が有効な場合は、IP フィルターの設定を強く推奨します。また、プライベート経路を追加し (プライベートネットワークのセットアップを参照) 、その上でパブリックアクセスを完全に無効化することもできます。なお、IP フィルタリングは ingress プロキシ層で適用されるため、スキャン時にロードバランサーのポートが開いているように見えても、許可リストにない送信元からの接続は拒否されます。
上記のリスナー以外に、SSH、踏み台ホスト、常設の管理用資格情報はいずれも存在しません。クエリトラフィックはどちらの方向においても ClickHouse 所有のインフラストラクチャを経由せず、クライアントはお客様自身のネットワーク内の ingress に直接接続します。デプロイメントごとに追加のプロトコルポートを有効化できます (現時点の例としては、証明書認証によるネイティブアクセスと Arrow Flight があります) 。そのため、この表をもとにファイアウォールルールを作成する前に、ご自身のデプロイメントにおける正確なポート構成を ClickHouse チームにご確認ください。

​
Kubernetes API サーバーの公開

ClickHouse の管理サービスが Kubernetes API サーバーに到達する経路と、そのアクセスを制限する仕組みは、クラウドごとに異なります。
  • AWS (EKS): パブリックエンドポイントは、クラスターのパブリックアクセス CIDR リストによって ClickHouse のエグレス CIDR 範囲のみに制限されます。Tailscale または VPC Lattice を使ってプライベート専用アクセスに切り替えることも可能です — Kubernetes API Private Connection を参照してください。
  • GCP (GKE): ノードは常にプライベートです。コントロールプレーンへは DNS ベースの endpoint (*.gke.goog) 経由で到達し、IP 許可リストではなく、権限借用した service account に付与された container.clusters.connect IAM permission によって認可されます。リクエストは VPC ネットワーク内部ではなく Google のフロントエンドで終端しますが、それでもクラスターのコントロールプレーンへの一つのアクセス経路であることに変わりはないため、インバウンドアクセスとして確認してください。IP ベースの独立した パブリックエンドポイントは無効化でき、その場合は DNS ベースのエンドポイントがコントロールプレーンへの唯一の経路となります — Kubernetes API Private Connection を参照してください。
  • Azure (AKS): API server へはパブリック FQDN 経由で到達し、Microsoft Entra ID と Azure RBAC によって認可されます。API サーバーの認可済み IP 範囲はデフォルトでは適用されません。ポリシー上これが必要な場合は ClickHouse にお問い合わせください。あるいは、パブリック FQDN を無効化したうえで、Azure プライベートリンク経由で接続するプライベートクラスターとしてクラスターを作成することもできます — Kubernetes API Private Connection を参照してください。
プライベート経路に移せるのは、Kubernetes API とトラブルシューティングのトラフィックのみです。クラウドプロバイダーの API に対する management 呼び出しは ClickHouse Cloud のネットワークから発信されるため、この経路を通すことはできません — Cloud provider APIs vs the Kubernetes API を参照してください。そこでは、お客様のクラスター内の controllers が行うプロバイダー API 呼び出しについても説明しています。

​
トラブルシューティングアクセス

Inbound、Private ClickHouse Cloud のエンジニアは、いずれのクラウドにおいても、トラブルシューティングのためにお客様のデプロイメントへアクセスする際、public internet を経由することはなく、必ず Tailscale 経由で接続します。アクセスは just-in-time かつ証明書ベースで、エンジニアは社内の承認 workflow を通じてアクセスをリクエストし、プラットフォームがエンジニアごとに有効期間の短い認証情報を発行、その認証情報は自動的に失効します。共有の管理者 identity は存在せず、standing access もありません。エンジニアが読み取れる table を含む policy の全文については、ClickHouse data access を参照してください。

​
Outbound connections

​
Billing scraper

Outbound、Private billing scraper は ClickHouse から使用状況データを収集し、ClickHouse Cloud が所有するバケット (AWS では S3、GCP では Cloud ストレージ、Azure では Blob Storage) へ送信します。 ClickHouse server コンテナーのサイドカーとして動作し、ClickHouse のシステムテーブルから CPU およびメモリのメトリクスを定期的に scrape します。レコードは、不透明なサービス識別子とポッド名をキーとして記録されます。同一 Region 内のリクエストは、Provider equivalents に記載された provider のストレージ API へプライベート経路を経由するため、AWS および GCP ではこのトラフィックが public internet を通ることはありません。
このストリームが伝送するのはシステムメトリクスと運用メタデータのみです。テーブルの行、カラム値、生のクエリテキストは一切含まれません。

​
Alerts

Outbound、Public AlertManager は、ClickHouse クラスターが正常でない場合に ClickHouse Cloud へ alert を送信するよう設定されています。BYOC の alert ペイロードには、意図的に alert 名とサービス識別子のみが含まれます。 監視データセットの全体は、どのクラウドにおいてもお客様自身のアカウント内に留まります。以下の 2 つは境界が異なるため、区別してください。
  • 継続的にエクスポートされるもの。 Billing scraper で説明した限定的な使用状況および health テレメトリーと、これらの alert ペイロードだけが、ClickHouse 所有のシステムに書き込まれるオブザーバビリティデータです。ClickHouse Cloud への Prometheus remote-write は、BYOC ビルドでは無効になっています。
  • その場で読み取られるもの。 ClickHouse の監視ダッシュボード、および承認された escalation の際には ClickHouse のエンジニアが、Tailscale 経由でクラスター内の Prometheus stack とお客様のログをクエリします — Tailscale Private Network を参照してください。クエリ結果は表示のため ClickHouse 側のツールに渡らざるを得ませんが、そこに永続化されるものはなく、基盤となるデータがお客様のアカウントから出ることはありません。
メトリクスは、お客様のクラスター内で稼働する Prometheus および Thanos の stack で扱い、任意でお客様自身のアカウント内のバケットに長期保持できます。この保持を有効にした場合、書き込みはプロバイダーのストレージ API へ向けて BYOC ネットワークの外に出ますが、データはお客様のアカウント内に留まります。ログは現在、ClickHouse ノードにアタッチされたノードボリュームに書き込まれます。今後のアップデートでは、同じく BYOC ネットワーク内で稼働する ClickHouse ベースのログストアである LogHouse に書き込まれる予定です。

​
サービスの状態

Outbound、Public state exporter は、ClickHouse のサービスおよびバックアップの状態情報 (バックアップの内容ではなく、稼働状況を示すイベント) を、ClickHouse Cloud が所有するキュー (AWS では SQS、GCP では Pub/Sub、Azure では Service Bus) に送信します。これにより、ClickHouse Cloud コンソール上で、お客様のアカウントで稼働中のサービスのステータスを確認できるようになります。

​
ネットワーク内トラフィック

クラスター内のコンポーネント間のトラフィック (ClickHouse から ClickHouse Keeper、operator、ClickHouse ポッドへのイングレス、監視の scrape) は、BYOC ネットワークの外に出ることはありません。各 provider は、自社の instance 間のトラフィックをネットワーク layer で暗号化します。AWS、GCP、Azure を参照してください。 egress は、既定ではセキュリティグループ、ファイアウォールルール、network security group の layer で制限されていません。実際に接続先となる宛先は Outbound connections に記載のとおりです。代わりに宛先の allowlist を適用する、service 単位の egress ファイアウォールを任意で利用することもできます。必要な場合は ClickHouse team にお問い合わせください。

​
境界の監査

データプレーン全体がお客様自身のアカウント内で稼働するため、このページで説明するフローはお客様自身のツールで観測できます。一部のソースはデフォルトで有効になっており、その他はお客様側で有効化する必要があります。
  • クラウド監査証跡 (CloudTrail、Cloud Audit Logs、または Azure Activity ログ): ClickHouse の自動化処理によるすべての role assumption、service account の権限借用、service principal のサインイン、およびそれらを用いて実行されたすべての Cloud API 呼び出し。
  • フローログ (VPC Flow Logs、VPC flow logs、または NSG flow logs): 上記のうちお客様自身のネットワークを通過する接続 — クライアントのイングレス、すべての outbound フロー、および Tailscale チャネル。保持したい場合はお客様側で有効化してください。ただし Kubernetes API サーバーへの management access は例外です。public endpoint が使用されている間、その通信はお客様のネットワーク内ではなくプロバイダーのマネージド コントロールプレーン エンドポイントで終端されるため、フローログには現れません。この通信は Kubernetes の audit logs およびクラウド監査証跡で確認してください。フローログに現れるのは、API server をプライベート エンドポイントに切り替えた後のみです。
  • Kubernetes audit logs: AWS では、audit log を含む EKS の コントロールプレーン ログがお客様のアカウント内の CloudWatch ロググループに配信されます。GCP および Azure では、クラスターの コントロールプレーン 監査ログの有効化または状態の確認についてサポートにお問い合わせください。
  • データおよびバックアップ用 bucket、ならびに有効化している場合は長期監視データの保持用 bucket における object storage のアクセスログ。
  • お客様自身の system.query_log: ClickHouse の自動化処理またはエンジニアが実行したすべてのステートメントが、実行した identity とともに記録されます。
最終更新日 2026年9月28日