> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

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

> Cette page explique comment les administrateurs peuvent ajouter des comptes de service de base de données

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.

<div id="overview">
  ## Vue d’ensemble
</div>

[SET ROLE](/docs/fr/reference/statements/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

<div id="setup-service-roles">
  ## Configurer un rôle de service
</div>

<Steps>
  <Step title="Accorder des rôles au compte de service" id="grant-roles-to-service-account">
    Commencez par créer des rôles avec les privilèges/paramètres souhaités, puis accordez-les au compte de service.

    ```sql theme={null}
    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;
    ```
  </Step>

  <Step title="Utiliser SET ROLE pour définir les limites de la session" id="define-permission-boundaries">
    Au début d’une session, le compte de service choisit quels rôles sont actifs :

    ```sql theme={null}
    -- Lecture seule pour cette session
    SET ROLE read_only_role;
    ```

    ou :

    ```sql theme={null}
    -- 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 :

    ```sql theme={null}
    SET ROLE NONE;
    ```

    ou activer plusieurs rôles :

    ```sql theme={null}
    SET ROLE read_only_role, maint_role;
    ```

    Les rôles actuellement actifs peuvent être consultés via `system.current_roles`.
  </Step>

  <Step title="Définir les rôles par défaut pour le compte de service" id="set-default-role">
    Pour garantir que le compte de service démarre toujours dans un mode restreint, configurez les rôles par défaut :

    ```sql theme={null}
    SET DEFAULT ROLE read_only_role TO service_user;
    ```

    ou

    ```sql theme={null}
    SET DEFAULT ROLE ALL EXCEPT maint_role TO service_user;
    ```
  </Step>

  <Step title="Utiliser SET ROLE via HTTP / par programmation" id="use-set-role-programmatically">
    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 :

    ```shell theme={null}
    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.
  </Step>
</Steps>