ClickHouseにおけるユーザーとロールの作成

ClickHouseは、RBAC アプローチに基づくアクセス制御管理をサポートしています。

ClickHouseのアクセスエンティティ:

• ユーザーアカウント
• ロール
• 行ポリシー
• 設定プロファイル
• クォータ

アクセスエンティティは次の方法で設定できます:

• SQL駆動型ワークフロー。

  この機能を有効にする必要があります。

• サーバーの設定ファイル users.xml と config.xml。

SQL駆動型ワークフローの使用をお勧めします。両方の設定方法は同時に機能するため、アカウントおよびアクセス権を管理するためにサーバー設定ファイルを使用する場合は、スムーズにSQL駆動型ワークフローに切り替えることができます。

注記

同じアクセスエンティティを両方の設定方法で同時に管理することはできません。

注記

ClickHouse Cloud Consoleのユーザーを管理する場合は、このページを参照してください。

すべてのユーザー、ロール、プロファイルなどとその付与内容を確認するには、SHOW ACCESS ステートメントを使用します。

概要

デフォルトでは、ClickHouseサーバーは default ユーザーアカウントを提供します。このアカウントはSQL駆動型アクセス制御やアカウント管理の使用を許可されていませんが、すべての権限と許可があります。 default ユーザーアカウントは、ログイン時にユーザー名が定義されていない場合や、分散クエリの際に使用されます。分散クエリ処理では、サーバーまたはクラスタの構成でユーザーとパスワードのプロパティが指定されていない場合、デフォルトのユーザーアカウントが使用されます。

ClickHouseの使用を開始したばかりの場合は、次のシナリオを考慮してください:

1. default ユーザーのためにSQL駆動型アクセス制御およびアカウント管理を有効にする。
2. default ユーザーアカウントにログインし、必要なすべてのユーザーを作成します。管理者アカウントを作成することを忘れないでください（GRANT ALL ON *.* TO admin_user_account WITH GRANT OPTION）。
3. default ユーザーのために権限を制限し、そのユーザーに対するSQL駆動型アクセス制御およびアカウント管理を無効にします。

現在のソリューションのプロパティ

• 存在しないデータベースやテーブルに対しても権限を付与できます。
• テーブルが削除された場合、そのテーブルに対応するすべての権限は取り消されません。つまり、後で同じ名前の新しいテーブルを作成しても、すべての権限は有効のままとなります。削除されたテーブルに対応する権限を取り消すには、例えば REVOKE ALL PRIVILEGES ON db.table FROM ALL クエリを実行する必要があります。
• 権限に対する有効期限の設定はありません。

ユーザーアカウント

ユーザーアカウントは、ClickHouseでの認証を可能にするアクセスエンティティです。ユーザーアカウントには以下が含まれます:

• 識別情報。
• ユーザーが実行できるクエリの範囲を定義する権限。
• ClickHouseサーバーに接続できるホスト。
• 複数のロール（役割）。
• ユーザーログイン時に適用される設定とその制約。
• 割り当てられた設定プロファイル。

権限は、GRANTクエリを使用してユーザーアカウントに付与することができ、ロールを割り当てることによっても付与できます。ユーザーから権限を取り消すために、ClickHouseはREVOKEクエリを提供します。ユーザーの権限を一覧表示するには、SHOW GRANTSステートメントを使用します。

管理クエリ:

• CREATE USER
• ALTER USER
• DROP USER
• SHOW CREATE USER
• SHOW USERS

設定の適用

設定は異なる方法で構成できます: ユーザーアカウントのために、その付与されたロール内、および設定プロファイルの中で。ユーザーのログイン時に、異なるアクセスエンティティに設定が構成されている場合、設定の値と制約は以下のように適用されます（優先順位が高いものから低いものへ）:

1. ユーザーアカウントの設定。
2. ユーザーアカウントのデフォルトロール用の設定。いくつかのロールに設定が構成されている場合、設定の適用順序は未定義です。
3. ユーザーまたはそのデフォルトロールに割り当てられた設定プロファイルからの設定。いくつかのプロファイルに設定が構成されている場合、設定の適用順序は未定義です。
4. デフォルトとして、またはデフォルトプロファイルからサーバー全体に適用される設定。

ロール

ロールは、ユーザーアカウントに付与できるアクセスエンティティのコンテナです。

ロールには以下が含まれます:

• 権限
• 設定と制約
• 割り当てられたロールのリスト

管理クエリ:

• CREATE ROLE
• ALTER ROLE
• DROP ROLE
• SET ROLE
• SET DEFAULT ROLE
• SHOW CREATE ROLE
• SHOW ROLES

権限は、GRANTクエリを使用してロールに付与できます。ロールから権限を取り消すために、ClickHouseはREVOKEクエリを提供します。

行ポリシー

行ポリシーは、ユーザーまたはロールにどの行が利用できるかを定義するフィルタです。行ポリシーには特定のテーブルのためのフィルタと、この行ポリシーを使用する必要があるロールやユーザーのリストが含まれます。

注記

行ポリシーは、読み取り専用アクセスを持つユーザーに対してのみ意味があります。ユーザーがテーブルを変更したり、テーブル間でパーティションをコピーできる場合、行ポリシーの制約は無効になります。

管理クエリ:

• CREATE ROW POLICY
• ALTER ROW POLICY
• DROP ROW POLICY
• SHOW CREATE ROW POLICY
• SHOW POLICIES

設定プロファイル

設定プロファイルは、設定のコレクションです。設定プロファイルには設定や制約が含まれており、このプロファイルが適用されるロールやユーザーのリストも含まれています。

管理クエリ:

• CREATE SETTINGS PROFILE
• ALTER SETTINGS PROFILE
• DROP SETTINGS PROFILE
• SHOW CREATE SETTINGS PROFILE
• SHOW PROFILES

クォータ

クォータはリソース使用量を制限します。詳細はクォータを参照してください。

クォータは、特定の期間のための制限のセットと、このクォータを使用するロールやユーザーのリストを含みます。

管理クエリ:

• CREATE QUOTA
• ALTER QUOTA
• DROP QUOTA
• SHOW CREATE QUOTA
• SHOW QUOTA
• SHOW QUOTAS

SQL駆動型アクセス制御およびアカウント管理の有効化

• 設定ストレージ用のディレクトリをセットアップします。

  ClickHouseは、access_control_pathサーバー設定パラメータで設定されたフォルダにアクセスエンティティの設定を保存します。

• 少なくとも1つのユーザーアカウントに対してSQL駆動型アクセス制御およびアカウント管理を有効にします。

  デフォルトでは、すべてのユーザーに対してSQL駆動型アクセス制御とアカウント管理は無効になっています。 users.xml 設定ファイルに少なくとも1つのユーザーを構成し、access_management、named_collection_control、show_named_collections、および show_named_collections_secrets の値を 1 に設定する必要があります。

SQLユーザーとロールの定義

ヒント

ClickHouse Cloudを使用している場合は、クラウドアクセス管理を参照してください。

この記事では、SQLユーザーおよびロールの定義の基本と、それらの権限や許可をデータベース、テーブル、行、カラムに適用する方法を示します。

SQLユーザーモードを有効にする

1. <default> ユーザーの users.xml ファイルでSQLユーザーモードを有効にします:

   注記

   default ユーザーは、新規インストール時に作成される唯一のユーザーであり、デフォルトではノード間通信に使用されるアカウントでもあります。

   本番環境では、SQL管理ユーザーでノード間通信が構成され、ノード間通信が <secret>、クラスタ認証情報、および/またはノード間HTTPおよびトランスポートプロトコル認証情報で設定された後、このユーザーを無効にすることが推奨されます。なぜなら、default アカウントはノード間通信に使用されるからです。

2. 変更を適用するためにノードを再起動します。

3. ClickHouseクライアントを起動します:

ユーザーの定義

1. SQL管理者アカウントを作成します:
2. 新しいユーザーにフル管理権限を付与します

ALTER権限

この記事は、権限の定義方法や、特権ユーザーが ALTER ステートメントを使用する際に権限がどのように機能するかを理解するのに役立つことを目的としています。

ALTER ステートメントは、いくつかのカテゴリに分かれており、その中には階層的なものとそうでないものがあり、明示的に定義する必要があります。

例：DB、テーブル、およびユーザーの構成

1. 管理ユーザーでサンプルユーザーを作成します

2. サンプルデータベースを作成します

3. サンプルテーブルを作成します

4. 権限を付与または取り消すためのサンプル管理ユーザーを作成します

注記

権限を付与または取り消すためには、管理ユーザーは WITH GRANT OPTION 権限を持っている必要があります。 例えば:

権限を GRANT または REVOKE するためには、そのユーザーはまずその権限を持っている必要があります。

権限を付与または取り消す

ALTER 階層:

1. ユーザーまたはロールに ALTER 権限を付与する

GRANT ALTER ON *.* TO my_userを使用すると、トップレベルの ALTER TABLE と ALTER VIEW にのみ影響します。他の ALTER ステートメントは、個別に付与または取り消す必要があります。

例えば、基本的な ALTER 権限を付与する:

権限の結果セット:

これにより、上記の例での ALTER TABLE と ALTER VIEW の下にあるすべての権限が付与されますが、 ALTER ROW POLICY のような他の特定の ALTER 権限は付与されません（階層を参照すると、ALTER ROW POLICY は ALTER TABLE または ALTER VIEW の子ではないことがわかります）。それらは明示的に付与または取り消す必要があります。

ALTER 権限のサブセットのみが必要な場合は、それぞれを個別に付与できますが、その権限にサブ権限がある場合は自動的に付与されます。

例えば:

権限は次のように設定されます:

これにより、以下のサブ権限も付与されます:

2. ユーザーとロールから ALTER 権限を取り消す

REVOKE ステートメントは、GRANT ステートメントと同様に機能します。

ユーザー/ロールにサブ権限が付与されている場合、そのサブ権限を直接取り消すか、継承している上位の権限を取り消すことができます。

例えば、ユーザーに ALTER ADD COLUMNが付与されている場合

権限は個別に取り消すことができます:

または、すべての上位レベルから取り消すこともできます（すべてのCOLUMNサブ権限を取り消す）:

追加情報

権限は、WITH GRANT OPTIONだけでなく、実際にその権限を持っているユーザーによって付与されなければなりません。

1. 管理ユーザーに権限を付与し、一連の権限を管理できるようにします 以下はその例です:

これで、ユーザーは ALTER COLUMN とそのすべてのサブ権限を付与または取り消すことができます。

テスト

1. SELECT 権限を追加します

2. ユーザーにカラム追加権限を付与します

3. 制限付きユーザーでログインします

4. カラムを追加するテスト

4. カラムを削除するテスト

5. 権限を付与するために管理者をテスト

6. アルターユーザーでログインします

7. サブ権限を付与します

8. アルターユーザーが持っていない権限を付与しようとするテスト

まとめ ALTER 権限はテーブルおよびビューに対して階層的ですが、他の ALTER ステートメントではそうではありません。権限は細かいレベルで設定することも、一群の権限として設定することもでき、同様に取り消すこともできます。権限を付与または取り消すユーザーには、ユーザーに権限を設定するための WITH GRANT OPTION が必要であり、またその権限自体を持っている必要があります。実行ユーザーは、自分自身が権限付与オプションを持っていない場合、自分の権限を取り消すことはできません。