設定に関する制約

user.xml 設定ファイルの profiles セクションで設定に関する制約を定義すると、ユーザーが SET クエリで一部の設定を変更できないようにできます。

​

概要

ClickHouse では、設定に対する「制約」とは、設定に適用できる制限やルールを指します。これらの制約は、データベースの安定性、セキュリティ、そして予測可能な動作を維持するために使用できます。

​

制約の定義

設定に対する制約は、user.xml 設定ファイルの profiles セクションで 定義できます。これにより、ユーザーが SETステートメントを使用して一部の設定を変更することを 禁止できます。

制約は次のように定義します。

<profiles>
  <user_name>
    <constraints>
      <setting_name_1>
        <min>lower_boundary</min>
      </setting_name_1>
      <setting_name_2>
        <max>upper_boundary</max>
      </setting_name_2>
      <setting_name_3>
        <min>lower_boundary</min>
        <max>upper_boundary</max>
      </setting_name_3>
      <setting_name_4>
        <readonly/>
      </setting_name_4>
      <setting_name_5>
        <min>lower_boundary</min>
        <max>upper_boundary</max>
        <changeable_in_readonly/>
      </setting_name_5>
      <setting_name_6>
        <min>lower_boundary</min>
        <max>upper_boundary</max>
        <disallowed>value1</disallowed>
        <disallowed>value2</disallowed>
        <disallowed>value3</disallowed>
        <changeable_in_readonly/>
      </setting_name_6>
    </constraints>
  </user_name>
</profiles>

ユーザーが制約に違反しようとすると、例外が発生し、 設定は変更されないままです。

​

制約の種類

ClickHouse でサポートされている制約には、いくつかの種類があります。

• min
• max
• disallowed
• readonly (別名 const)
• changeable_in_readonly

min 制約と max 制約は、数値設定の上限値と下限値を指定するもので、組み合わせて使用できます。

disallowed 制約は、特定の設定に対して許可しない特定の値を指定するために使用できます。

readonly または const 制約は、ユーザーが対応する設定を一切変更できないことを示します。

changeable_in_readonly 制約タイプでは、readonly 設定が 1 に設定されている場合でも、設定を min/max の範囲内で変更できます。 それ以外の場合、readonly=1 モードでは設定の変更は許可されません。

changeable_in_readonly がサポートされるのは、settings_constraints_replace_previous が有効になっている場合のみです。

<access_control_improvements>
  <settings_constraints_replace_previous>true</settings_constraints_replace_previous>
</access_control_improvements>

​

読み取り専用モードで readonly を変更可能にしない

誰にも割り当てていないプロファイルも含め、すべてのプロファイルで readonly を changeable_in_readonly のリストに含めないでください。プロファイル名はどのセッションからでも選択できます。

readonly 自体を changeable_in_readonly に指定しないでください。指定してしまうと、同じCONSTRAINTで 0 も禁止していない限り、readonly = 1 で開始したセッションが SET readonly = 0 を実行でき、そのセッションが既に持つ権限で許可されている書き込みクエリを再び実行できるようになります。

これは割り当て済みのプロファイルに限った話ではなく、定義したすべてのプロファイルで問題になります。

• SET profile はアクセスチェックの対象ではないため、どのセッションでも任意のプロファイルを名前で選択できます。誰にも割り当てていないプロファイルであっても選択可能です。ただし、そのプロファイルによって変更される内容は、そのセッションで既に有効なCONSTRAINTに照らしてチェックされます。
• HTTP 経由の場合、GET リクエストが readonly = 2 に強制されるのは、実効値がそのままでは 0 になる場合のみです。そのため、readonly = 1 を設定しつつ読み取り専用モードでの readonly の変更も許可しているプロファイルでは、GET リクエストで値を 0 に切り替えて書き込みができてしまうため、この保護が機能しなくなります。

​

複数の制約プロファイル

ユーザーに対して複数のプロファイルが有効になっている場合、制約はマージされます。 マージ処理の動作は settings_constraints_replace_previous によって決まります。

• true (推奨) : 同じ設定に対する制約はマージ時に置き換えられます。 そのため、最後の制約が使用され、それ以前の制約はすべて無視されます。 これには、新しい制約で設定されていないフィールドも含まれます。
• false (デフォルト) : 同じ設定に対する制約は、次のようにマージされます。 未設定の制約タイプはすべて前のプロファイルから引き継がれ、 設定済みの制約タイプはすべて新しいプロファイルの値で置き換えられます。

​

読み取り専用モード

読み取り専用モードは readonly 設定によって有効になります。これは readonly という CONSTRAINT の種別とは 別のものなので混同しないでください。readonly = 1 の場合でも、changeable_in_readonly CONSTRAINT が 許可していれば、通常は拒否される設定であっても変更できます。この設定の各値の意味については 設定リファレンスを、各値がどの種類のクエリを許可するか、 および HTTP インターフェイスがこの値をどのように設定するかについては クエリの権限を参照してください。

​

例

users.xml に次の行を記述します。

<profiles>
  <default>
    <max_memory_usage>10000000000</max_memory_usage>
    <force_index_by_date>0</force_index_by_date>
    ...
    <constraints>
      <max_memory_usage>
        <min>5000000000</min>
        <max>20000000000</max>
      </max_memory_usage>
      <force_index_by_date>
        <readonly/>
      </force_index_by_date>
    </constraints>
  </default>
</profiles>

次のクエリはいずれも例外をスローします:

SET max_memory_usage=20000000001;
SET max_memory_usage=4999999999;
SET force_index_by_date=1;

Code: 452, e.displayText() = DB::Exception: Setting max_memory_usage should not be greater than 20000000000.
Code: 452, e.displayText() = DB::Exception: Setting max_memory_usage should not be less than 5000000000.
Code: 452, e.displayText() = DB::Exception: Setting force_index_by_date should not be changed.

default プロファイルは特別な扱いになります。default プロファイルに定義された すべての制約はデフォルトの制約となるため、各ユーザーに対して明示的に上書きされない限り、 すべてのユーザーに適用されます。

​

MergeTree 設定の制約

MergeTree 設定には制約を設定できます。 これらの制約は、MergeTree エンジンのテーブルを作成するとき、 またはそのストレージ設定を変更するときに適用されます。

<constraints> セクションで参照する場合、MergeTree 設定名の先頭に merge_tree_ プレフィックスを付ける必要があります。

​

例

storage_policy を明示的に指定した新しいテーブルの作成を禁止できます

<profiles>
  <default>
    <constraints>
      <merge_tree_storage_policy>
        <const/>
      </merge_tree_storage_policy>
    </constraints>
  </default>
</profiles>