> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-8a08bda2.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Документация по команде USER

# CREATE USER

Создаёт [учётные записи пользователей](/ru/concepts/features/security/access-rights#user-account-management).

Синтаксис:

```sql theme={null}
CREATE USER [IF NOT EXISTS | OR REPLACE] name1 [, name2 [,...]] [ON CLUSTER cluster_name]
    [NOT IDENTIFIED | 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] 
    [, {[{plaintext_password | sha256_password | sha256_hash | ...}] BY {'password' | 'hash'}} | {ldap SERVER 'server_name'} | {...} | ... [,...]]]
    [HOST {LOCAL | NAME 'name' | REGEXP 'name_regexp' | IP 'address' | LIKE 'pattern'} [,...] | ANY | NONE]
    [VALID UNTIL datetime]
    [IN access_storage_type]
    [ROLE role [,...]]
    [DEFAULT ROLE role [,...]]
    [DEFAULT DATABASE database | NONE]
    [GRANTEES {user | role | ANY | NONE} [,...] [EXCEPT {user | role} [,...]]]
    [SETTINGS variable [= value] [MIN [=] min_value] [MAX [=] max_value] [READONLY | WRITABLE] | PROFILE 'profile_name'] [,...]
```

Предложение `ON CLUSTER` позволяет создавать пользователей в кластере, см. [Distributed DDL](/ru/reference/statements/distributed-ddl).

<div id="identification">
  ## Идентификация
</div>

Существует несколько способов идентификации пользователя:

* `IDENTIFIED WITH no_password`
* `IDENTIFIED WITH plaintext_password BY 'qwerty'`
* `IDENTIFIED WITH sha256_password BY 'qwerty'` or `IDENTIFIED BY 'password'`
* `IDENTIFIED WITH sha256_hash BY 'hash'` or `IDENTIFIED WITH sha256_hash BY 'hash' SALT 'salt'`
* `IDENTIFIED WITH double_sha1_password BY 'qwerty'`
* `IDENTIFIED WITH double_sha1_hash BY 'hash'`
* `IDENTIFIED WITH bcrypt_password BY 'qwerty'`
* `IDENTIFIED WITH bcrypt_hash BY 'hash'`
* `IDENTIFIED WITH ldap SERVER 'server_name'`
* `IDENTIFIED WITH kerberos` or `IDENTIFIED WITH kerberos REALM 'realm'`
* `IDENTIFIED WITH ssl_certificate CN 'mysite.com:user'`
* `IDENTIFIED WITH ssh_key BY KEY 'public_key' TYPE 'ssh-rsa', KEY 'another_public_key' TYPE 'ssh-ed25519'`
* `IDENTIFIED WITH http SERVER 'http_server'` or `IDENTIFIED WITH http SERVER 'http_server' SCHEME 'basic'`
* `IDENTIFIED BY 'qwerty'`

Требования к сложности паролей можно изменить в [config.xml](/ru/concepts/features/configuration/server-config/configuration-files). Ниже приведен пример конфигурации, в которой требуется, чтобы пароль был длиной не менее 12 символов и содержал 1 цифру. Для каждого правила сложности пароля требуется регулярное выражение для проверки паролей и описание правила.

```xml theme={null}
<clickhouse>
    <password_complexity>
        <rule>
            <pattern>.{12}</pattern>
            <message>be at least 12 characters long</message>
        </rule>
        <rule>
            <pattern>\p{N}</pattern>
            <message>contain at least 1 numeric character</message>
        </rule>
    </password_complexity>
</clickhouse>
```

<Note>
  В ClickHouse Cloud по умолчанию пароли должны соответствовать следующим требованиям к сложности:

  * Длина — не менее 12 символов
  * Содержать как минимум 1 цифру
  * Содержать как минимум 1 заглавную букву
  * Содержать как минимум 1 строчную букву
  * Содержать как минимум 1 специальный символ
</Note>

<div id="examples">
  ## Примеры
</div>

1. Следующее имя пользователя — `name1`, и для него не требуется пароль, что, очевидно, не дает почти никакой защиты:

   ```sql theme={null}
   CREATE USER name1 NOT IDENTIFIED
   ```

2. Чтобы указать пароль в открытом виде:

   ```sql theme={null}
   CREATE USER name2 IDENTIFIED WITH plaintext_password BY 'my_password'
   ```

<Tip>
  Пароль хранится в текстовом SQL-файле в `/var/lib/clickhouse/access`, поэтому использовать `plaintext_password` — не лучшая идея. Вместо этого лучше использовать `sha256_password`, как показано ниже...
</Tip>

3. Самый распространенный вариант — использовать пароль, хешированный с помощью SHA-256. ClickHouse сам вычислит хеш пароля, если указать `IDENTIFIED WITH sha256_password`. Например:

   ```sql theme={null}
   CREATE USER name3 IDENTIFIED WITH sha256_password BY 'my_password'
   ```

   Пользователь `name3` теперь может входить с паролем `my_password`, но сам пароль хранится в виде хеша, показанного выше. В `/var/lib/clickhouse/access` будет создан следующий SQL-файл, который выполняется при запуске сервера:

   ```bash theme={null}
   /var/lib/clickhouse/access $ cat 3843f510-6ebd-a52d-72ac-e021686d8a93.sql
   ATTACH USER name3 IDENTIFIED WITH sha256_hash BY '0C268556C1680BEF0640AAC1E7187566704208398DA31F03D18C74F5C5BE5053' SALT '4FB16307F5E10048196966DD7E6876AE53DE6A1D1F625488482C75F14A5097C7';
   ```

<Tip>
  Если у вас уже есть хеш-значение и соответствующее значение соли для имени пользователя, можно использовать `IDENTIFIED WITH sha256_hash BY 'hash'` или `IDENTIFIED WITH sha256_hash BY 'hash' SALT 'salt'`. При идентификации с помощью `sha256_hash` и `SALT` хеш должен вычисляться из конкатенации 'password' и 'salt'.
</Tip>

4. `double_sha1_password` обычно не требуется, но бывает полезен при работе с клиентами, которым он нужен (например, через интерфейс MySQL):

   ```sql theme={null}
   CREATE USER name4 IDENTIFIED WITH double_sha1_password BY 'my_password'
   ```

   ClickHouse генерирует и выполняет следующий запрос:

   ```response theme={null}
   CREATE USER name4 IDENTIFIED WITH double_sha1_hash BY 'CCD3A959D6A004B9C3807B728BC2E55B67E10518'
   ```

5. `bcrypt_password` — самый безопасный вариант хранения паролей. Он использует алгоритм [bcrypt](https://en.wikipedia.org/wiki/Bcrypt), устойчивый к атакам методом перебора, даже если хеш пароля был скомпрометирован.

   ```sql theme={null}
   CREATE USER name5 IDENTIFIED WITH bcrypt_password BY 'my_password'
   ```

   При использовании этого метода длина пароля ограничена 72 символами.
   Параметр bcrypt work factor, который определяет объем вычислений и время, необходимые для вычисления хеша и проверки пароля, можно изменить в конфигурации сервера:

   ```xml theme={null}
   <bcrypt_workfactor>12</bcrypt_workfactor>
   ```

   Значение work factor должно быть в диапазоне от 4 до 31, по умолчанию — 12.

<Warning>
  Для приложений с высокочастотной аутентификацией
  рассмотрите альтернативные методы аутентификации из-за
  вычислительных затрат bcrypt при более высоких значениях work factor.
</Warning>

6. Тип пароля также можно не указывать:

   ```sql theme={null}
   CREATE USER name6 IDENTIFIED BY 'my_password'
   ```

   В этом случае ClickHouse будет использовать тип пароля по умолчанию, указанный в конфигурации сервера:

   ```xml theme={null}
   <default_password_type>sha256_password</default_password_type>
   ```

   Доступные типы паролей: `plaintext_password`, `sha256_password`, `double_sha1_password`.

7. Можно указать несколько методов аутентификации:

   ```sql theme={null}
   CREATE USER user1 IDENTIFIED WITH plaintext_password by '1', bcrypt_password by '2', plaintext_password by '3''
   ```

Примечания:

1. Более старые версии ClickHouse могут не поддерживать синтаксис для нескольких методов аутентификации. Поэтому, если на сервере ClickHouse есть такие пользователи, а затем сервер понижают до версии, где эта возможность не поддерживается, такие пользователи станут непригодны к использованию, а некоторые операции, связанные с пользователями, перестанут работать. Чтобы корректно понизить версию, перед этим необходимо настроить всех пользователей так, чтобы у каждого был только один метод аутентификации. Если же версия сервера была понижена без соблюдения этой процедуры, некорректных пользователей следует удалить.
2. `no_password` не может использоваться вместе с другими методами аутентификации из соображений безопасности. Поэтому указать
   `no_password` можно только в том случае, если это единственный метод аутентификации в запросе.

<div id="user-host">
  ## Хост пользователя
</div>

Хост пользователя — это хост, с которого может быть установлено соединение с сервером ClickHouse. Хост можно указать в секции запроса `HOST` следующими способами:

* `HOST IP 'ip_address_or_subnetwork'` — Пользователь может подключаться к серверу ClickHouse только с указанного IP-адреса или из [подсети](https://en.wikipedia.org/wiki/Subnetwork). Примеры: `HOST IP '192.168.0.0/16'`, `HOST IP '2001:DB8::/32'`. Для использования в рабочей среде указывайте только элементы `HOST IP` (IP-адреса и их маски), поскольку использование `host` и `host_regexp` может вызывать дополнительную задержку.
* `HOST ANY` — Пользователь может подключаться откуда угодно. Это вариант по умолчанию.
* `HOST LOCAL` — Пользователь может подключаться только локально.
* `HOST NAME 'fqdn'` — Хост пользователя можно указать в виде FQDN. Например, `HOST NAME 'mysite.com'`.
* `HOST REGEXP 'regexp'` — При указании хостов пользователя можно использовать [pcre](http://www.pcre.org/) регулярные выражения. Например, `HOST REGEXP '.*\.mysite\.com'`.
* `HOST LIKE 'template'` — Позволяет использовать оператор [LIKE](/ru/reference/functions/regular-functions/string-search-functions#like) для фильтрации хостов пользователя. Например, `HOST LIKE '%'` эквивалентно `HOST ANY`, а `HOST LIKE '%.mysite.com'` фильтрует все хосты в домене `mysite.com`.

Ещё один способ указать хост — использовать синтаксис `@` после имени пользователя. Примеры:

* `CREATE USER mira@'127.0.0.1'` — Эквивалентно синтаксису `HOST IP`.
* `CREATE USER mira@'localhost'` — Эквивалентно синтаксису `HOST LOCAL`.
* `CREATE USER mira@'192.168.%.%'` — Эквивалентно синтаксису `HOST LIKE`.

<Tip>
  ClickHouse рассматривает `user_name@'address'` как имя пользователя целиком. Таким образом, технически можно создать нескольких пользователей с одним и тем же `user_name` и разными конструкциями после `@`. Однако мы не рекомендуем этого делать.
</Tip>

<div id="valid-until-clause">
  ## предложение VALID UNTIL
</div>

Позволяет указать дату истечения срока действия и, при необходимости, время для метода аутентификации. В качестве параметра принимает строку. Для даты и времени рекомендуется использовать формат `YYYY-MM-DD [hh:mm:ss] [timezone]`, где `[timezone]` должен быть числовым смещением, например `+09:00`, или одним из значений `UTC`, `GMT`, `Z`, `MSK`, `MSD`; именованные зоны IANA, такие как `Asia/Tokyo`, не распознаются (см. примечание ниже). По умолчанию значение этого параметра — `'infinity'`.
Клаузу `VALID UNTIL` можно указывать только вместе с методом аутентификации, кроме случая, когда в запросе не указан ни один метод аутентификации. В таком случае клауза `VALID UNTIL` будет применена ко всем существующим методам аутентификации.

Примеры:

* `CREATE USER name1 VALID UNTIL '2025-01-01'`
* `CREATE USER name1 VALID UNTIL '2025-01-01 12:00:00 UTC'`
* `CREATE USER name1 VALID UNTIL '2025-01-01 12:00:00 +09:00'`
* `CREATE USER name1 VALID UNTIL 'infinity'`
* `CREATE USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID UNTIL '2025-01-01'`

<Note>
  Строка даты и времени разбирается функцией `parseDateTimeBestEffort`, которая распознаёт только токены часового пояса `UTC`, `GMT`, `Z`, `MSK`, `MSD` и числовые смещения, такие как `+09:00` или `-05:00`. Именованные часовые пояса IANA, такие как `Asia/Tokyo` или `Europe/London`, не поддерживаются, а фиксированное смещение не эквивалентно зоне IANA для регионов, где действует переход на летнее время, поэтому для конкретной даты нужно вычислить правильное смещение.
</Note>

<div id="grantees-clause">
  ## Предложение GRANTEES
</div>

Указывает пользователей или роли, которым этот пользователь может предоставлять [привилегии](/ru/reference/statements/grant#privileges), при условии, что самому этому пользователю также предоставлены все необходимые права доступа с [GRANT OPTION](/ru/reference/statements/grant#granting-privilege-syntax). Варианты предложения `GRANTEES`:

* `user` — Указывает пользователя, которому этот пользователь может предоставлять привилегии.
* `role` — Указывает роль, которой этот пользователь может предоставлять привилегии.
* `ANY` — Этот пользователь может предоставлять привилегии кому угодно. Это значение по умолчанию.
* `NONE` — Этот пользователь не может предоставлять привилегии никому.

Исключить любого пользователя или роль можно с помощью выражения `EXCEPT`. Например, `CREATE USER user1 GRANTEES ANY EXCEPT user2`. Это означает, что если пользователю `user1` предоставлены какие-либо привилегии с `GRANT OPTION`, он сможет предоставлять эти привилегии кому угодно, кроме `user2`.

<div id="examples">
  ## Примеры
</div>

Создайте пользовательскую учетную запись `mira`, защищенную паролем `qwerty`:

```sql theme={null}
CREATE USER mira HOST IP '127.0.0.1' IDENTIFIED WITH sha256_password BY 'qwerty';
```

`mira` должна запускать клиентское приложение на хосте, где запущен сервер ClickHouse.

Создайте учётную запись пользователя `john` и назначьте роли:

```sql theme={null}
CREATE USER john ROLE role1, role2;
```

Создайте учетную запись пользователя `john`, назначьте роли и сделайте некоторые из них ролями по умолчанию:

```sql theme={null}
CREATE USER john ROLE role1, role2 DEFAULT ROLE role1;
```

или

```sql theme={null}
CREATE USER john ROLE role1, role2 DEFAULT ROLE ALL EXCEPT role2;
```

Создайте учётную запись пользователя `john` и разрешите ему передавать свои привилегии пользователю с учётной записью `jack`:

```sql theme={null}
CREATE USER john GRANTEES jack;
```

Используйте параметр запроса, чтобы создать учётную запись пользователя `john`:

```sql theme={null}
SET param_user=john;
CREATE USER {user:Identifier};
```