CREATE USER

Crea cuentas de usuario. Sintaxis:

CREATE USER [IF NOT EXISTS | OR REPLACE] name1 [, name2 [,...]] [ON CLUSTER cluster_name]
    [{VALID UNTIL datetime | VALID FOR interval}]
    [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 | VALID FOR interval}] [GRANTS (privilege ON object [,...])]
    [, {[{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]
    [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'] [,...]

La cláusula ON CLUSTER permite crear usuarios en un clúster; consulte Distributed DDL.

Identificación

Hay varias formas de identificar a un usuario:

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'

Los requisitos de complejidad de las contraseñas pueden editarse en config.xml. A continuación, se muestra una configuración de ejemplo que exige que las contraseñas tengan al menos 12 caracteres y contengan 1 número. Cada regla de complejidad de contraseñas requiere una expresión regular con la que validar las contraseñas y una descripción de la regla.

<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>

En ClickHouse Cloud, de forma predeterminada, las contraseñas deben cumplir los siguientes requisitos de complejidad:

Tener al menos 12 caracteres
Contener al menos 1 dígito
Contener al menos 1 letra mayúscula
Contener al menos 1 letra minúscula
Contener al menos 1 carácter especial

Ejemplos

El siguiente nombre de usuario es name1 y no requiere contraseña, lo que obviamente no ofrece mucha seguridad:
CREATE USER name1 NOT IDENTIFIED

Para especificar una contraseña en texto plano:

CREATE USER name2 IDENTIFIED WITH plaintext_password BY 'my_password'

La contraseña se almacena en un archivo de texto SQL en /var/lib/clickhouse/access, por lo que no es buena idea usar plaintext_password. En su lugar, prueba sha256_password, como se muestra a continuación…

La opción más habitual es usar una contraseña con hash SHA-256. ClickHouse calculará el hash de la contraseña por ti cuando especifiques IDENTIFIED WITH sha256_password. Por ejemplo:
CREATE USER name3 IDENTIFIED WITH sha256_password BY 'my_password'
El usuario name3 ahora puede iniciar sesión con my_password, pero la contraseña se almacena como el valor hash mostrado arriba. El siguiente archivo SQL se creó en /var/lib/clickhouse/access y se ejecuta al iniciar el servidor:
/var/lib/clickhouse/access $ cat 3843f510-6ebd-a52d-72ac-e021686d8a93.sql ATTACH USER name3 IDENTIFIED WITH sha256_hash BY '0C268556C1680BEF0640AAC1E7187566704208398DA31F03D18C74F5C5BE5053' SALT '4FB16307F5E10048196966DD7E6876AE53DE6A1D1F625488482C75F14A5097C7';

Si ya has creado un valor hash y el valor salt correspondiente para un nombre de usuario, puedes usar IDENTIFIED WITH sha256_hash BY 'hash' o IDENTIFIED WITH sha256_hash BY 'hash' SALT 'salt'. Para la identificación con sha256_hash usando SALT, el hash debe calcularse a partir de la concatenación de ‘password’ y ‘salt’.

double_sha1_password no suele ser necesario, pero resulta útil al trabajar con clientes que lo requieren (como la interfaz MySQL):
CREATE USER name4 IDENTIFIED WITH double_sha1_password BY 'my_password'
ClickHouse genera y ejecuta la siguiente consulta:
CREATE USER name4 IDENTIFIED WITH double_sha1_hash BY 'CCD3A959D6A004B9C3807B728BC2E55B67E10518'
bcrypt_password es la opción más segura para almacenar contraseñas. Utiliza el algoritmo bcrypt, que es resistente a ataques de fuerza bruta incluso si el hash de la contraseña se ve comprometido.
CREATE USER name5 IDENTIFIED WITH bcrypt_password BY 'my_password'
La longitud de la contraseña está limitada a 72 caracteres con este método. El parámetro de factor de trabajo de bcrypt, que define la cantidad de cómputo y tiempo necesarios para calcular el hash y verificar la contraseña, se puede modificar en la configuración del servidor:
<bcrypt_workfactor>12</bcrypt_workfactor>
El factor de trabajo debe estar entre 4 y 31, con un valor predeterminado de 12.

Para aplicaciones con autenticación de alta frecuencia, considera métodos de autenticación alternativos debido a la sobrecarga computacional de bcrypt con factores de trabajo altos.

El tipo de contraseña también se puede omitir:
CREATE USER name6 IDENTIFIED BY 'my_password'
En este caso, ClickHouse usará el tipo de contraseña predeterminado especificado en la configuración del servidor:
<default_password_type>sha256_password</default_password_type>
Los tipos de contraseña disponibles son: plaintext_password, sha256_password, double_sha1_password.

Se pueden especificar varios métodos de autenticación:

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

Notas:

Es posible que las versiones anteriores de ClickHouse no admitan la sintaxis de varios métodos de autenticación. Por lo tanto, si el servidor ClickHouse contiene usuarios de este tipo y se degrada a una versión que no lo admite, esos usuarios quedarán inutilizables y algunas operaciones relacionadas con los usuarios dejarán de funcionar. Para realizar la degradación correctamente, es necesario configurar todos los usuarios para que tengan un único método de autenticación antes de degradar la versión. Como alternativa, si el servidor se degradó sin seguir el procedimiento adecuado, se deben eliminar los usuarios afectados.
no_password no puede coexistir con otros métodos de autenticación por motivos de seguridad. Por lo tanto, solo puede especificar no_password si es el único método de autenticación en la consulta.

Host de usuario

El host de usuario es el host desde el que se puede establecer una conexión con servidor ClickHouse. El host puede especificarse en la sección HOST de la consulta de las siguientes maneras:

HOST IP 'ip_address_or_subnetwork' — El usuario solo puede conectarse a servidor ClickHouse desde la dirección IP especificada o una subred. Ejemplos: HOST IP '192.168.0.0/16', HOST IP '2001:DB8::/32'. Para usarlo en producción, especifique solo elementos HOST IP (direcciones IP y sus máscaras), ya que el uso de host y host_regexp puede provocar latencia adicional.
HOST ANY — El usuario puede conectarse desde cualquier ubicación. Esta es la opción predeterminada.
HOST LOCAL — El usuario solo puede conectarse localmente.
HOST NAME 'fqdn' — El host de usuario puede especificarse como un FQDN. Por ejemplo, HOST NAME 'mysite.com'.
HOST REGEXP 'regexp' — Puede usar expresiones regulares pcre al especificar hosts de usuario. Por ejemplo, HOST REGEXP '.*\.mysite\.com'.
HOST LIKE 'template' — Permite usar el operador LIKE para filtrar los hosts de usuario. Por ejemplo, HOST LIKE '%' equivale a HOST ANY; HOST LIKE '%.mysite.com' filtra todos los hosts del dominio mysite.com.

Otra forma de especificar el host es usar la sintaxis @ después del nombre de usuario. Ejemplos:

CREATE USER mira@'127.0.0.1' — Equivale a la sintaxis HOST IP.
CREATE USER mira@'localhost' — Equivale a la sintaxis HOST LOCAL.
CREATE USER mira@'192.168.%.%' — Equivale a la sintaxis HOST LIKE.

ClickHouse trata user_name@'address' como un nombre de usuario completo. Por lo tanto, técnicamente puede crear varios usuarios con el mismo user_name y distintas formas después de @. Sin embargo, no recomendamos hacerlo.

Cláusula VALID UNTIL

Permite especificar la fecha de expiración y, opcionalmente, la hora de un método de autenticación. Acepta una cadena como parámetro. Se recomienda usar el formato de fecha y hora YYYY-MM-DD [hh:mm:ss] [timezone], donde [timezone] debe ser un desplazamiento numérico como +09:00 o uno de UTC, GMT, Z, MSK, MSD; las zonas IANA con nombre, como Asia/Tokyo, no se reconocen (consulte la nota a continuación). De forma predeterminada, este parámetro es igual a 'infinity'. El intervalo de fechas límite aceptado va de 1900-01-01 00:00:00 UTC a 9999-12-31 09:59:59 UTC —el último instante que permanece dentro del año 9999 en todas las zonas horarias—, por lo que el instante almacenado nunca se trunca al representarse. Una fecha límite en el pasado significa que las credenciales ya han expirado. Las fechas límite anteriores a 1970-01-01 00:00:01 UTC solo se aceptan como marcador de «ya expirado»: se canonicalizan al instante expirado mínimo, un segundo después de la época Unix (1970-01-01 00:00:01 UTC), por lo que SHOW CREATE USER muestra ese instante en lugar de la fecha límite especificada. Las fechas límite a partir de ese instante se almacenan exactamente. Una fecha límite se almacena como un instante absoluto, pero SHOW CREATE USER y system.users la representan en la zona horaria del servidor o de la sesión, por lo que el mismo instante almacenado aparece como texto de hora local distinto en servidores configurados de forma diferente: por ejemplo, el instante expirado canonicalizado anterior se representa como 1970-01-01 00:00:01 en un servidor con UTC y como 1970-01-01 14:00:01 en un servidor con Pacific/Kiritimati. La aplicación siempre usa el instante almacenado, no su representación. La posición de la cláusula determina a qué métodos de autenticación se aplica:

Antes de la cláusula IDENTIFIED (o cuando la consulta no especifica ningún método de autenticación): la fecha límite se aplica a nivel de usuario y afecta a todos los métodos de autenticación del usuario.
Después de un método de autenticación: la fecha límite se aplica únicamente a ese método. Por tanto, una cláusula escrita después de toda la lista IDENTIFIED se asocia únicamente al último método y deja los métodos anteriores sin fecha de expiración.

Ejemplos:

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 VALID UNTIL '2025-01-01' IDENTIFIED WITH plaintext_password BY 'password_1', bcrypt_password BY 'password_2' — la fecha límite a nivel de usuario se aplica a ambos métodos.
CREATE USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID UNTIL '2025-01-01' — la fecha límite se aplica únicamente al método bcrypt_password; plaintext_password nunca expira.

La cadena de fecha y hora se analiza mediante parseDateTimeBestEffort, que solo reconoce los tokens de zona horaria UTC, GMT, Z, MSK, MSD y desplazamientos numéricos como +09:00 o -05:00. Las zonas horarias IANA con nombre, como Asia/Tokyo o Europe/London, no son compatibles, y un desplazamiento fijo no equivale a una zona IANA en regiones que aplican el horario de verano, por lo que debe calcular el desplazamiento correcto para la fecha específica que está codificando.

Cláusula VALID FOR

La cláusula VALID FOR es una abreviatura práctica de VALID UNTIL. En lugar de una fecha y hora absolutas, acepta un intervalo, y la fecha límite de expiración se calcula sumando ese intervalo a la hora actual en el momento en que se ejecuta la consulta. El resultado se almacena en formato VALID UNTIL, por lo que SHOW CREATE USER siempre muestra la fecha límite absoluta resultante. Puede usarse en cualquier lugar donde se pueda usar VALID UNTIL y sigue las mismas reglas de ubicación: antes de IDENTIFIED (o sin método de autenticación), es una fecha límite a nivel de usuario que se aplica a todos los métodos; después de un método de autenticación, se aplica solo a ese método. La fecha límite se almacena y se aplica con precisión de segundos, por lo que se rechazan los intervalos inferiores a un segundo (NANOSECOND, MICROSECOND, MILLISECOND); la unidad más pequeña aceptada es SECOND. Se acepta un intervalo negativo para marcar las credenciales como ya expiradas; si la fecha límite resultante es anterior a 1970-01-01 00:00:01 UTC, se canonicaliza a ese instante expirado mínimo, que es lo que posteriormente muestra SHOW CREATE USER, representado en la zona horaria del servidor o de la sesión, como se describe para VALID UNTIL. Ejemplos:

CREATE USER name1 VALID FOR INTERVAL 1 DAY
CREATE USER name1 VALID FOR INTERVAL 3 MONTH
CREATE USER name1 VALID FOR INTERVAL 1 DAY + INTERVAL 12 HOUR
CREATE USER name1 VALID FOR INTERVAL 30 DAY IDENTIFIED WITH plaintext_password BY 'password_1', bcrypt_password BY 'password_2' — la fecha límite a nivel de usuario se aplica a ambos métodos.
CREATE USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID FOR INTERVAL 30 DAY — la fecha límite se aplica solo al método bcrypt_password; plaintext_password nunca expira.

Cláusula GRANTS

Permite limitar los derechos de acceso disponibles para una sesión autenticada mediante un método de autenticación concreto. Acepta, entre paréntesis, una lista de privilegios con el mismo formato que la sentencia GRANT. La cláusula se especifica después de un método de autenticación (después de su cláusula VALID UNTIL, si la tiene) y se aplica únicamente a ese método. Cuando un usuario inicia sesión mediante dicho método de autenticación, los derechos de acceso de la sesión son la intersección entre los derechos de acceso del usuario (incluidos los procedentes de roles concedidos) y los privilegios enumerados en la cláusula. La cláusula nunca añade derechos de acceso: si un privilegio enumerado no se ha concedido al usuario, la sesión no lo tiene. Las sesiones autenticadas mediante dicho método tampoco pueden conceder privilegios (la GRANT OPTION nunca se conserva tras la intersección) ni administrar roles. La administración de roles incluye no solo crear, modificar, eliminar, conceder y revocar roles, sino también cambiar qué roles se activan de forma predeterminada para un usuario (SET DEFAULT ROLE y ALTER USER ... DEFAULT ROLE), lo que también se rechaza. EXECUTE AS cambia el principal de la sesión, por lo que una sentencia ejecutada bajo suplantación queda limitada por la intersección entre los derechos de acceso del usuario de destino y los privilegios enumerados, en lugar de por los derechos del usuario que inició sesión. El límite nunca se elimina, y la suplantación requiere que IMPERSONATE ON target esté concedido al usuario y enumerado en la cláusula, de modo que unas credenciales limitadas nunca pueden otorgar más acceso que las credenciales sin limitaciones del mismo usuario. Esto ofrece una forma práctica de crear tokens para aplicaciones: credenciales adicionales con una fecha de expiración y un conjunto limitado de privilegios, vinculadas al usuario; se muestran como ese usuario en system.query_log y system.processes, dejan de funcionar si se elimina el usuario y pierden derechos de acceso cuando el usuario los pierde.

La aplicación se realiza únicamente en el iniciador. El límite GRANTS del método de autenticación y su expiración VALID UNTIL se aplican únicamente en el nodo que recibe la consulta (el iniciador). No se propagan a otros nodos de un clúster, por lo que no debe confiar en la cláusula para restringir la ejecución en todo el clúster. Los nodos remotos conservan su ámbito de roles habitual. La cláusula tampoco está disponible en users.xml. La caché de resultados de consultas se comparte entre todos los métodos de autenticación de un usuario: aísla las entradas por usuario y roles, y un acierto de caché no se vuelve a comprobar con los GRANTS del método con el que se autenticó la sesión.

Ejemplos:

CREATE USER name1 IDENTIFIED BY 'qwerty' GRANTS (SELECT ON db.*)
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)

Tenga en cuenta que el límite es una propiedad del método de autenticación y se determina en el momento de iniciar sesión: cambiar la cláusula con ALTER USER afecta a las sesiones nuevas, no a las ya establecidas. Las concesiones de origen filtradas, como READ ON S3('s3://bucket/.*'), todavía no son compatibles con la cláusula: la intersección compara un filtro de origen como una cadena opaca y no puede restringir un filtro mediante otro, por lo que dicha concesión se rechaza en lugar de no conceder acceso silenciosamente. La cláusula solo es compatible con métodos de autenticación cuyas credenciales se verifican íntegramente de forma local en el servidor. Para los métodos cuya verificación contacta (o, en el caso de jwt, puede contactar —por ejemplo, para obtener las claves de firma—) con un sistema externo (ldap, kerberos, http, jwt), la cláusula se rechaza: cuando varios métodos de autenticación aceptan las mismas credenciales, el límite se aplica volviendo a comprobar las credenciales con los demás métodos, y realizar una comprobación adicional en un sistema externo no es seguro, por lo que otro método que acepte las mismas credenciales podría eludir el límite. Cuando más de un método de autenticación acepta las mismas credenciales efectivas, el inicio de sesión queda limitado de forma segura por todos ellos: la sesión obtiene la intersección de los GRANTS de todos los métodos coincidentes y expira en la fecha más temprana de sus VALID UNTIL. El VALID UNTIL más temprano prevalece incluso si ya ha pasado: el inicio de sesión se rechaza, exactamente como si hubiera expirado el único método coincidente, de modo que la expiración de un token nunca otorga silenciosamente a las credenciales compartidas los derechos o la vigencia de un método más amplio. Esta combinación solo se comprueba entre los métodos de autenticación verificados localmente por el servidor, por la misma razón por la que la cláusula se rechaza en un método verificado externamente: volver a comprobar la credencial en ese caso requeriría realizar un sondeo adicional no seguro del sistema externo. Por tanto, si la misma credencial también es aceptada por un método verificado externamente (ldap, kerberos, http, jwt) para el mismo usuario, el VALID UNTIL de ese método no forma parte de la combinación, y una caducidad anterior configurada en él no acorta la sesión obtenida mediante el método verificado localmente.

Cláusula GRANTEES

Especifica los usuarios o roles que pueden recibir privilegios de este usuario, siempre que este usuario también tenga concedidos todos los permisos de acceso necesarios con GRANT OPTION. Opciones de la cláusula GRANTEES:

user — Especifica un usuario al que este usuario puede conceder privilegios.
role — Especifica un rol al que este usuario puede conceder privilegios.
ANY — Este usuario puede conceder privilegios a cualquiera. Es la opción predeterminada.
NONE — Este usuario no puede conceder privilegios a nadie.

Puede excluir cualquier usuario o rol mediante la expresión EXCEPT. Por ejemplo, CREATE USER user1 GRANTEES ANY EXCEPT user2. Esto significa que, si a user1 se le han concedido algunos privilegios con GRANT OPTION, podrá conceder esos privilegios a cualquiera excepto a user2.

Ejemplos

Cree la cuenta de usuario mira con la contraseña qwerty:

CREATE USER mira HOST IP '127.0.0.1' IDENTIFIED WITH sha256_password BY 'qwerty';

mira debe iniciar la aplicación cliente en el host donde se ejecuta el servidor ClickHouse. Cree la cuenta de usuario john y asígnele roles:

CREATE USER john ROLE role1, role2;

Cree la cuenta de usuario john, asigne roles y establezca algunos de ellos como predeterminados:

CREATE USER john ROLE role1, role2 DEFAULT ROLE role1;

CREATE USER john ROLE role1, role2 DEFAULT ROLE ALL EXCEPT role2;

Cree la cuenta de usuario john y permítale conceder sus privilegios al usuario de la cuenta jack:

CREATE USER john GRANTEES jack;

Utilice un parámetro de consulta para crear la cuenta de usuario john:

SET param_user=john;
CREATE USER {user:Identifier};

SQL Reference

Data Types

Engines

Functions

Formats

Interfaces

Settings

System Tables

Data Lakes

Identificación

Ejemplos

Host de usuario

Cláusula VALID UNTIL

Cláusula VALID FOR

Cláusula GRANTS

Cláusula GRANTEES

Ejemplos

​Identificación

​Ejemplos

​Host de usuario

​Cláusula VALID UNTIL

​Cláusula VALID FOR

​Cláusula GRANTS

​Cláusula GRANTEES

​Ejemplos

Identificación

Ejemplos

Host de usuario

Cláusula VALID UNTIL

Cláusula VALID FOR

Cláusula GRANTS

Cláusula GRANTEES

Ejemplos