> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-detect-table-modification.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > Documentación sobre USER # CREATE USER Crea [cuentas de usuario](/es/concepts/features/security/access-rights#user-account-management). Sintaxis: ```sql theme={null} 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](/es/reference/statements/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](/es/concepts/features/configuration/server-config/configuration-files). 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. ```xml theme={null} .{12} be at least 12 characters long \p{N} contain at least 1 numeric character ``` 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
1. El siguiente nombre de usuario es `name1` y no requiere contraseña, lo que obviamente no ofrece mucha seguridad: ```sql theme={null} CREATE USER name1 NOT IDENTIFIED ``` 2. Para especificar una contraseña en texto plano: ```sql theme={null} 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... 3. 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: ```sql theme={null} 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: ```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'; ``` 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'. 4. `double_sha1_password` no suele ser necesario, pero resulta útil al trabajar con clientes que lo requieren (como la interfaz MySQL): ```sql theme={null} CREATE USER name4 IDENTIFIED WITH double_sha1_password BY 'my_password' ``` ClickHouse genera y ejecuta la siguiente consulta: ```response theme={null} CREATE USER name4 IDENTIFIED WITH double_sha1_hash BY 'CCD3A959D6A004B9C3807B728BC2E55B67E10518' ``` 5. `bcrypt_password` es la opción más segura para almacenar contraseñas. Utiliza el algoritmo [bcrypt](https://en.wikipedia.org/wiki/Bcrypt), que es resistente a ataques de fuerza bruta incluso si el hash de la contraseña se ve comprometido. ```sql theme={null} 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: ```xml theme={null} 12 ``` 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. 6. El tipo de contraseña también se puede omitir: ```sql theme={null} 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: ```xml theme={null} sha256_password ``` Los tipos de contraseña disponibles son: `plaintext_password`, `sha256_password`, `double_sha1_password`. 7. Se pueden especificar varios métodos de autenticación: ```sql theme={null} CREATE USER user1 IDENTIFIED WITH plaintext_password by '1', bcrypt_password by '2', plaintext_password by '3'' ``` Notas: 1. 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. 2. `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](https://en.wikipedia.org/wiki/Subnetwork). 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](http://www.pcre.org/) al especificar hosts de usuario. Por ejemplo, `HOST REGEXP '.*\.mysite\.com'`. * `HOST LIKE 'template'` — Permite usar el operador [LIKE](/es/reference/functions/regular-functions/string-search-functions#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`](/es/reference/system-tables/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](/es/reference/data-types/special-data-types/interval), 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`](#valid-until-clause). 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](/es/reference/statements/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](/es/concepts/features/performance/caches/query-cache) 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](/es/reference/statements/grant#privileges) de este usuario, siempre que este usuario también tenga concedidos todos los permisos de acceso necesarios con [GRANT OPTION](/es/reference/statements/grant#granting-privilege-syntax). 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`: ```sql theme={null} 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: ```sql theme={null} CREATE USER john ROLE role1, role2; ``` Cree la cuenta de usuario `john`, asigne roles y establezca algunos de ellos como predeterminados: ```sql theme={null} CREATE USER john ROLE role1, role2 DEFAULT ROLE role1; ``` o ```sql theme={null} 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`: ```sql theme={null} CREATE USER john GRANTEES jack; ``` Utilice un parámetro de consulta para crear la cuenta de usuario `john`: ```sql theme={null} SET param_user=john; CREATE USER {user:Identifier}; ```