Pourquoi `SET ROLE` ne persiste pas dans la SQL Console de ClickHouse Cloud

Découvrez pourquoi SET ROLE ne persiste pas dans la SQL Console de ClickHouse Cloud et comment attribuer des autorisations persistantes par utilisateur.

Lorsque vous exécutez SET ROLE dans la SQL Console de ClickHouse Cloud, le rôle peut sembler changer pour une requête, puis revenir à son état précédent lors de la requête suivante. Utilisez un rôle SQL Console propre à l’utilisateur lorsque les autorisations doivent persister d’une requête et d’une session à l’autre.

Préférez les rôles de base de données gérés par le Cloud pour gérer l’accès à la base de données depuis la console. Les rôles sql-console-role:<email> ne sont pas compatibles avec les sessions JWT dans la SQL Console.

​

Symptômes

Vous pouvez observer un ou plusieurs des symptômes suivants :

• Après avoir exécuté SET ROLE sql_console_developer, les requêtes ultérieures s’exécutent toujours avec sql_console_read_only.
• Les résultats de currentRoles, enabledRoles et defaultRoles varient d’une requête à l’autre.
• L’exécution de SET ROLE avec une autre requête ne conserve pas systématiquement le rôle sélectionné.
• SHOW GRANTS répertorie les rôles attendus, mais leurs autorisations ne sont pas actives.

Vous pouvez examiner l’utilisateur courant et les rôles avec :

SELECT
    currentUser(),
    currentRoles(),
    enabledRoles(),
    defaultRoles();

​

Pourquoi ce comportement se produit

La SQL Console envoie des requêtes via des connexions HTTP sans état vers un service ClickHouse Cloud comportant plusieurs réplicas. Rien ne garantit que des requêtes consécutives utilisent la même connexion ou le même réplica.

SET ROLE modifie les rôles activés pour la session en cours. Il ne conserve pas cet état de session pour les requêtes ultérieures de la SQL Console. Une requête ultérieure peut donc s’exécuter sans le rôle activé par une requête précédente.

Pour cette raison, n’utilisez pas SET ROLE comme mécanisme persistant de contrôle d’accès dans la SQL Console.

​

Fonctionnement des rôles utilisateur de SQL Console

Lorsqu’un utilisateur ouvre la SQL Console, ClickHouse Cloud crée un utilisateur de base de données selon la convention de nommage suivante :

sql-console:[e-mail]

ClickHouse Cloud recherche également un rôle de base de données dont le nom respecte la convention suivante :

sql-console-role:[e-mail]

Lorsqu’il existe, ClickHouse Cloud affecte ce rôle à l’utilisateur SQL Console correspondant. C’est la méthode prise en charge pour accorder des autorisations personnalisées persistantes à un utilisateur SQL Console donné.

Entité	Objectif	Persistant
sql-console:<email>	Utilisateur de base de données provisionné à l’ouverture de la SQL Console par l’utilisateur	Oui, géré par ClickHouse Cloud
sql_console_admin et sql_console_read_only	Rôles SQL Console intégrés	Oui, géré par ClickHouse Cloud
sql-console-role:<email>	Rôle personnalisé créé pour un utilisateur par un administrateur	Oui, appliqué à la connexion de l’utilisateur

​

Configurer des autorisations persistantes

Exécutez les instructions suivantes avec un utilisateur disposant de privilèges administratifs sur le service, tel qu’un utilisateur SQL Console ayant le rôle sql_console_admin ou tout autre utilisateur disposant du privilège ACCESS MANAGEMENT.

1. Créer le rôle personnalisé

   L’exemple suivant crée un rôle personnalisé sql_console_developer et lui accorde des autorisations sur my_database :

   CREATE ROLE IF NOT EXISTS sql_console_developer;
   
   GRANT SELECT, INSERT, CREATE TABLE
   ON my_database.*
   TO sql_console_developer;
   

   sql_console_developer est un rôle fourni à titre d’exemple, et non un rôle ClickHouse Cloud intégré. Vous pouvez utiliser à la place un rôle personnalisé existant disposant des autorisations dont l’utilisateur a besoin.

2. Créer le rôle SQL Console propre à l’utilisateur

   Créez un rôle dont le nom contient l’adresse e-mail exacte de l’utilisateur :

   CREATE ROLE IF NOT EXISTS `sql-console-role:[e-mail]`;
   

   Les accents graves sont requis, car le nom du rôle contient des caractères spéciaux.

3. Accorder le rôle personnalisé

   Accordez le rôle souhaité au rôle SQL Console propre à l’utilisateur :

   GRANT sql_console_developer
   TO `sql-console-role:[e-mail]`;
   

   Vous pouvez accorder plusieurs rôles si nécessaire :

   GRANT sql_console_developer, sql_console_read_only
   TO `sql-console-role:[e-mail]`;
   
4. Démarrer une nouvelle session SQL Console

   Demandez à l’utilisateur de se déconnecter, puis de se reconnecter à SQL Console, ou d’actualiser l’onglet du navigateur. Dans la nouvelle session, ClickHouse Cloud applique sql-console-role:[e-mail] à sql-console:[e-mail] ; aucune instruction SET ROLE n’est requise.

   Vérifiez les rôles actifs :

   SELECT
       currentUser(),
       currentRoles(),
       enabledRoles(),
       defaultRoles();
   

   Les résultats doivent inclure les autorisations accordées via sql-console-role:[e-mail].

​

Évitez de modifier les rôles gérés

Ne modifiez pas sql_console_admin ni sql_console_read_only afin d’accorder des autorisations personnalisées. ClickHouse Cloud gère ces rôles intégrés. Utilisez plutôt sql-console-role:<email> pour définir des autorisations par utilisateur.

Pour des exemples généraux de gestion des rôles, consultez Requêtes courantes de gestion des accès.