altinity-expert-clickhouse-grants について
ClickHouse の操作拒否を調査し、最小範囲の権限付与や認証の修正を提案するスキルです。クエリパックの実行、結果の解釈、報告書の作成を案内します。
主な機能
- 01アクセス・認証エラーの確認
- 02失敗したクエリから不足権限を特定
- 03ユーザーの権限とロールを確認
- 04最小範囲のロールベース権限を提案
- 05報告と次の対応を案内
活用シーン
- 01ACCESS_DENIED エラーの調査
- 02認証問題と権限不足の切り分け
- 03アップグレード後の権限変更の確認
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ altinity/ altinity-skills --skill altinity-expert-clickhouse-grantsインストール後、Claude Code で/altinity-expert-clickhouse-grantsを入力して読み込まれたか確認します。
同梱ファイルchecks.sqlreference.md
詳細
GRANT および認証エラー
system.errors、system.query_log、system.grants、system.role_grants から、ブロックされた操作に不足している権限を特定し、それを許可する最小限の GRANT を算出します。
接続モード、クラスター、時間範囲がまだ確定していない場合は、最初に altinity-expert-clickhouse-connection を実行してください。
クエリパック
checks.sql— 4 つのチェック:過去 24 時間のsystem.errorsにおけるアクセスエラーと認証エラー(grants-01)、例外コード 497 で失敗したクエリに不足している権限(grants-02)、該当ユーザーへの現在の GRANT(grants-03)、該当ユーザーに割り当てられたロール(grants-04)。reference.md— 背景情報(権限の種類、access_control_improvements のデフォルト値)。推奨事項の説明が必要な場合にのみ読みます。
クエリパックの実行方法
- このスキルのディレクトリにある各パックファイルを読みます(スキルローダーがディレクトリのパスを出力します)。
- ステートメントを 1 つずつ実行し、ファイル全体をまとめて実行しないでください。ステートメントは
;で終わり、-- @check <id> <title>ヘッダーで始まります。結果には ID を付けてください。 -- @requiresに従ってください。指定されたテーブルがない場合、keeperが必要なのにサーバーに Keeper/ZooKeeper がない場合、またはバージョン条件を満たさない場合は、そのステートメントをスキップします。スキップした ID とその理由を列挙してください。- クラスターのマクロがある場合は、
{cluster}をそのまま使用してください。ない場合は、接続スキルの書き換えルールを適用してください。それ以外の{placeholder}はテンプレート変数です。実際の値に置き換えてから実行するか、ステートメントをスキップしてください。 - エラーが発生した場合は、チェック ID とエラーの最初の行を記録してから続行してください。
UNKNOWN_IDENTIFIERの場合に限り、DESCRIBE TABLE system.<table>を実行して、不足しているカラムを削除してください。 severityカラムはその行の判定です。値をそのまま転記し、再判定しないでください。
解釈ルール
- grants-02 の
missing_privilegesはサーバー自身による判定です。その値からGRANTステートメントを作成し、クエリテキストから権限を推測しないでください。 - 各 GRANT の対象は、エラーを解消できる最も限定的なオブジェクトにしてください。
db.*よりカラムリストまたはdb.tableを、*.*よりdb.*を優先します。必要以上に広い GRANT は現時点ではエラーを解消しても、後で監査上の指摘になります。 - grants-04 でユーザーがロール経由ですでに権限を得ている場合は、ロールベースの GRANT を優先してください。既存のロールに付与すれば権限モデルの一貫性が保たれますが、ユーザーに直接付与すると分断されます。
- grants-01 の認証エラー(
AUTHENTICATION_FAILED、WRONG_PASSWORD、REQUIRED_PASSWORD)は権限の問題ではありません。これらに対するGRANTを提案しないでください。修正するには、ユーザーの認証方式またはホスト ACL を見直す必要があります。 - 以下の権限は、データ流出、SSRF、権限昇格につながる可能性があります。包括的な権限ではなく、必要なものだけをロールに付与してください。また、
*.*に対して付与してはいけません。SOURCESとそのメンバーであるS3、URL、FILE、REMOTE(25.7 以降ではREADとWRITEも含む)、およびSYSTEMとINTROSPECTIONは、単一のサブコマンドに対象を限定してください。 - 通常の ACCESS_DENIED の修正に、
ACCESS MANAGEMENT、WITH GRANT OPTION、displaySecretsInShowAndSelect、NAMED COLLECTION ADMIN、ALLOW SQL SECURITY NONE、IMPERSONATEを付与してはいけません。いずれも権限昇格またはシークレット漏えいにつながる経路となるため、明確な正当性が必要です。 - アップグレード後は、
access_control_improvementsのフラグselect_from_system_db_requires_grant、select_from_information_schema_requires_grant、on_cluster_queries_require_cluster_grantを確認してください。これらが有効になっている場合、以前は動作していたユーザーにもsystem.*、INFORMATION_SCHEMA.*、またはCLUSTERに対する明示的な GRANT が必要になります。このエラーは GRANT の喪失ではなく、動作の変更によるものです。
詳細調査用ステートメント
最小限の GRANT は次の形式になります。不足している権限ごとに 1 つのステートメントを出力し、最も限定的なオブジェクトと、存在する場合はロールを使用してください。
GRANT SELECT ON system.processes TO role_analytics;
GRANT role_analytics TO user_x;
レポート形式
- ヘッダー:接続モード、クラスターまたは「単一ノード」、ClickHouse のバージョン、対象期間。
- 検出結果:列が
check、severity、object、evidence、recommendationの表。検出結果ごとに 1 行を記載し、Critical を先頭にします。evidence には結果行の数値を引用します。 - 問題のなかったチェック:問題行が返されなかったチェック ID を 1 行で列挙します。
- スキップしたチェックと失敗したチェック:ID と理由または最初のエラー行を記載します。このセクションは必ず含めてください。
- 次のステップ:次に読み込むスキルと、すぐに実施するアクション。
次のスキル
- 何がブロックされているかではなく、誰に過剰なアクセス権があるかを確認する場合 → スキル
altinity-expert-clickhouse-securityを読み込みます - バージョン固有の権限変更を監査側のチェックで確認する必要がある場合 → スキル
altinity-expert-clickhouse-securityを読み込みます system.query_logが欠落または切り詰められており、失敗したクエリを特定できない場合 → スキルaltinity-expert-clickhouse-logsを読み込みます- 権限付与後に ON CLUSTER ステートメントが失敗またはハングする場合 → スキル
altinity-expert-clickhouse-replicationを読み込みます
コメント
Markdown 対応