このページはClickHouse Cloudには該当しません。ここで説明している手順は、ClickHouse Cloud サービスでは自動化されています。
TLS の実装は複雑で、完全に安全かつ堅牢なデプロイメントを実現するには、考慮すべき点が数多くあります。ここでは、基本的な TLS 構成の例を示す入門チュートリアルを紹介します。組織に適した証明書を生成するには、PKI/セキュリティチームに相談してください。導入的な概要については、こちらの証明書の利用に関する基本チュートリアルを参照してください。
1
2
TLS 証明書を作成する
自己署名証明書の使用はデモ目的に限られ、本番環境では使用すべきではありません。証明書要求は組織による署名を前提に作成し、設定で構成する CA チェーンを使って検証できるようにする必要があります。ただし、これらの手順は設定の構成とテストに使用でき、後で実際に使用する証明書に置き換えることができます。
-
新しい CA で使用する秘密鍵を生成します:
-
新しい自己署名 CA 証明書を生成します。以下のコマンドは、CA の秘密鍵を使用して他の証明書に署名するための新しい証明書を作成します:
秘密鍵と CA 証明書は、クラスター外の安全な場所にバックアップしてください。ノード証明書を生成したら、秘密鍵はクラスターのノードから削除する必要があります。
-
新しい CA 証明書の内容を確認します:
-
各ノードの証明書要求 (CSR) を作成し、秘密鍵を生成します:
-
CSR と CA を使用して、新しい証明書と秘密鍵のペアを作成します:
-
subject と issuer を確認します:
-
新しい証明書が CA 証明書で検証できることを確認します:
3
証明書と秘密鍵を格納するディレクトリを作成して設定します。
これは各ノードで実施する必要があります。各ホストでは、それぞれに対応する適切な証明書と秘密鍵を使用してください。
-
各ノードで、ClickHouse からアクセス可能な場所にフォルダを作成します。デフォルトの設定ディレクトリ (例:
/etc/clickhouse-server) を使用することを推奨します。 - 各ノードに対応する CA証明書、ノード証明書、および秘密鍵を、新しく作成した certs ディレクトリにコピーします。
-
ClickHouse が証明書を読み取れるように、所有者とパーミッションを更新します。
4
ClickHouse Keeperを使用した基本クラスターによる環境の構成
このデプロイメント環境では、各ノードで以下の ClickHouse Keeper 設定を使用します。各サーバーにはそれぞれ固有の<server_id> が設定されます (例:ノード chnode1 には <server_id>1</server_id>、以降も同様) 。ClickHouse Keeper の推奨ポートは
9281 です。ただし、ポートは設定可能であり、このポートが環境内の別のアプリケーションですでに使用されている場合は、別のポートに設定できます。すべてのオプションの詳細な説明については、https://clickhouse.com/docs/operations/clickhouse-keeper/ を参照してください。- 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 を構成する を参照してください。-
すべてのノードで Keeper の設定のコメントを外して更新し、
<secure>フラグを 1 に設定します。 -
chnode1とchnode2のクラスター設定を更新し、以下の設定を追加します。chnode3は ClickHouse Keeper のクォーラムに使用します。
この構成では、設定されているサンプルのクラスターは 1 つだけです。テスト用のサンプルクラスターは削除するかコメントアウトする必要があります。あるいは、テスト対象の既存のクラスターがある場合は、ポートを更新し、
<secure> オプションを追加する必要があります。インストール時または users.xml ファイルで default ユーザーにあらかじめパスワードが設定されていた場合は、<user と <password> を設定する必要があります。-
テスト用のReplicatedMergeTreeテーブルを作成できるよう、マクロの値を定義します。
chnode1で:chnode2で:
5
ClickHouse ノードで TLS インターフェイスを設定する
以下の設定は、ClickHouse サーバーのconfig.xml で行います。-
デプロイメントの表示名を設定します (任意) 。
-
ClickHouse が外部ポートでリッスンするように設定します。
-
各ノードで
httpsポートを設定し、httpポートを無効にします。 -
各ノードで ClickHouse Native のセキュアな TCP ポートを設定し、デフォルトの非セキュアポートを無効にします。
-
各ノードで
interserver httpsポートを設定し、デフォルトの非セキュアポートを無効にします。 - 証明書とパスを指定して OpenSSL を設定します
各ファイル名とパスは、設定対象のノードに合わせて更新する必要があります。
たとえば、
chnode2 ホストで設定する場合は、<certificateFile> エントリを chnode2.crt に更新します。-
すべてのノードで gRPC 用の TLS を設定します。
詳細については、https://clickhouse.com/docs/interfaces/grpc/ を参照してください。
-
少なくとも 1 つのノードで、ClickHouse client が自身の
config.xmlファイル (デフォルトでは/etc/clickhouse-client/) で接続に TLS を使用するよう設定します。 -
MySQL および PostgreSQL のデフォルトのエミュレーションポートを無効にします。
6
テスト
-
すべてのノードを1台ずつ起動します。
-
セキュアなポートが起動し、待ち受け状態になっていることを確認してください。各ノードでは、次の例のように表示されるはずです:
-
ClickHouse Keeper の正常性を確認する
一般的な 4 letter word (4lW) コマンドは、TLS なしで
echoを使っても動作しません。以下では、opensslを使ってこれらのコマンドを実行する方法を示します。opensslで対話セッションを開始する
-
OpenSSL セッションで 4LW コマンドを送信する
-
--secureフラグと TLS ポートを指定して ClickHouse client を起動します: -
https://chnode1.marsnet.local:8443/playのhttpsインターフェイス経由で Play UI にログインします。
ブラウザは、ワークステーションからアクセスしており、かつ証明書がクライアントマシンのルート CA ストアに含まれていないため、信頼されていない証明書として表示します。
公開認証局またはエンタープライズ CA が発行した証明書を使用している場合は、信頼済みとして表示されるはずです。
-
レプリケートテーブルを作成します。
-
chnode1に2行ほど追加します: -
chnode2上の行を確認して、レプリケーションを検証します:
スタンドアロンの ClickHouse Keeper 向けに OpenSSL を設定する
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> を設定します。このハンドラーは、証明書の検証に失敗した場合の動作を決定します。サーバー側では、無効なクライアント証明書に対する応答を制御します。クライアント側では、無効なサーバー証明書に対する応答を制御します。
例: 証明書の検証を無効にする
verificationMode を none に設定し、AcceptCertificateHandler を使用します。
clickhouse-client では、--accept-invalid-certificate CLI フラグを使用することもでき、このフラグを指定すると両方の設定が自動的に適用されます。
clickhouse-client (/etc/clickhouse-client/config.xml):
config.xml または config.d/ 内のファイル)。<server> セクションでは、クライアント証明書を検証しない場合でも、サーバー自身の証明書をクライアントに提示する必要があるため、引き続き証明書と秘密鍵のパスを指定する必要があります: