Skip to content
ClickHouse Docs
ClickHouse DocsClickHouse Docs
49.6kGet Started

Gérer les comptes de service de base de données

View as MarkdownEdit this pageReport an issueSet up docs MCP

Les comptes de service de base de données peuvent être aussi simples qu’un utilisateur disposant d’un mot de passe distinct ou d’un certificat pour l’authentification. Les utilisateurs plus avancés peuvent vouloir configurer des comptes dont le périmètre des autorisations peut être modifié dynamiquement avec SET ROLE, afin de passer rapidement d’un profil à l’autre sans se déconnecter ni recharger la page.

Vue d’ensemble

SET ROLE peut être utilisé pour définir dynamiquement le périmètre des permissions d’un compte de service pendant une session. Cela fonctionne en limitant les permissions effectives d’un utilisateur à celles accordées par le ou les rôles activés. Cette approche présente plusieurs avantages :

  • Les comptes de service peuvent se voir attribuer plusieurs rôles, mais n’activer que celui nécessaire pour une requête donnée.
  • Si le compte de service est compromis, les attaquants ne peuvent utiliser que les permissions du rôle actif.
  • Un même compte peut exécuter diverses tâches en changeant de rôle, plutôt qu’en nécessitant des identifiants distincts pour chaque tâche.
  • Les permissions peuvent être mises à jour pour toute une catégorie de comptes de service en modifiant un seul rôle, au lieu de mettre à jour chaque utilisateur individuellement.
  • Les journaux peuvent indiquer précisément quel rôle était actif pendant une requête, ce qui fournit un contexte plus clair pour les audits de sécurité.

En pratique, vous :

  1. Concevez des rôles qui définissent les limites autorisées (read_only, maintenance, etc.)
  2. Les accordez au compte de service
  3. Au moment de la connexion, choisissez le ou les rôles actifs via SET ROLE (ou le paramètre de rôle), ce qui limite ainsi ce que cette session peut faire

Configurer un rôle de service

Accorder des rôles au compte de service

Commencez par créer des rôles avec les privilèges/paramètres souhaités, puis accordez-les au compte de service.

CREATE ROLE read_only_role;
GRANT SELECT ON db1.* TO read_only_role;

CREATE ROLE maint_role;
GRANT SELECT, INSERT, ALTER on db1.* TO maint_role;

GRANT read_only_role, maint_role TO service_user;

Utiliser SET ROLE pour définir les limites de la session

Au début d’une session, le compte de service choisit quels rôles sont actifs :

-- Lecture seule pour cette session
SET ROLE read_only_role;

ou :

-- Utiliser tous les rôles accordés (tous les droits)
SET ROLE ALL;

SET ROLE active les rôles pour l’utilisateur actuel ; les privilèges effectifs correspondent à l’union de tous les rôles actifs, plus ceux accordés directement à l’utilisateur.

Vous pouvez également désactiver tous les rôles :

SET ROLE NONE;

ou activer plusieurs rôles :

SET ROLE read_only_role, maint_role;

Les rôles actuellement actifs peuvent être consultés via system.current_roles.

Définir les rôles par défaut pour le compte de service

Pour garantir que le compte de service démarre toujours dans un mode restreint, configurez les rôles par défaut :

SET DEFAULT ROLE read_only_role TO service_user;

ou

SET DEFAULT ROLE ALL EXCEPT maint_role TO service_user;

Utiliser SET ROLE via HTTP / par programmation

Si le compte de service se connecte via HTTP, vous ne pouvez pas envoyer SET ROLE; SELECT … sous forme de requête multi-instruction. À la place, transmettez le rôle comme paramètre de requête :

curl "https://host:8123?user=service_user&password=...&role=read_only_role" \
 --data-binary "SELECT * FROM db1.table1"

?role=… équivaut à exécuter SET ROLE read_only_role avant l’instruction. Plusieurs paramètres de rôle se comportent comme SET ROLE role 1, role 2.

Certains drivers (par exemple ClickHouse Connect for Python) exposent également un paramètre de rôle envoyé avec chaque requête, que le serveur utilise comme rôle de session.

Navigation