ClickHouseでのユーザーとロールの作成

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

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

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

アクセスエンティティは以下を使用して構成できます:

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

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

• サーバーの構成ファイル users.xmlおよびconfig.xml。

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

注記

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

注記

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

すべてのユーザー、ロール、プロファイルなど、及びそのすべての権限を表示するには、SHOW ACCESS文を使用してください。

概要

デフォルトでは、ClickHouseサーバはdefaultユーザーアカウントを提供しており、このアカウントはSQL駆動のアクセス制御およびアカウント管理を使用することは許可されていませんが、すべての権利と権限を持っています。defaultユーザーアカウントは、ユーザー名が定義されていない場合、例としてクライアントからのログインや分散クエリの処理で使用されます。分散クエリ処理では、サーバーまたはクラスタの設定がuser and passwordプロパティを指定していない場合に、デフォルトのユーザーアカウントが使用されます。

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で作業している場合は、Cloudアクセス管理を参照してください。

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

SQLユーザーモードの有効化

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

   注記

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

   本番環境では、このユーザーをSQL管理者ユーザーでノード間通信が設定された後に無効にすることをお勧めします。なぜなら、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を持っている必要があり、またその権限を最初に持っていなければなりません。操作を行うユーザーが自分自身の権限を取り消すことはできません。