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 avecsql_console_read_only. - Les résultats de
currentRoles,enabledRolesetdefaultRolesvarient d’une requête à l’autre. - L’exécution de
SET ROLEavec une autre requête ne conserve pas systématiquement le rôle sélectionné. SHOW GRANTSré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.comClickHouse Cloud recherche également un rôle de base de données dont le nom respecte la convention suivante :
sql-console-role:user@example.comLorsqu’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.