ALTER USER

Modifica las cuentas de usuario de ClickHouse. Sintaxis:

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' [,...] ]

Para usar ALTER USER, debe contar con el privilegio ALTER USER. SET variable = value es un alias de MODIFY SETTING variable = value: modifica una sola SETTING sin afectar el resto. Se prefiere (o MODIFY SETTING) a la cláusula SETTINGS simple, que reemplaza toda la lista de SETTINGS y además elimina todos los perfiles heredados (padre).

Cláusula GRANTEES

Especifica los usuarios o roles que pueden recibir privilegios de este usuario, siempre que este usuario también tenga todos los privilegios de acceso necesarios concedidos 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 cualquier usuario o rol. Es la configuración predeterminada.
NONE — Este usuario no puede conceder privilegios a ningún usuario ni rol.

Puede excluir cualquier usuario o rol mediante la expresión EXCEPT. Por ejemplo, ALTER 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

Establece los roles asignados como predeterminados:

ALTER USER user DEFAULT ROLE role1, role2

Si no se han asignado roles previamente a un usuario, ClickHouse lanza una excepción. Establezca como predeterminados todos los roles asignados:

ALTER USER user DEFAULT ROLE ALL

Si en el futuro se asigna un rol a un usuario, pasará a ser el predeterminado automáticamente. Establezca como predeterminados todos los roles asignados, excepto role1 y role2:

ALTER USER user DEFAULT ROLE ALL EXCEPT role1, role2

Permite que el usuario john conceda sus privilegios al usuario jack:

ALTER USER john GRANTEES jack;

Añade nuevos métodos de autenticación al usuario, conservando los existentes:

ALTER USER user1 ADD 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 múltiples métodos de autenticación. Por lo tanto, si el servidor de ClickHouse contiene este tipo de usuarios y se degrada a una versión que no los admite, dichos usuarios quedarán inutilizables y algunas operaciones relacionadas con los usuarios dejarán de funcionar. Para llevar a cabo la degradación sin problemas, es necesario configurar todos los usuarios para que tengan un único método de autenticación antes de hacerlo. Como alternativa, si el servidor se degradó sin seguir el procedimiento adecuado, se deben eliminar los usuarios defectuosos.
no_password no puede coexistir con otros métodos de autenticación por motivos de seguridad. Por ello, no es posible ADD un método de autenticación no_password. La consulta siguiente generará un error:

ALTER USER user1 ADD IDENTIFIED WITH no_password

Si quiere eliminar los métodos de autenticación de un usuario y utilizar no_password, debe especificarlo en la siguiente forma de sustitución. Restablece los métodos de autenticación y añade los especificados en la consulta (efecto de un IDENTIFIED inicial sin la palabra clave ADD):

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

Restablece los métodos de autenticación y conserva el último añadido:

ALTER USER user1 RESET AUTHENTICATION METHODS TO NEW

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 YYYY-MM-DD [hh:mm:ss] [timezone] para valores DateTime. De forma predeterminada, este parámetro es 'infinity'. El intervalo de fechas límite aceptado abarca desde 1900-01-01 00:00:00 UTC hasta 9999-12-31 09:59:59 UTC —el último instante que se mantiene dentro del año 9999 en todas las zonas horarias—, de modo que el instante almacenado nunca se limita 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 se aceptan únicamente como marcador de «ya expirado»: se canonicalizan al instante expirado más temprano, 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 indicada. 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 muestran en la zona horaria del servidor o de la sesión, por lo que el mismo instante almacenado aparece como texto de hora local diferente en servidores configurados de forma distinta: por ejemplo, el instante expirado canonicalizado anterior se muestra 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 solo a ese método. Por tanto, una cláusula escrita después de toda la lista IDENTIFIED se asocia únicamente al último método, dejando los métodos anteriores sin expiración.

Ejemplos:

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' — la fecha límite a nivel de usuario se aplica a ambos métodos.
ALTER 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 solo al método bcrypt_password; plaintext_password nunca expira.

Cláusula VALID FOR

La cláusula VALID FOR es una forma abreviada 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 de ejecutar la consulta. El resultado se almacena en formato VALID UNTIL, por lo que SHOW CREATE USER siempre muestra la fecha límite absoluta resultante. Sigue las mismas reglas de posición que VALID UNTIL: antes de IDENTIFIED (o sin ningún 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 únicamente 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ínima 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 primer instante expirado, que es el que SHOW CREATE USER muestra posteriormente, representado en la zona horaria del servidor o de la sesión, como se describe para VALID UNTIL. Ejemplos:

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' — la fecha límite a nivel de usuario se aplica a ambos métodos.
ALTER 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 únicamente 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 específico. Consulta la cláusula GRANTS de CREATE USER para obtener más información. Junto con ADD IDENTIFIED, proporciona una forma práctica de crear tokens para aplicaciones: una credencial adicional con fecha de expiración y un conjunto limitado de privilegios. Ejemplo:

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

Cláusula GRANTEES

Ejemplos

Cláusula VALID UNTIL

Cláusula VALID FOR

Cláusula GRANTS

​Cláusula GRANTEES

​Ejemplos

​Cláusula VALID UNTIL

​Cláusula VALID FOR

​Cláusula GRANTS

Cláusula GRANTEES

Ejemplos

Cláusula VALID UNTIL

Cláusula VALID FOR

Cláusula GRANTS