ClickHouseでのユーザーとロールの作成
ClickHouseは、RBAC アプローチに基づくアクセス制御管理をサポートしています。
ClickHouseのアクセスエンティティ:
アクセスエンティティは次の方法で構成できます:
SQL主導のワークフローの使用をお勧めします。両方の構成方法は同時に機能するため、アカウントとアクセス権を管理するためにサーバー構成ファイルを使用している場合、SQL主導のワークフローにスムーズに切り替えることができます。
同じアクセスエンティティを両方の構成方法で同時に管理することはできません。
ClickHouse Cloudコンソールのユーザーを管理する場合は、このページを参照してください。
すべてのユーザー、ロール、プロファイルなど、およびすべての権限を見るには、SHOW ACCESS
ステートメントを使用します。
概要
デフォルトで、ClickHouseサーバーはdefault
ユーザーアカウントを提供します。このアカウントはSQL主導のアクセス制御とアカウント管理に使用できず、すべての権利と権限を持っています。default
ユーザーアカウントは、クライアントからのログインや分散クエリでユーザー名が定義されていない場合に使用されます。分散クエリ処理では、サーバーまたはクラスターの設定がuser and passwordプロパティを指定していない場合にデフォルトユーザーアカウントが使用されます。
ClickHouseの使用を開始したばかりの場合、以下のシナリオを考慮してください:
default
ユーザーに対してSQL主導のアクセス制御とアカウント管理を有効にする。default
ユーザーアカウントにログインし、必要なすべてのユーザーを作成します。管理者アカウントを作成するのを忘れないでください(GRANT ALL ON *.* TO admin_user_account WITH GRANT OPTION
)。default
ユーザーの権限を制限すると、そのためのSQL主導のアクセス制御とアカウント管理を無効にします。
現行ソリューションの特性
- データベースやテーブルが存在しなくても、権限を付与できます。
- テーブルが削除された場合、そのテーブルに対応するすべての権限は取り消されません。これは、後で同じ名前の新しいテーブルを作成しても、すべての権限が有効であることを意味します。削除されたテーブルに対応する権限を取り消すには、たとえば、
REVOKE ALL PRIVILEGES ON db.table FROM ALL
クエリを実行する必要があります。 - 権限の寿命に関する設定はありません。
ユーザーアカウント
ユーザーアカウントは、ClickHouseで誰かを認証するためのアクセスエンティティです。ユーザーアカウントには次の情報が含まれます。
- 識別情報。
- ユーザーが実行できるクエリの範囲を定義する権限。
- ClickHouseサーバーに接続を許可されたホスト。
- 設定されたロールおよびデフォルトのロール。
- ユーザーがログインしたときに適用される設定とその制約。
- 割り当てられた設定プロファイル。
権限は、GRANTクエリを介してユーザーアカウントに付与することができるか、ロールを割り当てることによって付与することができます。ユーザーから権限を取り消すには、ClickHouseはREVOKEクエリを提供します。ユーザーの権限をリストするには、SHOW GRANTSステートメントを使用します。
管理クエリ:
設定の適用
設定は、ユーザーアカウント、付与されたロール、および設定プロファイルで異なる方法で構成できます。ユーザーのログイン時に、異なるアクセエンティティに対して設定が構成されている場合、その設定の値と制約は以下のように適用されます(優先度が高い順):
- ユーザーアカウントの設定。
- ユーザーアカウントのデフォルトロールに対する設定。あるロールで設定が構成されている場合、その設定の適用順序は未定義です。
- ユーザーまたはそのデフォルトロールに割り当てられた設定プロファイルの設定。あるプロファイルで設定が構成されている場合、その設定の適用順序は未定義です。
- サーバー全体にデフォルトで適用される設定またはデフォルトプロファイルからの設定。
ロール
ロールは、ユーザーアカウントに付与できるアクセスエンティティのコンテナです。
ロールには次の情報が含まれます。
- 権限
- 設定と制約
- 割り当てられたロールのリスト
管理クエリ:
権限は、GRANTクエリを介してロールに付与できます。ロールから権限を取り消すには、ClickHouseはREVOKEクエリを提供します。
行ポリシー
行ポリシーは、ユーザーまたはロールに対してどの行が利用可能であるかを定義するフィルターです。行ポリシーには、特定のテーブルに対するフィルターが含まれ、またこの行ポリシーを使用するロールおよび/またはユーザーのリストが含まれます。
行ポリシーは、読み取り専用アクセスを持つユーザーに対してのみ意味があります。ユーザーがテーブルを変更したり、テーブル間でパーティションをコピーできる場合、行ポリシーの制約が無効になります。
管理クエリ:
設定プロファイル
設定プロファイルは、設定のコレクションです。設定プロファイルには、設定および制約、ならびにこのプロファイルが適用されるロールおよび/またはユーザーのリストが含まれます。
管理クエリ:
- CREATE SETTINGS PROFILE
- ALTER SETTINGS PROFILE
- DROP SETTINGS PROFILE
- SHOW CREATE SETTINGS PROFILE
- SHOW PROFILES
クォータ
クォータはリソース使用を制限します。詳細はクォータを参照してください。
クォータには、特定の期間に対する制限のセットと、このクォータを使用するロールおよび/またはユーザーのリストが含まれます。
管理クエリ:
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ユーザーモードの有効化
<default>
ユーザーの下にあるusers.xml
ファイルでSQLユーザーモードを有効にします:
default
ユーザーは、クリーンインストールで作成される唯一のユーザーであり、デフォルトでノード間通信に使用されるアカウントです。
本番環境では、SQL管理者ユーザーを使用してノード間通信を設定し、通信が<secret>
、クラスター資格情報、および/またはノード間のHTTPおよびトランスポートプロトコル資格情報で設定されると、default
ユーザーは無効にすることをお勧めします。
-
変更を適用するためにノードを再起動します。
-
ClickHouseクライアントを起動します:
ユーザーの定義
- SQL管理者アカウントを作成します:
- 新しいユーザーに完全な管理権を付与します
権限の変更
この記事は、権限の定義方法と、特権ユーザーがALTER
ステートメントを使用する際の権限の動作についての理解を深めるためのものです。
ALTER
ステートメントは、階層的なものとそうでないものに分かれ、階層的なものは明示的に定義する必要があります。
例:データベース、テーブル、ユーザー構成
- 管理者ユーザーを使用して、サンプルユーザーを作成します
- サンプルデータベースを作成します
- サンプルテーブルを作成します
- 権限を付与/取り消すためのサンプル管理者ユーザーを作成します
権限を付与または取り消すには、管理者ユーザーがWITH GRANT OPTION
権限を持っている必要があります。
たとえば:
権限をGRANT
またはREVOKE
するには、ユーザー自身が最初にそれらの権限を持っている必要があります。
権限の付与または取り消し
ALTER
の階層:
- ユーザーまたはロールに
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
権限のサブセットのみが必要な場合は、それぞれを個別に付与できます。その権限にサブ権限がある場合は、それらも自動的に付与されます。
たとえば:
付与される権限は:
これにより、次のサブ権限も付与されます:
- ユーザーおよびロールから
ALTER
権限を取り消す
REVOKE
ステートメントは、GRANT
ステートメントと同様に機能します。
ユーザー/ロールがサブ権限を付与されている場合、そのサブ権限を直接取り消すか、継承先の上位権限を取り消すことができます。
たとえば、ユーザーにALTER ADD COLUMN
が付与されている場合
権限を個別に取り消すことができます:
または、上位レベルのいずれかから取り消すこともできます(COLUMNのサブ権限をすべて取り消す):
追加情報
権限は、WITH GRANT OPTION
だけでなく、その権限自体も持っているユーザーによって付与される必要があります。
- 管理者ユーザーに権限を付与し、権限セットを管理できるようにします 以下に例を示します:
これで、そのユーザーはALTER COLUMN
およびすべてのサブ権限を付与または取り消すことができます。
テスト
SELECT
権限を追加します
- ユーザーにカラム追加権限を追加します
- 制限されたユーザーでログインします
- カラムの追加をテストします
- カラムの削除をテストします
- 権限を付与することによる管理者のテスト
- ALTER管理者ユーザーでログインします
- サブ権限を付与します
- ALTER管理者ユーザーが持っていない権限を付与しようとするが、それは管理者ユーザーの付与のサブ権限ではないことをテストします。
要約
ALTER
権限は、テーブルとビューに関しては階層的ですが、他のALTER
ステートメントには階層がありません。権限は細かいレベルで設定することもできますし、権限のグループ化によって設定することもできますし、同様に取り消すことも可能です。権限を付与または取り消すユーザーは、ユーザーに権限を設定するためにWITH GRANT OPTION
を必要とし、そのユーザー自身もその権限を持っている必要があります。権限を取り消すことは、権限を持っていない場合はできません。