権限モデル

​

アイデンティティ

• コネクタの mTLS クライアント証明書は、組織 ID をコモンネームとして持ち、すべてのデーモンをコネクタエンドポイントに対して認証します。clicklink clctl instances create も、エンドポイントを呼び出す際に同じ証明書と HMAC キーを使用します。
• pcm_scraper と pcm_troubleshooter は、scraper と troubleshooter が接続する際に使用する読み取り専用の ClickHouse ユーザーです。executor には ClickHouse ユーザーがありません。
• Troubleshooter の ServiceAccount は、プロビジョニング済みのデプロイメントごとに 1 つ存在し、サポートセッションで利用できる読み取り専用の Kubernetes ビューを提供します。
• pcm-executor は、マネージドサービスのライフサイクルを管理する executor の Kubernetes ServiceAccount です。ValidatingAdmissionPolicy により、その書き込みはサービスのネームスペースに限定されます。
• pcm-platform は、プラットフォーム更新に使用される executor のアイデンティティです。clicklink clctl platform approve を実行すると有効期間 2 時間のトークンが発行され、自動更新されることはありません。承認と承認の間、executor はプラットフォーム層への書き込みアクセスを持ちません。
• サービスごとの IAM ロール (デフォルトでは CH-S3-<service>-<region>-00-Role) は、clicklink clctl executor prepare がお客様の認証情報を用いて作成します。このロールは当該サービスのデータおよびバックアップ用バケットにスコープが限定され、当該サービスの Kubernetes ServiceAccount からのみ信頼されるため、executor も ClickHouse もこれを assume できません。
• コネクタ EC2 VM のインスタンスプロファイルは、プラットフォームへの直接アクセスのために、チャートのログインとイメージチェックの両方で、お客様の環境の読み取り専用 ECR プラーロールを assume します。承認 CLI も同じインスタンスプロファイルの経路を使用します。workstation の AWS プロファイルや SSO 認証情報がこれを置き換えることはありません。その他の ECR チャートレジストリでは、ambient な AWS 認証情報が使用されます。イメージのプルは、お客様のノード上でそれぞれのプルロールのもとで実行されます。executor は、お客様のバケットや IAM に対する認証情報を一切保持せず、S3 や IAM の呼び出しも行いません。レジストリ認証情報を参照してください。
• お客様自身の認証情報が、あらゆる権限を適用します。具体的には、init --managed における executor のアクセス権限、prepare におけるバケットとロール、approve における各プラットフォーム更新の permission に関する部分、そして teardown におけるクリーンアップです。

​

コネクタでできること

​

送信接続

​

ClickHouse 権限

CREATE USER IF NOT EXISTS `pcm_scraper` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';
ALTER USER `pcm_scraper` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';

GRANT SELECT ON `system`.`asynchronous_metric_log` TO `pcm_scraper`;
GRANT SELECT ON `system`.`metric_log` TO `pcm_scraper`;
GRANT SELECT ON `system`.`server_settings` TO `pcm_scraper`;
GRANT SELECT ON `system`.`tables` TO `pcm_scraper`;
GRANT SELECT ON `system`.`warnings` TO `pcm_scraper`;
GRANT SELECT ON `system`.`user_directories` TO `pcm_scraper`;
GRANT READ ON REMOTE TO `pcm_scraper`;
GRANT SYSTEM FLUSH LOGS ON *.* TO `pcm_scraper`;

CREATE USER IF NOT EXISTS `pcm_troubleshooter` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';
ALTER USER `pcm_troubleshooter` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';

GRANT SELECT ON `system`.`asynchronous_metrics` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`build_options` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`clusters` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`columns` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`databases` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`detached_parts` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`disks` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`events` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`formats` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`functions` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`grants` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`merges` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`metrics` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`mutations` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts_columns` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts_summary` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`processes` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`replicas` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`replication_queue` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`roles` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings_profile_elements` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings_profiles` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`storage_policies` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`table_engines` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`tables` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`users` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`user_directories` TO `pcm_troubleshooter`;

​

Kubernetes RBAC

​

スクレイパーとトラブルシューター

​

Executor

​

プラットフォーム アイデンティティ

​

コネクタができないこと

• ClickHouse のデータや状態への書き込みはできません。 上記の権限には INSERT も DDL も含まれず、ユーザー管理・設定・プロセス制御の権限もありません。唯一のシステム系権限である scraper の SYSTEM FLUSH LOGS は、ログテーブルがすでにバッファしている内容を永続化させるだけです。executor は ClickHouse ユーザーを持ちません。いかなるコンポーネントも、ClickHouse 経由でデータ、スキーマ、ユーザー、設定を変更することはできません。
• exec はできません。 pods/exec を含む RBAC は存在せず、どのコンポーネントもお客様のポッド内でコマンドを実行できません。
• サービスおよびプラットフォームのネームスペース外への書き込みはできません。 scraper と troubleshooter は delete も patch も保持していません。唯一のミューテーションは、コネクタ自身の mTLS Secret に対する名前を厳密に指定した update と、serviceaccounts/token に対する create だけです。後者は自身の ServiceAccount 向けに短命なトークンを発行するだけで、保存済みオブジェクトは一切変更しません。admission はサービスのプレフィックス外への executor の書き込みを拒否し、プラットフォームへの書き込みはお客様が発行したトークンが有効な間だけ可能です。
• アクセス許可を付与する権限はありません。 プラットフォームの Namespace、CRD、ServiceAccount、RBAC、webhook および admission の設定、PriorityClass、StorageClass は、approve の実行時にお客様の認証情報で適用されます。executor のプラットフォーム アイデンティティは、権限昇格も bind も impersonate も行えません。サービスのネームスペース内では、executor はすでに自身が保持しているアクセス許可を付与する Role しか作成できません。
• お客様の bucket や IAM の認証情報は持ちません。 clicklink clctl executor prepare が bucket とサービスごとの role を作成し、clicklink clctl executor teardown がそれらを削除します。いずれもお客様の認証情報で実行されます。その role を assume できるのは当該サービスのポッドだけです。プラットフォームへの直接アクセスでは、executor はコネクタの EC2 VM のインスタンスプロファイルを使用して読み取り専用の ECR プラー role を assume し、チャートへのログインとイメージ確認の両方を行います。その他の ECR チャートレジストリではアンビエントな AWS 認証情報を使用します。identities を参照してください。クラウド API の呼び出し先は ECR と STS のみであり、お客様のデータを読み取ったり削除したりすることはできません。
• お客様の default user のパスワードは知り得ません。 clicklink clctl executor prepare がお客様側でパスワードを生成し、一度だけ表示します (入力をフラグとして渡す場合は clicklink clctl instances create が行います) 。送信されるのはそのハッシュのみであるため、コネクタも ClickHouse Cloud も元のパスワードを復元できません。
• インバウンドの通信は一切ありません。 ClickHouse Cloud がお客様の環境に向けて connection を開くことはありません。コマンドの経路は 2 本のアウトバウンド WebSocket のみです。troubleshooter は、お客様が有効化したサポートセッションがアクティブでない限り、すべてのコマンドを拒否します。executor は、お客様が ClickHouse に管理を依頼したサービスに対してのみ、上記のスコープ内でライフサイクルコマンドを受け付けます。session 中であっても、troubleshooter は双方で制限されます。ClickHouse へのクエリはテーブルの許可リストに限定され、query_log と text_log は拒否されるため、これらが許可されることはありません。Kubernetes へのアクセスは、ネームスペーススコープの Role が付与する読み取り専用のビューとポッドのログに限定されます。

​

対応が必要な項目

• マネージドモードの有効化。 executorが動作し、そのKubernetes 権限が存在するのは、initでマネージドモードを有効にした後のみです。権限はクラスター管理者権限で適用されます。マネージドサービスを参照してください。
• サービスの作成。 clicklink clctl executor prepare はお客様のAWS 認証情報で実行され、bucketsとIAM ロールを作成します。clicklink clctl instances create は定義を送信します。この両方がなければ、ClickHouse Cloudはお客様のクラスター内にサービスを作成できません。サービスの作成を参照してください。
• プラットフォームの更新。 プラットフォームコンポーネントの各更新は、該当するbundleに対して clicklink clctl platform approve を実行した後にのみ適用されます。発行されるトークンは2時間で失効し、更新されることはありません。プラットフォームの更新を参照してください。
• 削除後のクリーンアップ。 サービスを削除しても、削除されるのはそのKubernetes resourcesのみです。お客様の認証情報で実行する clicklink clctl executor teardown により、IAM ロールが削除され、明示的なフラグを指定した場合にのみデータとbackupsも削除されます。サービスの削除を参照してください。
• サポートセッション。 対話型のトラブルシューティングは、有効にしたセッション内でのみ実施されます。セッションの有効期間はデフォルトで4時間、最長24時間です。無効化は直ちに反映されます。サポートセッションを参照してください。
• オペレーターの許可リスト。 すべてのゲートウェイリクエストには、認証済みメールアドレスが許可リストに含まれるOIDCトークンが必要です。許可リストが空の場合はアクセスできません。リストはお客様が管理します。設定ガイドを参照してください。
• ゲートウェイの公開。 セッションゲートウェイは、有効にしない限り無効であり、イングレスを使用しない限りポートフォワード経由でのみアクセスできます。VM では、セッションコマンドから通信する前に、各オペレーターが自己署名証明書のフィンガープリントを固定するか、--gateway-ca として渡したCA bundleで検証する必要があります。
• ネットワークegress。 強制適用CNI 環境では、networkPolicy.allowEgressCIDRs にCIDRを列挙するまで、いずれのデーモンもお客様のコネクタエンドポイントに到達できません。executorにはKubernetes API serverのCIDR (networkPolicy.apiserverCIDRs) も必要であり、これは init --managed がクラスターのVPCから導出します。プラットフォームチャートをAmazon ECRから取得する場合は、ECRおよびSTSの範囲も追加してください。

​

アクセスの帰属の仕組み

• デプロイメントのアイデンティティ。 mTLS クライアント証明書のコモンネームは組織 ID であり、その単一の DNS name はエンドポイントホストに紐付けられています。これにより、すべての API 接続を組織に帰属させられます。更新は自動的にデーモン内で行われ、鍵素材を扱う operator は存在しません。
• リクエストの完全性。 すべての API request には、登録時に発行された鍵ペアを用いて、method、path、timestamp、ボディのハッシュに対して生成した HMAC-SHA256 署名 (Authorization: HMAC-SHA256 AccessKey=..., Signature=..., Timestamp=...) も付加されます。
• operator のアイデンティティ。 ゲートウェイ呼び出しは、operator の OIDC ID トークンによって証明され、identity provider の JWKS に対して検証されたメールアドレスに帰属します。トークンが利用可能な場合、自己申告の name が信頼されることはありません。
• ライフサイクル commands。 executor は受け取ったすべてのコマンドを、その始点 (ClickHouse Cloud またはローカルの clicklink clctl 呼び出し) 、stage、結果とともにローカルストアへ記録します。結果はコマンドチャネル経由で報告されます。記録は clicklink clctl commands list および clicklink clctl commands get で参照できます。CLI reference を参照してください。
• プラットフォームの承認。 承認した bundle のダイジェストは pcm-platform ServiceAccount に記録されます。認証情報によって適用されたすべての object にはコンテンツハッシュが付与され、executor は書き込みを行う前にこれを検証します。それ以外のダイジェストを持つ bundle は拒否されます。
• 監査証跡。 受理・ブロックを問わず、すべての session コマンドは、コマンドチャネルから得た組織のアイデンティティとともに NDJSON の監査ログに追記されます。ゲートウェイ呼び出しは、証明された operator のメールアドレスとともに、トラブルシューターのログに structured な clctl.gateway 行として記録されます。VM のローカル session の変更では、ホストの USER が session.json に記録されます。監査ログは clicklink clctl troubleshoot audit tail で参照できます。CLI reference を参照してください。

​

データ最小化のデフォルト

• query_log はデフォルトで scrape 対象から除外されます。 そのカラムにはリテラル値を含む生の SQL が格納されており、個人データやシークレットが含まれる可能性があります。明示的に追加しない限り境界の外に出ることはありません。
• トラブルシューターは許可リストに登録されたテーブルのみを読み取ります。 query_log と text_log は許可リストの設定自体で拒否されるため、許可されることはなく、クエリ履歴が読み取られることもありません。デフォルトの許可リストには system.processes (実行中のクエリテキスト) が含まれています。セッション中もこれを秘匿する必要がある場合は、この設定 (Kubernetes では troubleshooter.allowedTables、VM では troubleshooter.allowed_tables) から削除してください。
• トラブルシューターの出力はすべて redact されます。 組み込みのパターンに加え、ユーザーが定義したパターンも適用されます。組み込みパターンは IPv4 および IPv6 アドレス、bearer トークン、AWS access key、メールアドレス、JWT、SSH 秘密鍵、接続文字列に含まれる認証情報をカバーします。パターンファイルが不正な場合、デーモンは redact されないまま実行するのではなく、起動そのものを拒否します。
• マネージドサービスのステータスはメタデータのみです。 executor が報告するのは、サービスの状態、レプリカ数、バージョン、コマンドの実行結果です。サービスのテーブルや bucket を読み取ることは決してありません。
• 認証情報は保存時に最小化されます。 provisioning 用の SQL に含まれるのは bcrypt ハッシュのみで、平文のパスワードは含まれません。マネージドサービスの default ユーザーのパスワードは一度だけ表示され、それ以降はハッシュとしてのみ外部に出ます。enrollment token がコマンドライン、ディスク、ログに書き込まれることはありません。鍵は Kubernetes Secrets またはモード 0600 のファイルに保管されます。