メインコンテンツへスキップ
このページはClickHouse Cloudには該当しません。ここで説明している手順は、ClickHouse Cloud サービスでは自動化されています。
このガイドでは、OpenSSL 証明書を使用して接続を検証するよう ClickHouse を設定するための、シンプルで最小限の構成を説明します。このデモでは、適切な設定で接続できるように、自己署名の認証局 (CA) 証明書と秘密鍵を作成し、あわせてノード証明書も用意します。
TLS の実装は複雑で、完全に安全かつ堅牢なデプロイメントを実現するには、考慮すべき点が数多くあります。ここでは、基本的な TLS 構成の例を示す入門チュートリアルを紹介します。組織に適した証明書を生成するには、PKI/セキュリティチームに相談してください。導入的な概要については、こちらの証明書の利用に関する基本チュートリアルを参照してください。
1

ClickHouse デプロイメントを作成する

このガイドは、Ubuntu 20.04 を使用し、以下のホストに DEB パッケージ (apt を使用) で ClickHouse をインストールした環境を前提に作成されています。ドメインは marsnet.local です。
ClickHouse のインストール方法の詳細については、クイックスタートを参照してください。
2

TLS 証明書を作成する

自己署名証明書の使用はデモ目的に限られ、本番環境では使用すべきではありません。証明書要求は組織による署名を前提に作成し、設定で構成する CA チェーンを使って検証できるようにする必要があります。ただし、これらの手順は設定の構成とテストに使用でき、後で実際に使用する証明書に置き換えることができます。
  1. 新しい CA で使用する秘密鍵を生成します:
  2. 新しい自己署名 CA 証明書を生成します。以下のコマンドは、CA の秘密鍵を使用して他の証明書に署名するための新しい証明書を作成します:
秘密鍵と CA 証明書は、クラスター外の安全な場所にバックアップしてください。ノード証明書を生成したら、秘密鍵はクラスターのノードから削除する必要があります。
  1. 新しい CA 証明書の内容を確認します:
  2. 各ノードの証明書要求 (CSR) を作成し、秘密鍵を生成します:
  3. CSR と CA を使用して、新しい証明書と秘密鍵のペアを作成します:
  4. subject と issuer を確認します:
  5. 新しい証明書が CA 証明書で検証できることを確認します:
3

証明書と秘密鍵を格納するディレクトリを作成して設定します。

これは各ノードで実施する必要があります。各ホストでは、それぞれに対応する適切な証明書と秘密鍵を使用してください。
  1. 各ノードで、ClickHouse からアクセス可能な場所にフォルダを作成します。デフォルトの設定ディレクトリ (例: /etc/clickhouse-server) を使用することを推奨します。
  2. 各ノードに対応する CA証明書、ノード証明書、および秘密鍵を、新しく作成した certs ディレクトリにコピーします。
  3. ClickHouse が証明書を読み取れるように、所有者とパーミッションを更新します。
4

ClickHouse Keeperを使用した基本クラスターによる環境の構成

このデプロイメント環境では、各ノードで以下の ClickHouse Keeper 設定を使用します。各サーバーにはそれぞれ固有の <server_id> が設定されます (例:ノード chnode1 には <server_id>1</server_id>、以降も同様) 。
ClickHouse Keeper の推奨ポートは 9281 です。ただし、ポートは設定可能であり、このポートが環境内の別のアプリケーションですでに使用されている場合は、別のポートに設定できます。すべてのオプションの詳細な説明については、https://clickhouse.com/docs/operations/clickhouse-keeper/ を参照してください。
  1. ClickHouse server の config.xml<clickhouse> タグ内に以下を追加します
本番環境では、config.d ディレクトリ内の別の .xml 設定ファイルを使用することを推奨します。 詳細については、https://clickhouse.com/docs/operations/configuration-files/ を参照してください。
ClickHouse Keeper が ClickHouse server に埋め込まれている場合 (上図のとおり) 、Keeper は ClickHouse ノードで TLS インターフェイスを構成する の OpenSSL セクションで定義された、server の OpenSSL 設定を使用します。ClickHouse Keeper をスタンドアロンのプロセスとして実行する場合は、同じ CA 証明書とノード証明書 / 秘密鍵の設定を含む <openSSL> セクションを Keeper の設定ファイルに追加する必要があります。詳細については、以下の スタンドアロンの ClickHouse Keeper 用に OpenSSL を構成する を参照してください。
  1. すべてのノードで Keeper の設定のコメントを外して更新し、<secure> フラグを 1 に設定します。
  2. chnode1chnode2 のクラスター設定を更新し、以下の設定を追加します。chnode3 は ClickHouse Keeper のクォーラムに使用します。
この構成では、設定されているサンプルのクラスターは 1 つだけです。テスト用のサンプルクラスターは削除するかコメントアウトする必要があります。あるいは、テスト対象の既存のクラスターがある場合は、ポートを更新し、<secure> オプションを追加する必要があります。インストール時または users.xml ファイルで default ユーザーにあらかじめパスワードが設定されていた場合は、<user<password> を設定する必要があります。
以下は、2台のサーバー (各ノードに1台) に1つの分片レプリカを持つクラスターを作成します。
  1. テスト用のReplicatedMergeTreeテーブルを作成できるよう、マクロの値を定義します。chnode1 で:
    chnode2 で:
5

ClickHouse ノードで TLS インターフェイスを設定する

以下の設定は、ClickHouse サーバーの config.xml で行います。
  1. デプロイメントの表示名を設定します (任意) 。
  2. ClickHouse が外部ポートでリッスンするように設定します。
  3. 各ノードで https ポートを設定し、http ポートを無効にします。
  4. 各ノードで ClickHouse Native のセキュアな TCP ポートを設定し、デフォルトの非セキュアポートを無効にします。
  5. 各ノードで interserver https ポートを設定し、デフォルトの非セキュアポートを無効にします。
  6. 証明書とパスを指定して OpenSSL を設定します
各ファイル名とパスは、設定対象のノードに合わせて更新する必要があります。 たとえば、chnode2 ホストで設定する場合は、<certificateFile> エントリを chnode2.crt に更新します。
詳細については、このページを参照してください。
  1. すべてのノードで gRPC 用の TLS を設定します。
    詳細については、https://clickhouse.com/docs/interfaces/grpc/ を参照してください。
  2. 少なくとも 1 つのノードで、ClickHouse client が自身の config.xml ファイル (デフォルトでは /etc/clickhouse-client/) で接続に TLS を使用するよう設定します。
  3. MySQL および PostgreSQL のデフォルトのエミュレーションポートを無効にします。
6

テスト

  1. すべてのノードを1台ずつ起動します。
  2. セキュアなポートが起動し、待ち受け状態になっていることを確認してください。各ノードでは、次の例のように表示されるはずです:
  3. ClickHouse Keeper の正常性を確認する 一般的な 4 letter word (4lW) コマンドは、TLS なしで echo を使っても動作しません。以下では、openssl を使ってこれらのコマンドを実行する方法を示します。
    • openssl で対話セッションを開始する
  • OpenSSL セッションで 4LW コマンドを送信する
  1. --secure フラグと TLS ポートを指定して ClickHouse client を起動します:
  2. https://chnode1.marsnet.local:8443/playhttps インターフェイス経由で Play UI にログインします。
ブラウザは、ワークステーションからアクセスしており、かつ証明書がクライアントマシンのルート CA ストアに含まれていないため、信頼されていない証明書として表示します。 公開認証局またはエンタープライズ CA が発行した証明書を使用している場合は、信頼済みとして表示されるはずです。
  1. レプリケートテーブルを作成します。
  2. chnode1 に2行ほど追加します:
  3. chnode2 上の行を確認して、レプリケーションを検証します:

スタンドアロンの ClickHouse Keeper 向けに OpenSSL を設定する

ClickHouse Keeper をスタンドアロンのプロセスとして実行する場合 (ClickHouse server に埋め込んで実行するのではなく) 、OpenSSL の証明書と設定は Keeper の設定ファイルで個別に構成する必要があります。これを行わないと、Keeper はクライアント通信用の secure connections (tcp_port_secure) や、Keeper ノード間の Raft レプリケーションを確立できません。 各ノードのスタンドアロンの ClickHouse Keeper の設定ファイルに、次の <openSSL> セクションを追加してください。
各ファイル名は、設定するノードに合わせて更新する必要があります。 たとえば、chnode2 ホストで設定する場合は、<certificateFile> エントリを chnode2.crt に更新してください。
<server> セクションは、セキュアな Keeper ポート (tcp_port_secure) で受け付けるクライアントからの接続に使用されます。<client> セクションは、Raft レプリケーション中に Keeper ノード間で行われる送信接続に使用されます。
上記の証明書パスでは /etc/clickhouse-keeper/certs/ を使用しています。これは、スタンドアロンの Keeper インストールで一般的なパスです。Keeper を別のパスにインストールした場合は、それに合わせて調整してください。証明書自体は、ステップ 2 で作成したものと同じです。

OpenSSL の検証モードと証明書ハンドラ

<openSSL> の設定では、ClickHouse による TLS 証明書の検証方法を制御する <verificationMode><invalidCertificateHandler> に、いくつかのオプションが用意されています。これらの設定は、clickhouse-server、clickhouse-client、およびスタンドアロンの ClickHouse Keeper に適用されます。

検証モード

<openSSL><server> または <client> セクション内で <verificationMode> を設定します。

無効な証明書ハンドラ

<openSSL><server> または <client> セクション内で <invalidCertificateHandler> を設定します。このハンドラーは、証明書の検証に失敗した場合の動作を決定します。サーバー側では、無効なクライアント証明書に対する応答を制御します。クライアント側では、無効なサーバー証明書に対する応答を制御します。

例: 証明書の検証を無効にする

証明書の検証を無効にすると、TLS の認証確認が行われなくなり、接続が中間者攻撃にさらされるおそれがあります。この設定は、隔離された開発環境またはテスト環境でのみ使用してください。
証明書の検証を完全にスキップするには (たとえば、テスト環境で自己署名証明書を使用する場合) 、verificationModenone に設定し、AcceptCertificateHandler を使用します。 clickhouse-client では、--accept-invalid-certificate CLI フラグを使用することもでき、このフラグを指定すると両方の設定が自動的に適用されます。 clickhouse-client (/etc/clickhouse-client/config.xml):
clickhouse-server (config.xml または config.d/ 内のファイル)。<server> セクションでは、クライアント証明書を検証しない場合でも、サーバー自身の証明書をクライアントに提示する必要があるため、引き続き証明書と秘密鍵のパスを指定する必要があります:
スタンドアロンの ClickHouse Keeper (Keeper設定ファイル) :

まとめ

この記事では、TLS を使用する ClickHouse 環境の構成について説明しました。本番環境では要件に応じて設定が異なり、たとえば証明書の検証レベル、プロトコル、暗号スイートなどが変わります。これで、安全な接続を構成して実装するために必要な手順を十分に理解できたはずです。
最終更新日 2026年6月29日