ClickHouse のユーザーアカウントを変更します。
構文:
ALTER USER [IF EXISTS] name1 [RENAME TO new_name |, name2 [,...]]
[ON CLUSTER cluster_name]
[{VALID UNTIL datetime | VALID FOR interval}]
[NOT IDENTIFIED | RESET AUTHENTICATION METHODS TO NEW | {IDENTIFIED | ADD IDENTIFIED} {[WITH {plaintext_password | sha256_password | sha256_hash | double_sha1_password | double_sha1_hash}] BY {'password' | 'hash'}} | WITH NO_PASSWORD | {WITH ldap SERVER 'server_name'} | {WITH kerberos [REALM 'realm']} | {WITH ssl_certificate CN 'common_name' | SAN 'TYPE:subject_alt_name'} | {WITH ssh_key BY KEY 'public_key' TYPE 'ssh-rsa|...'} | {WITH http SERVER 'server_name' [SCHEME 'Basic']} [{VALID UNTIL datetime | VALID FOR interval}] [GRANTS (privilege ON object [,...])]
[, {[{plaintext_password | sha256_password | sha256_hash | ...}] BY {'password' | 'hash'}} | {ldap SERVER 'server_name'} | {...} | ... [,...]]]
[[ADD | DROP] HOST {LOCAL | NAME 'name' | REGEXP 'name_regexp' | IP 'address' | LIKE 'pattern'} [,...] | ANY | NONE]
[IN access_storage_type]
[DEFAULT ROLE role [,...] | ALL | ALL EXCEPT role [,...] ]
[GRANTEES {user | role | ANY | NONE} [,...] [EXCEPT {user | role} [,...]]]
[DROP ALL PROFILES]
[DROP ALL SETTINGS]
[DROP SETTINGS variable [,...] ]
[DROP PROFILES 'profile_name' [,...] ]
[ADD|MODIFY SETTINGS variable [=value] [MIN [=] min_value] [MAX [=] max_value] [READONLY|WRITABLE|CONST|CHANGEABLE_IN_READONLY] [,...] ]
[SET variable [=value] [MIN [=] min_value] [MAX [=] max_value] [READONLY|WRITABLE|CONST|CHANGEABLE_IN_READONLY] [,...] ]
[ADD PROFILES 'profile_name' [,...] ]ALTER USER を使用するには、ALTER USER 権限を持っている必要があります。
SET variable = value は MODIFY SETTING variable = value の別名です。これは 1 つの設定だけをその場で変更し、ほかの設定はそのまま維持します。設定リスト全体を置き換え、さらにすべての継承元 (親) プロファイルも削除してしまう、裸の SETTINGS 句よりも、こちら (または MODIFY SETTING) を優先してください。
GRANTEES 句
このユーザーが GRANT OPTION 付きで必要なすべてのアクセス権を付与されていることを条件に、このユーザーから 権限 を受け取ることが許可されるユーザーまたはロールを指定します。GRANTEES 句のオプションは次のとおりです。
user— このユーザーが権限を付与できるユーザーを指定します。role— このユーザーが権限を付与できるロールを指定します。ANY— このユーザーは誰にでも権限を付与できます。これはデフォルト設定です。NONE— このユーザーは誰にも権限を付与できません。
EXCEPT 式を使用すると、任意のユーザーまたはロールを除外できます。たとえば、ALTER USER user1 GRANTEES ANY EXCEPT user2 です。これは、user1 が GRANT OPTION 付きでいくつかの権限を付与されている場合、それらの権限を user2 を除く誰にでも付与できることを意味します。
例
割り当てられたロールをデフォルトに設定します:
ALTER USER user DEFAULT ROLE role1, role2事前にユーザーにロールが割り当てられていない場合、ClickHouse では例外が発生します。
割り当てられているすべてのロールをデフォルトに設定します:
ALTER USER user DEFAULT ROLE ALL今後ユーザーにロールが割り当てられた場合、そのロールは自動的にデフォルトになります。
role1 と role2 を除き、割り当てられているすべてのロールをデフォルトに設定します。
ALTER USER user DEFAULT ROLE ALL EXCEPT role1, role2john アカウントのユーザーが、自身の権限を jack アカウントのユーザーに付与できるようにします。
ALTER USER john GRANTEES jack;既存の認証方式は保持したまま、ユーザーに新しい認証方式を追加します。
ALTER USER user1 ADD IDENTIFIED WITH plaintext_password by '1', bcrypt_password by '2', plaintext_password by '3'注記:
- 古いバージョンのClickHouseでは、複数の認証方式の構文がサポートされていない場合があります。そのため、ClickHouse serverにそのようなユーザーが存在する状態で、その構文をサポートしていないバージョンにダウングレードすると、それらのユーザーは使用不能になり、一部のユーザー関連操作も正常に行えなくなります。問題なくダウングレードするには、事前にすべてのユーザーが単一の認証方式のみを持つように設定しておく必要があります。あるいは、適切な手順を踏まずにserverをダウングレードしてしまった場合は、問題のあるユーザーを削除する必要があります。
no_passwordは、セキュリティ上の理由から他の認証方式と併用できません。 そのため、no_password認証方式をADDすることはできません。以下のクエリはエラーになります:
ALTER USER user1 ADD IDENTIFIED WITH no_passwordユーザーの認証方式を削除して no_password を使用する場合は、以下の置換形式で指定する必要があります。
認証方式をリセットし、クエリで指定したものを追加します (ADD キーワードを伴わない先頭の IDENTIFIED の効果) :
ALTER USER user1 IDENTIFIED WITH plaintext_password by '1', bcrypt_password by '2', plaintext_password by '3'認証方式をリセットし、最後に追加した方式のみを保持します:
ALTER USER user1 RESET AUTHENTICATION METHODS TO NEWVALID UNTIL 句
認証方式の有効期限の日付と、必要に応じて時刻を指定できます。パラメータには文字列を指定します。日時には YYYY-MM-DD [hh:mm:ss] [timezone] フォーマットの使用を推奨します。デフォルトでは、このパラメータは 'infinity' です。指定できるデッドラインの範囲は、1900-01-01 00:00:00 UTC から 9999-12-31 09:59:59 UTC までです。後者は、すべてのタイムゾーンで年 9999 の範囲内に収まる最も遅い時点であるため、保存された時点が表示時にクランプされることはありません。過去のデッドラインは、認証情報がすでに期限切れであることを意味します。1970-01-01 00:00:01 UTC より前のデッドラインは、「すでに期限切れ」であることを示すマーカーとしてのみ受け入れられます。これらは Unix epoch の 1 秒後にあたる最小の期限切れ時点 (1970-01-01 00:00:01 UTC) に正規化されるため、SHOW CREATE USER では指定したデッドラインではなく、この時点が表示されます。この時点以降のデッドラインは正確に保存されます。
デッドラインは絶対時点として保存されますが、SHOW CREATE USER と system.users ではサーバーまたはセッションのタイムゾーンで表示されます。そのため、同じ保存済みの時点でも、設定が異なるサーバーでは異なる現地時刻の文字列として表示されます。たとえば、上記の正規化された期限切れ時点は、UTC のサーバーでは 1970-01-01 00:00:01、Pacific/Kiritimati のサーバーでは 1970-01-01 14:00:01 と表示されます。適用時には、表示結果ではなく保存された時点が常に使用されます。
句の配置によって、適用対象となる認証方式が決まります。
IDENTIFIED句の前に配置した場合 (またはクエリで認証方式をまったく指定しない場合) : デッドラインは、ユーザーのすべての認証方式に適用されるユーザーレベルのデッドラインです。- 認証方式の後に配置した場合: デッドラインはその方式にのみ適用されます。したがって、
IDENTIFIEDリスト全体の後に記述した句は最後の方式にのみ適用され、先行する方式には有効期限が設定されません。
例:
ALTER USER name1 VALID UNTIL '2025-01-01'ALTER USER name1 VALID UNTIL '2025-01-01 12:00:00 UTC'ALTER USER name1 VALID UNTIL 'infinity'ALTER USER name1 VALID UNTIL '2025-01-01' IDENTIFIED WITH plaintext_password BY 'password_1', bcrypt_password BY 'password_2'— ユーザーレベルのデッドラインは両方の方式に適用されます。ALTER USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID UNTIL '2025-01-01'— デッドラインはbcrypt_password方式にのみ適用されます。plaintext_passwordに有効期限はありません。
VALID FOR 句
VALID FOR句は、VALID UNTILの便利な短縮表記です。絶対的な日付と時刻の代わりにインターバルを指定でき、クエリの実行時点における現在時刻にそのインターバルを加算して有効期限のデッドラインが計算されます。結果はVALID UNTIL形式で保存されるため、SHOW CREATE USERでは常に解決済みの絶対デッドラインが表示されます。配置規則はVALID UNTILと同じです。IDENTIFIEDの前 (または認証方式が指定されていない場合) に指定すると、すべての認証方式に適用されるユーザーレベルのデッドラインになります。一方、認証方式の後に指定すると、その認証方式にのみ適用されます。デッドラインは秒精度で保存・適用されるため、サブ秒のインターバル (NANOSECOND、MICROSECOND、MILLISECOND) は受け付けられません。指定可能な最小単位はSECONDです。負のインターバルは、認証情報をすでに期限切れとしてマークする方法として使用できます。結果のデッドラインが1970-01-01 00:00:01 UTCより前になる場合は、その最小の期限切れ時点に正規化され、SHOW CREATE USERではその値が表示されます。これはVALID UNTILで説明されているとおり、サーバーまたはセッションタイムゾーンで表示されます。
例:
ALTER USER name1 VALID FOR INTERVAL 1 DAYALTER USER name1 VALID FOR INTERVAL 3 MONTHALTER USER name1 VALID FOR INTERVAL 30 DAY IDENTIFIED WITH plaintext_password BY 'password_1', bcrypt_password BY 'password_2'— ユーザーレベルのデッドラインは両方の認証方式に適用されます。ALTER USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID FOR INTERVAL 30 DAY— デッドラインはbcrypt_password認証方式にのみ適用されます。plaintext_passwordは期限切れになりません。
GRANTS 句
特定の認証方式で認証されたセッションで利用可能なアクセス権を制限できます。詳細については、CREATE USER の GRANTS 句を参照してください。
ADD IDENTIFIED と組み合わせることで、有効期限と限定された権限セットを持つ追加の認証情報として、アプリケーション用トークンを簡単に作成できます。
例:
ALTER USER name1 ADD IDENTIFIED WITH plaintext_password BY 'app_token' VALID UNTIL '2026-12-31' GRANTS (SELECT ON db.table, INSERT ON db.table)