ALTER USER

Изменяет учетные записи пользователей в 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: он изменяет одну настройку, сохраняя остальные. Предпочитайте его (или MODIFY SETTING) простой форме SETTINGS, которая заменяет весь список настроек, а также удаляет все наследуемые (родительские) профили.

Предложение 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, role2

Позволяет пользователю с учетной записью john предоставлять свои привилегии пользователю с учетной записью 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 есть такие пользователи и затем его понизить до версии, которая этого не поддерживает, эти пользователи станут непригодны к использованию, а некоторые связанные с ними операции перестанут работать. Чтобы корректно понизить версию, перед этим необходимо настроить всех пользователей так, чтобы у каждого был только один метод аутентификации. Либо, если сервер был понижен без соблюдения надлежащей процедуры, проблемных пользователей следует удалить.
no_password не может использоваться вместе с другими методами аутентификации по соображениям безопасности. Поэтому добавить метод аутентификации no_password с помощью ADD невозможно. Приведённый ниже запрос вызовет ошибку:

ALTER USER user1 ADD IDENTIFIED WITH no_password

Если вы хотите сбросить методы аутентификации пользователя и использовать no_password, это необходимо указать в приведённой ниже форме замены. Сбрасывает методы аутентификации и добавляет те, которые указаны в запросе (эффект начального IDENTIFIED без ключевого слова ADD):

ALTER USER user1 IDENTIFIED WITH plaintext_password by '1', bcrypt_password by '2', plaintext_password by '3'

Сбросьте методы аутентификации, оставив только последний добавленный:

ALTER USER user1 RESET AUTHENTICATION METHODS TO NEW

Предложение VALID 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 (1970-01-01 00:00:01 UTC), поэтому SHOW CREATE USER выводит этот момент вместо указанного вами срока. Сроки, начиная с этого момента, сохраняются без изменений. Срок хранится как абсолютный момент, однако SHOW CREATE USER и system.users отображают его в часовом поясе сервера или сеанса. Поэтому один и тот же сохранённый момент на серверах с разными настройками отображается как разное местное время: например, указанный выше приведённый истёкший момент отображается как 1970-01-01 00:00:01 на сервере в UTC и как 1970-01-01 14:00:01 на сервере в Pacific/Kiritimati. При проверке всегда используется сохранённый момент, а не его отображение. Расположение предложения определяет, к каким методам аутентификации оно применяется:

Перед предложением 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 DAY
ALTER USER name1 VALID FOR INTERVAL 3 MONTH
ALTER 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

Позволяет ограничить права доступа, доступные для сеанса, аутентифицированного с использованием определённого метода аутентификации. Подробнее см. предложение GRANTS оператора CREATE USER. В сочетании с 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)

SQL Reference

Data Types

Engines

Functions

Formats

Interfaces

Settings

System Tables

Data Lakes

Предложение GRANTEES

Примеры

Предложение VALID UNTIL

Предложение VALID FOR

Предложение GRANTS

​Предложение GRANTEES

​Примеры

​Предложение VALID UNTIL

​Предложение VALID FOR

​Предложение GRANTS

Предложение GRANTEES

Примеры

Предложение VALID UNTIL

Предложение VALID FOR

Предложение GRANTS