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

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 à chaque utilisateur lorsque les autorisations doivent persister d’une requête et d’une session à l’autre.

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:user@example.com

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

sql-console-role:user@example.com

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.

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.

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:user@example.com`;

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

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:user@example.com`;

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

GRANT sql_console_developer, sql_console_read_only
TO `sql-console-role:user@example.com`;

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:user@example.com à sql-console:user@example.com ; 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:user@example.com.

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

​Symptômes

​Pourquoi ce comportement se produit

​Fonctionnement des rôles utilisateur de SQL Console

​Configurer des autorisations persistantes

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

Symptômes

Pourquoi ce comportement se produit

Fonctionnement des rôles utilisateur de SQL Console

Configurer des autorisations persistantes

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