Users and roles settings

The users section of the users.xml configuration file contains user settings.

Note

ClickHouse also supports SQL-driven workflow for managing users. We recommend using it.

Structure of the users section:

<users>
    <!-- If user name was not specified, 'default' user is used. -->
    <user_name>
        <!-- Exactly one authentication method may be specified at the users.user_name level. For example: -->
        <password></password>
        <!-- Or (exclusive) -->
        <password_sha256_hex></password_sha256_hex>
 
        <!-- Or (exclusive) (N.B. multiple SSH keys are allowed for backwards compatibility) -->
        <ssh_keys>
            <ssh_key>
                <type>ssh-ed25519</type>
                <base64_key>AAAAC3NzaC1lZDI1NTE5AAAAIDNf0r6vRl24Ix3tv2IgPmNPO2ATa2krvt80DdcTatLj</base64_key>
            </ssh_key>
            <ssh_key>
                <type>ecdsa-sha2-nistp256</type>
                <base64_key>AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNxeV2uN5UY6CUbCzTA1rXfYimKQA5ivNIqxdax4bcMXz4D0nSk2l5E1TkR5mG8EBWtmExSPbcEPJ8V7lyWWbA8=</base64_key>
            </ssh_key>
            <ssh_key>
                <type>ssh-rsa</type>
                <base64_key>AAAAB3NzaC1yc2EAAAADAQABAAABgQCpgqL1SHhPVBOTFlOm0pu+cYBbADzC2jL41sPMawYCJHDyHuq7t+htaVVh2fRgpAPmSEnLEC2d4BEIKMtPK3bfR8plJqVXlLt6Q8t4b1oUlnjb3VPA9P6iGcW7CV1FBkZQEVx8ckOfJ3F+kI5VsrRlEDgiecm/C1VPl0/9M2llW/mPUMaD65cM9nlZgM/hUeBrfxOEqM11gDYxEZm1aRSbZoY4dfdm3vzvpSQ6lrCrkjn3X2aSmaCLcOWJhfBWMovNDB8uiPuw54g3ioZ++qEQMlfxVsqXDGYhXCrsArOVuW/5RbReO79BvXqdssiYShfwo+GhQ0+aLWMIW/jgBkkqx/n7uKLzCMX7b2F+aebRYFh+/QXEj7SnihdVfr9ud6NN3MWzZ1ltfIczlEcFLrLJ1Yq57wW6wXtviWh59WvTWFiPejGjeSjjJyqqB49tKdFVFuBnIU5u/bch2DXVgiAEdQwUrIp1ACoYPq22HFFAYUJrL32y7RxX3PGzuAv3LOc=</base64_key>
            </ssh_key>
        </ssh_keys>

        <!-- Or (exclusive) for multiple authentication methods: -->
        <auth_methods>
            <method1>
                <password></password>
            </method1>
            <method2>
                <password_sha256_hex></password_sha256_hex>
            </method2>
            <!-- ... -->
            <methodN>
                <!-- ... -->
            </methodN>
        </auth_methods>

        <access_management>0|1</access_management>

        <networks incl="networks" replace="replace">
        </networks>

        <profile>profile_name</profile>

        <quota>default</quota>
        <default_database>default</default_database>
        <databases>
            <database_name>
                <table_name>
                    <filter>expression</filter>
                </table_name>
            </database_name>
        </databases>

        <grants>
            <query>GRANT SELECT ON system.*</query>
        </grants>
    </user_name>
    <!-- Other users settings -->
</users>

user_name/password

Password can be specified in plaintext or in SHA256 (hex format).

To assign a password in plaintext (not recommended), place it in a password element.

For example, <password>qwerty</password>. The password can be left blank.

To assign a password using its SHA256 hash, place it in a password_sha256_hex element.

For example, <password_sha256_hex>65e84be33532fb784c48129675f9eff3a682b27168c0ea744b2cf58ee02337c5</password_sha256_hex>.

Example of how to generate a password from shell:
```
PASSWORD=$(base64 < /dev/urandom | head -c8); echo "$PASSWORD"; echo -n "$PASSWORD" | sha256sum | tr -d '-'
```
The first line of the result is the password. The second line is the corresponding SHA256 hash.

For compatibility with MySQL clients, password can be specified in double SHA1 hash. Place it in password_double_sha1_hex element.

For example, <password_double_sha1_hex>08b4a0f1de6ad37da17359e592c8d74788a83eb0</password_double_sha1_hex>.

Example of how to generate a password from shell:
```
PASSWORD=$(base64 < /dev/urandom | head -c8); echo "$PASSWORD"; echo -n "$PASSWORD" | sha1sum | tr -d '-' | xxd -r -p | sha1sum | tr -d '-'
```
The first line of the result is the password. The second line is the corresponding double SHA1 hash.

TOTP Authentication Configuration

Time-Based One-Time Password (TOTP) can be used to authenticate ClickHouse users by generating temporary access codes that are valid for a limited time. This TOTP authentication method aligns with RFC 6238 standards, making it compatible with popular TOTP applications like Google Authenticator, 1Password and similar tools. It can be set up trough the users.xml configuration file in addition to password-based authentication. It's not yet supported in SQL-driven Access Control.

To authenticate using TOTP, users must provide a primary password along with a one-time password generated by their TOTP application via the --one-time-password command line option or concatenated to main password together with a '+' character. For example if the primary password is some_password and the generated TOTP code is 345123, user may specify --password some_password+345123 or --password some_password --one-time-password 345123 when connecting to ClickHouse. If no password specified clickhouse-client will prompt for it interactively.

To enable TOTP authentication for a user, configure the time_based_one_time_password section in users.xml. This section defines the TOTP settings, such as secret, validity period, number of digits, and hash algorithm.

Example

<clickhouse>
    <!-- ... -->
    <users>
        <my_user>
            <!-- Primary password-based authentication: -->
            <password>some_password</password>
            <password_sha256_hex>1464acd6765f91fccd3f5bf4f14ebb7ca69f53af91b0a5790c2bba9d8819417b</password_sha256_hex>
            <!-- ... or any other supported authentication method ... -->

            <!-- TOTP authentication configuration -->
            <time_based_one_time_password>
                <secret>JBSWY3DPEHPK3PXP</secret>      <!-- Base32-encoded TOTP secret -->
                <period>30</period>                    <!-- Optional: OTP validity period in seconds -->
                <digits>6</digits>                     <!-- Optional: Number of digits in the OTP -->
                <algorithm>SHA1</algorithm>            <!-- Optional: Hash algorithm: SHA1, SHA256, SHA512 -->
            </time_based_one_time_password>
        </my_user>
    </users>
</clickhouse>

Parameters:

- secret - (Required) The base32-encoded secret key used to generate TOTP codes.
- period - Optional. Sets the validity period of each OTP in seconds. Must be a positive number not exceeding 120. Default is 30.
- digits - Optional. Specifies the number of digits in each OTP. Must be between 4 and 10. Default is 6.
- algorithm - Optional. Defines the hash algorithm for generating OTPs. Supported values are SHA1, SHA256, and SHA512. Default is SHA1.

Generating a TOTP Secret

To generate a TOTP-compatible secret for use with ClickHouse, run the following command in the terminal:

```bash
$ base32 -w32 < /dev/urandom | head -1

This command will produce a base32-encoded secret that can be added to the secret field in users.xml.

To enable TOTP for a specific user, add to any existing password-based field (like password or password_sha256_hex) another time_based_one_time_password section.

The qrencode tool can be used to generate a QR code for the TOTP secret.

$ qrencode -t ansiutf8 'otpauth://totp/ClickHouse?issuer=ClickHouse&secret=JBSWY3DPEHPK3PXP'

After configuring TOTP for a user, one-time password can be used as a part of the authentication process as described above.

username/ssh-key

This setting allows authenticating with SSH keys.

Given a SSH key (as generated by ssh-keygen) like

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDNf0r6vRl24Ix3tv2IgPmNPO2ATa2krvt80DdcTatLj john@example.com

The ssh_key element is expected to be

<ssh_key>
     <type>ssh-ed25519</type>
     <base64_key>AAAAC3NzaC1lZDI1NTE5AAAAIDNf0r6vRl24Ix3tv2IgPmNPO2ATa2krvt80DdcTatLj</base64_key>
 </ssh_key>

Substitute ssh-ed25519 with ssh-rsa or ecdsa-sha2-nistp256 for the other supported algorithms.

Multiple Authentication Methods

A single user can be configured with multiple authentication methods using the <auth_methods> element. This allows a user to authenticate with any one of the listed methods — for example, a user could have both a password and an LDAP credential, and logging in with either one would succeed.

Each child element of <auth_methods> is an arbitrarily-named wrapper that contains exactly one authentication type. The wrapper name (e.g. <method1>, <primary>, <a1>) does not matter; only the inner authentication element is used.

Example: multiple passwords

<users>
    <my_user>
        <auth_methods>
            <primary>
                <password>password_one</password>
            </primary>
            <secondary>
                <password_sha256_hex>65e84be33532fb784c48129675f9eff3a682b27168c0ea744b2cf58ee02337c5</password_sha256_hex>
            </secondary>
        </auth_methods>
    </my_user>
</users>

Example: mixed authentication types

<users>
    <my_user>
        <auth_methods>
            <a1>
                <password>plaintext_pass</password>
            </a1>
            <a2>
                <password_sha256_hex>e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855</password_sha256_hex>
            </a2>
            <a3>
                <ldap>
                    <server>my_ldap_server</server>
                </ldap>
            </a3>
        </auth_methods>
    </my_user>
</users>

The following authentication types are supported inside <auth_methods>:

password — plaintext password
password_sha256_hex — SHA256 password hash
password_scram_sha256_hex — SCRAM-SHA-256 password hash
password_double_sha1_hex — double SHA1 password hash
ldap — LDAP server authentication
kerberos — Kerberos authentication
ssl_certificates — SSL certificate authentication
ssh_keys — SSH key authentication
http_authentication — HTTP authentication

Rules and restrictions:

<auth_methods> cannot be used together with authentication methods specified at the user level. Use one style or the other, not both.
<auth_methods> must contain at least one authentication method.
Each wrapper element inside <auth_methods> must contain exactly one authentication type (with the exception of <ssh_keys>, which can contain multiple, for backwards compatibility).
TOTP (<time_based_one_time_password>) is specified at the user level (outside <auth_methods>) and applies to all password-based methods in the list. At least one password-based method is required when TOTP is enabled.

Example: auth_methods with TOTP

<users>
    <my_user>
        <auth_methods>
            <a1>
                <password>my_password</password>
            </a1>
            <a2>
                <ldap>
                    <server>ldap_server_1</server>
                </ldap>
            </a2>
        </auth_methods>
        <time_based_one_time_password>
            <secret>JBSWY3DPEHPK3PXP</secret>
        </time_based_one_time_password>
    </my_user>
</users>

In this example, TOTP verification is applied to the password-based method (<password>), while the LDAP method authenticates against the external server independently.

access_management

This setting enables or disables using of SQL-driven access control and account management for the user.

Possible values:

0 — Disabled.
1 — Enabled.

Default value: 0.

grants

This setting allows to grant any rights to selected user. Each element of the list should be GRANT query without any grantees specified.

Example:

<user1>
    <grants>
        <query>GRANT SHOW ON *.*</query>
        <query>GRANT CREATE ON *.* WITH GRANT OPTION</query>
        <query>GRANT SELECT ON system.*</query>
    </grants>
</user1>

This setting can't be specified at the same time with dictionaries, access_management, named_collection_control, show_named_collections_secrets and allow_databases settings.

user_name/networks

List of networks from which the user can connect to the ClickHouse server.

Each element of the list can have one of the following forms:

<ip> — IP address or network mask.

Examples: 213.180.204.3, 10.0.0.1/8, 10.0.0.1/255.255.255.0, 2a02:6b8::3, 2a02:6b8::3/64, 2a02:6b8::3/ffff:ffff:ffff:ffff::.
<host> — Hostname.

Example: example01.host.ru.

To check access, a DNS query is performed, and all returned IP addresses are compared to the peer address.
<host_regexp> — Regular expression for hostnames.

Example, ^example\d\d-\d\d-\d\.host\.ru$

To check access, a DNS PTR query is performed for the peer address and then the specified regexp is applied. Then, another DNS query is performed for the results of the PTR query and all the received addresses are compared to the peer address. We strongly recommend that regexp ends with $.

All results of DNS requests are cached until the server restarts.

Examples

To open access for user from any network, specify:

<ip>::/0</ip>

Note

It's insecure to open access from any network unless you have a firewall properly configured or the server is not directly connected to Internet.

To open access only from localhost, specify:

<ip>::1</ip>
<ip>127.0.0.1</ip>

user_name/profile

You can assign a settings profile for the user. Settings profiles are configured in a separate section of the users.xml file. For more information, see Profiles of Settings.

user_name/quota

Quotas allow you to track or limit resource usage over a period of time. Quotas are configured in the quotas section of the users.xml configuration file.

You can assign a quotas set for the user. For a detailed description of quotas configuration, see Quotas.

user_name/databases

In this section, you can limit rows that are returned by ClickHouse for SELECT queries made by the current user, thus implementing basic row-level security.

Example

The following configuration forces that user user1 can only see the rows of table1 as the result of SELECT queries, where the value of the id field is 1000.

<user1>
    <databases>
        <database_name>
            <table1>
                <filter>id = 1000</filter>
            </table1>
        </database_name>
    </databases>
</user1>

The filter can be any expression resulting in a UInt8-type value. It usually contains comparisons and logical operators. Rows from database_name.table1 where filter results to 0 are not returned for this user. The filtering is incompatible with PREWHERE operations and disables WHERE→PREWHERE optimization.

Roles

You can create any predefined roles using the roles section of the user.xml configuration file.

Structure of the roles section:

<roles>
    <test_role>
        <grants>
            <query>GRANT SHOW ON *.*</query>
            <query>REVOKE SHOW ON system.*</query>
            <query>GRANT CREATE ON *.* WITH GRANT OPTION</query>
        </grants>
    </test_role>
</roles>

These roles can also be granted to users from the users section:

<users>
    <user_name>
        ...
        <grants>
            <query>GRANT test_role</query>
        </grants>
    </user_name>
<users>

user_name/password​

TOTP Authentication Configuration​

username/ssh-key​

Multiple Authentication Methods​

access_management​

grants​

user_name/networks​

user_name/profile​

user_name/quota​

user_name/databases​

Roles​