サポートセッションとは
- セッションゲートウェイ: トラブルシューターに組み込まれた認証済みAPIで、
enable、disable、statusエンドポイントを提供します。すべてのゲートウェイ呼び出しには、メールアドレスがオペレーターの許可リストに含まれている、短期間有効なOIDC IDトークンが必要です。 - Linux VMへのインストールで使用するローカルセッションファイル: rootアクセスでホストに直接書き込みます。
kubectl port-forward (トンネルはKubernetes API serverのTLSを経由します) またはCA発行の証明書でTLSを終端するイングレスを介してアクセスします。
オペレーターの許可リストを含むセッション方針は、clicklink clctl initの実行時に選択します。
セッションの有効化と無効化
- Kubernetes
- Linux VM
ゲートウェイは トラブルシューター ポッドのポート 8443 で待ち受けます。クラスターにアクセスできる場合は、ポートフォワード経由で接続してください。このトンネルは Kubernetes API server の TLS を利用します。次に、別の端末でセッションを有効にします。同様に、セッションの状態確認や終了も行えます。呼び出し元の OIDC アイデンティティは、オペレーター の許可リストに含まれている必要があります。認証されていない呼び出し元や許可リストにない呼び出し元には 401 または 403 が返され、その試行はログに記録されます。クラスター認証情報を必須にしたくない場合は、chart でオプトインのイングレスを介してゲートウェイを公開できます。このイングレスは CA 発行の証明書で TLS を終端します。詳細は設定を参照してください。
セッションの有効期限
session enable --duration により最大24時間まで設定できます。セッションの期限が切れるか、session disable を実行した時点で、トラブルシューターはコマンドを受け付けなくなります。セッションの無効化は即時の失効手段です。再起動やClickHouseとの協調は必要ありません。
オペレーターの許可リスト
- Kubernetes: values オーバーレイで
clctl.gateway.allowedOperatorsを設定します。リストは ConfigMap にレンダリングされ、ゲートウェイは 30 秒ごとに再読み込みします。そのため、values を変更してhelm upgradeを実行すると、ポッドを再起動せずに許可リストを更新できます。 - Linux VM: 許可リストは
/etc/clicklink/allowed-operators.txtにあり、指定したオペレーターのメールアドレスに基づいてclicklink clctl initにより書き込まれます。
セッション中にオペレーターが実行できる操作
- 明示的に指定されたテーブル許可リストに制限された、
pcm_troubleshooterユーザーとしてクラスターに対する読み取り専用 SQL。デフォルトの許可リストには、system.parts、system.merges、system.replicas、system.metrics、system.settingsなどの ClickHousesystemテーブルが含まれます。system.query_logおよびsystem.text_logは無条件で拒否されるため、クエリ履歴が外部に出ることはありません。デフォルトの許可リストにはsystem.processesも含まれており、そのqueryカラムにはその時点で実行中のステートメントのテキストが表示されます。セッション中にライブのクエリテキストを決して表示させたくない場合は、セッションのテーブル許可リストからこれを削除してください (Helm オーバーレイではtroubleshooter.allowedTables、VM 構成ファイルではtroubleshooter.allowed_tables) 。このユーザーにはテーブル単位のSELECT権限のみが付与され、書き込み、DDL、管理権限はありません。 - プロビジョニング済みのすべてのデプロイメントに対する読み取り専用の Kubernetes リソース閲覧 (アクセスバンドルは、両方のインストール先で Kubernetes ServiceAccount に関連付けられます) 。付与されたネームスペース内のポッド、ポッドログ、サービス、configmaps、イベント、PersistentVolumeClaims、デプロイメント、statefulsets、replicasets に対する
get、list、watch。プロビジョニング済みのバンドルがない場合、トラブルシューターは kubectl 型のコマンドを一切受け付けません。
exec、delete、patch 権限がないため、オペレーターはポッド内でシェルを開くことも、コネクタ経由で変更を加えることもできません。すべての権限付与と RBAC の一覧については、権限モデルのリファレンスを参照してください。
監査ログ
/var/log/clicklink/troubleshoot-audit.log に追記されます。submitted_by フィールドには各エントリに対応するアイデンティティが記録され、その内容はエントリの発生元によって異なります。ゲートウェイ呼び出しには、検証済みトークンで証明されたメールアドレスが記録され、クライアントが指定した値が記録されることはありません。VM 上でローカルに行われたセッション変更には、操作を実行したホストユーザーが記録されます。セッション中に実行されたコマンドには、認証済みコマンドチャネルで渡される組織アイデンティティが記録されます。ゲートウェイによるセッション有効化のエントリは次のようになります。
clctl.session.enable、clctl.session.disable、clctl.session.status のコマンドタイプが使用されます。enable の --reason は command_text として記録され、セッション中に実行されたコマンドも同じスキーマでログに記録されます。status は成功した呼び出しと unauthorized、forbidden、rate_limited の試行を区別するため、拒否されたアクセスもログに残ります。
VM では、clicklink clctl troubleshoot audit tail でファイルを直接読み取ります。Kubernetes では、ログはトラブルシューターのポッド内にあり、コンテナーイメージにはシェルが含まれていないため、kubectl exec を使用してバイナリに組み込まれたリーダーを呼び出します。
マスキング
/etc/clicklink/redaction-patterns.yaml で拡張またはオーバーライドできます。組み込みパターンと同じ名前のエントリは、そのパターンを置き換えます。パターンファイルが無効な場合、デーモンは起動を拒否し、clicklink clctl preflight によって検証されるため、マスキング設定が壊れている場合はデータが黙って通過するのではなく、明示的に失敗します。
- Architecture: コネクタが確立するすべての接続と、セッションを中心としたデータフロー。
- Configuration: ゲートウェイ、許可リスト、機密情報のマスキングに関する設定。
- よくある質問: 失効、監査、データegressに関するよくある質問の概要。