ALTER USER

Modifie les comptes d’utilisateur ClickHouse. Syntaxe :

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

Pour utiliser ALTER USER, vous devez disposer du privilège ALTER USER. SET variable = value est un alias de MODIFY SETTING variable = value : il modifie un seul paramètre sans toucher aux autres. Préférez-le (ou MODIFY SETTING) à la clause SETTINGS seule, qui remplace l’intégralité de la liste des paramètres et supprime également tous les profils hérités (parents).

Clause GRANTEES

Spécifie les utilisateurs ou les rôles autorisés à recevoir des privilèges de cet utilisateur, à condition que celui-ci dispose également de tous les droits d’accès requis accordés avec GRANT OPTION. Options de la clause GRANTEES :

user — Spécifie un utilisateur auquel cet utilisateur peut accorder des privilèges.
role — Spécifie un rôle auquel cet utilisateur peut accorder des privilèges.
ANY — Cet utilisateur peut accorder des privilèges à n’importe qui. Il s’agit du paramètre par défaut.
NONE — Cet utilisateur ne peut accorder de privilèges à personne.

Vous pouvez exclure n’importe quel utilisateur ou rôle à l’aide de l’expression EXCEPT. Par exemple, ALTER USER user1 GRANTEES ANY EXCEPT user2. Cela signifie que si user1 dispose de privilèges accordés avec GRANT OPTION, il pourra les accorder à n’importe qui, sauf à user2.

Exemples

Définissez les rôles attribués comme rôles par défaut :

ALTER USER user DEFAULT ROLE role1, role2

Si aucun rôle n’a été attribué au préalable à un utilisateur, ClickHouse lève une exception. Définissez tous les rôles attribués comme rôles par défaut :

ALTER USER user DEFAULT ROLE ALL

Si un rôle est attribué à un utilisateur ultérieurement, il deviendra automatiquement le rôle par défaut. Définissez tous les rôles attribués par défaut, à l’exception de role1 et role2 :

ALTER USER user DEFAULT ROLE ALL EXCEPT role1, role2

Permet à l’utilisateur du compte john d’accorder ses privilèges à l’utilisateur du compte jack :

ALTER USER john GRANTEES jack;

Ajoute de nouvelles méthodes d’authentification à l’utilisateur tout en conservant celles existantes :

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

Remarques :

Les anciennes versions de ClickHouse peuvent ne pas prendre en charge la syntaxe associée à plusieurs méthodes d’authentification. Par conséquent, si le serveur ClickHouse contient de tels utilisateurs et qu’il est rétrogradé vers une version qui ne prend pas cette syntaxe en charge, ces utilisateurs deviendront inutilisables et certaines opérations liées aux utilisateurs ne fonctionneront plus. Pour effectuer la rétrogradation correctement, il faut configurer tous les utilisateurs de sorte qu’ils n’aient qu’une seule méthode d’authentification avant la rétrogradation. Sinon, si le serveur a été rétrogradé sans suivre la procédure appropriée, les utilisateurs défectueux doivent être supprimés.
no_password ne peut pas coexister avec d’autres méthodes d’authentification pour des raisons de sécurité. Pour cette raison, il n’est pas possible d’ADD une méthode d’authentification no_password. La requête ci-dessous générera une erreur :

ALTER USER user1 ADD IDENTIFIED WITH no_password

Si vous souhaitez supprimer les méthodes d’authentification d’un utilisateur et utiliser no_password, vous devez le préciser dans le formulaire de remplacement ci-dessous. Réinitialise les méthodes d’authentification et ajoute celles spécifiées dans la requête (effet de IDENTIFIED en tête sans le mot-clé ADD) :

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

Réinitialisez les méthodes d’authentification et ne conservez que la dernière ajoutée :

ALTER USER user1 RESET AUTHENTICATION METHODS TO NEW

Clause VALID UNTIL

Permet de spécifier la date d’expiration et, éventuellement, l’heure d’une méthode d’authentification. Elle accepte une chaîne de caractères comme paramètre. Il est recommandé d’utiliser le format YYYY-MM-DD [hh:mm:ss] [timezone] pour les valeurs de date et d’heure. Par défaut, ce paramètre est égal à 'infinity'. La plage d’échéances acceptées va de 1900-01-01 00:00:00 UTC à 9999-12-31 09:59:59 UTC — le dernier instant qui reste dans l’année 9999 dans tous les fuseaux horaires, afin que l’instant stocké ne soit jamais borné lors de son affichage. Une échéance passée signifie que les identifiants ont déjà expiré. Les échéances antérieures à 1970-01-01 00:00:01 UTC ne sont acceptées que comme marqueur « déjà expiré » : elles sont normalisées vers le plus ancien instant expiré, soit une seconde après l’époque Unix (1970-01-01 00:00:01 UTC), de sorte que SHOW CREATE USER affiche cet instant au lieu de l’échéance indiquée. Les échéances à partir de cet instant sont stockées telles quelles. Une échéance est stockée sous la forme d’un instant absolu, mais SHOW CREATE USER et system.users l’affichent dans le fuseau horaire du serveur ou de la session. Ainsi, un même instant stocké apparaît sous la forme d’heures locales différentes sur des serveurs configurés différemment : par exemple, l’instant expiré normalisé ci-dessus s’affiche sous la forme 1970-01-01 00:00:01 sur un serveur en UTC et 1970-01-01 14:00:01 sur un serveur en Pacific/Kiritimati. L’application de l’échéance utilise toujours l’instant stocké, et non son affichage. La position de la clause détermine les méthodes d’authentification auxquelles elle s’applique :

Avant la clause IDENTIFIED (ou lorsque la requête ne spécifie aucune méthode d’authentification) : l’échéance est définie au niveau de l’utilisateur et s’applique à toutes ses méthodes d’authentification.
Après une méthode d’authentification : l’échéance s’applique uniquement à cette méthode. Une clause placée après toute la liste IDENTIFIED s’applique donc uniquement à la dernière méthode, les méthodes précédentes n’ayant pas d’expiration.

Exemples :

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' — l’échéance définie au niveau de l’utilisateur s’applique aux deux méthodes.
ALTER USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID UNTIL '2025-01-01' — l’échéance s’applique uniquement à la méthode bcrypt_password ; plaintext_password n’expire jamais.

Clause VALID FOR

La clause VALID FOR est un raccourci pratique pour VALID UNTIL. Au lieu d’une date et d’une heure absolues, elle accepte un intervalle, et l’échéance est calculée en ajoutant cet intervalle à l’heure actuelle au moment de l’exécution de la requête. Le résultat est stocké sous la forme VALID UNTIL, de sorte que SHOW CREATE USER affiche toujours l’échéance absolue résolue. Elle suit les mêmes règles de positionnement que VALID UNTIL : avant IDENTIFIED (ou sans méthode d’authentification), elle définit une échéance au niveau de l’utilisateur qui s’applique à toutes les méthodes, tandis qu’après une méthode d’authentification, elle ne s’applique qu’à cette méthode. L’échéance est stockée et appliquée avec une précision à la seconde ; les intervalles inférieurs à la seconde (NANOSECOND, MICROSECOND, MILLISECOND) sont donc rejetés, et la plus petite unité acceptée est SECOND. Un intervalle négatif permet de marquer les identifiants comme déjà expirés ; si l’échéance obtenue est antérieure à 1970-01-01 00:00:01 UTC, elle est normalisée à cet instant expiré minimal, que SHOW CREATE USER affiche ensuite dans le fuseau horaire du serveur ou de la session, comme décrit pour VALID UNTIL. Exemples :

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' — l’échéance au niveau de l’utilisateur s’applique aux deux méthodes.
ALTER USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID FOR INTERVAL 30 DAY — l’échéance s’applique uniquement à la méthode bcrypt_password ; plaintext_password n’expire jamais.

Clause GRANTS

Permet de limiter les droits d’accès disponibles pour une session authentifiée à l’aide d’une méthode d’authentification donnée. Consultez la clause GRANTS de CREATE USER pour plus de détails. Associée à ADD IDENTIFIED, cette clause offre un moyen pratique de créer des jetons pour les applications : des identifiants supplémentaires assortis d’une date d’expiration et d’un ensemble limité de privilèges. Exemple :

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

Clause GRANTEES

Exemples

Clause VALID UNTIL

Clause VALID FOR

Clause GRANTS

​Clause GRANTEES

​Exemples

​Clause VALID UNTIL

​Clause VALID FOR

​Clause GRANTS

Clause GRANTEES

Exemples

Clause VALID UNTIL

Clause VALID FOR

Clause GRANTS