> ## 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.
# Modèle de privilèges
> Ce que le Connecteur ClickHouse peut et ne peut pas faire : connexions sortantes, privilèges ClickHouse, RBAC Kubernetes, attribution et minimisation des données
Cette page constitue la référence de sécurité du Connecteur ClickHouse : l’ensemble des connexions qu’il établit, les privilèges exacts dont il dispose, ce qu’il ne peut structurellement pas faire et la façon dont chaque action est attribuée. Pour comprendre comment ces éléments s’articulent, consultez [l’architecture](/docs/fr/products/bring-your-own-cloud/connector/architecture).
## Fonctionnalités du connecteur
### Connexions sortantes
Voici la liste complète des connexions établies par le connecteur. Elles proviennent toutes de votre environnement.
| Destination | Protocole | Objectif |
| ----------------------------------------------------------------- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Point de terminaison de l’API du connecteur de votre organisation | HTTPS avec mTLS, chaque requête étant signée par HMAC | `POST /v1/metrics`, `/v1/self-metrics`, `/v1/status`, `/v1/instance/sync`, `/v1/infra/sync`, `/v1/backup/sync`, `/v1/pcm/cert/renew` |
| Point de terminaison de l’API du connecteur de votre organisation | WebSocket sortant, `/v1/commands/ws` | Canal de commandes de l’outil de dépannage, conditionné par l’état de la session d’assistance |
| Point de terminaison d’inscription de votre organisation | HTTPS (jeton d’inscription ou HMAC ; sans mTLS) | Échange du jeton et signature du certificat (`/v1/pcm/cert/sign`) lors de l’installation |
| Vos instances ClickHouse | Protocole natif ClickHouse | Requêtes en lecture seule exécutées en tant que `pcm_scraper` et `pcm_troubleshooter`, ainsi que l’instruction de vidage des journaux du scraper (voir les [autorisation](#clickhouse-grants)) |
| Serveur d’API Kubernetes | HTTPS | Lectures limitées à l’espace de noms et demandes de jetons ServiceAccount (pour les deux cibles) ; lecture et mise à jour, par nom exact, du Secret mTLS du connecteur afin de conserver les certificats renouvelés (installations Kubernetes uniquement ; une VM écrit les renouvellements dans ses fichiers TLS locaux) |
| Point de terminaison JWKS de votre fournisseur d’identité | HTTPS | Validation du jeton de l’opérateur, uniquement lorsque la passerelle de session est activée |
En entrée, le connecteur expose uniquement des ports locaux de contrôle d’état et de métriques, ainsi que la passerelle de session facultative. Rien d’autre n’écoute, et ClickHouse Cloud ne se connecte jamais à votre environnement : il peut uniquement répondre au WebSocket sortant de l’outil de dépannage.
### Autorisations ClickHouse
Le provisionnement crée un utilisateur en lecture seule par composant. La seule exception à la lecture seule est l’autorisation `SYSTEM FLUSH LOGS` accordée au scraper et indiquée ci-dessous, qui ne permet ni de lire ni de modifier quoi que ce soit ; elle force uniquement les tables de logs à rendre persistantes les entrées déjà présentes dans leur tampon. Les utilisateurs sont créés avec `IDENTIFIED WITH bcrypt_hash` : seul un hachage bcrypt salé figure dans le SQL de provisionnement ; le mot de passe en clair se trouve uniquement dans le fichier d’identifiants lu par le démon au moment de l’exécution. Les autorisations sont exactement les suivantes, avec les ensembles de tables par défaut :
```sql theme={null}
CREATE USER IF NOT EXISTS `pcm_scraper` IDENTIFIED WITH bcrypt_hash BY '';
GRANT SELECT ON `system`.`asynchronous_metric_log` TO `pcm_scraper`;
GRANT SELECT ON `system`.`metric_log` TO `pcm_scraper`;
GRANT SELECT ON `system`.`server_settings` TO `pcm_scraper`;
GRANT SELECT ON `system`.`tables` TO `pcm_scraper`;
GRANT SELECT ON `system`.`warnings` TO `pcm_scraper`;
GRANT SELECT ON `system`.`user_directories` TO `pcm_scraper`;
GRANT READ ON REMOTE TO `pcm_scraper`;
GRANT SYSTEM FLUSH LOGS ON *.* TO `pcm_scraper`;
```
`READ ON REMOTE` est obligatoire, car les requêtes de scrape enveloppent chaque table système dans `clusterAllReplicas()`. `SYSTEM FLUSH LOGS` doit être accordé au niveau global, car ClickHouse rejette les portées plus restreintes pour ce privilège ; ClickHouse ne l’applique qu’aux tables système `*_log`, de sorte que ce privilège accordé est plus large que la capacité réelle.
```sql theme={null}
CREATE USER IF NOT EXISTS `pcm_troubleshooter` IDENTIFIED WITH bcrypt_hash BY '';
GRANT SELECT ON `system`.`asynchronous_metrics` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`build_options` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`clusters` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`columns` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`databases` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`detached_parts` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`disks` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`events` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`formats` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`functions` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`grants` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`merges` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`metrics` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`mutations` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts_columns` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts_summary` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`processes` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`replicas` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`replication_queue` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`roles` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings_profile_elements` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings_profiles` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`storage_policies` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`table_engines` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`tables` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`users` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`user_directories` TO `pcm_troubleshooter`;
```
L’autorisation `system.user_directories` accordée aux deux utilisateurs n’est requise que pour un diagnostic : `clicklink clctl preflight` s’exécute avec les propres identifiants du connecteur et vérifie comment l’instance stocke ses utilisateurs ClickHouse (répliqués ou locaux). La table contient des métadonnées de configuration du stockage des utilisateurs, et non des données utilisateur. Elle n’est incluse ni dans l’ensemble de scrape ni dans la liste d’autorisation des tables de session ; aucun chemin de sortie de scrape ou de session ne la lit donc. Sans cette autorisation, cette unique vérification preflight signale qu’elle est ignorée, tandis que tout le reste se poursuit.
Outre le privilège `SELECT` accordé table par table, le seul privilège système est `SYSTEM FLUSH LOGS` du scraper : il force les tables système `*_log` à écrire sur disque les entrées en mémoire tampon afin que les scrapes accèdent aux données à jour, et ne fait rien d’autre ; ClickHouse ne l’applique qu’aux tables de logs, bien que ce privilège ne puisse être accordé qu’à l’échelle globale. Aucun privilège `INSERT`, DDL, de gestion des utilisateurs, de paramètres ou de contrôle des processus n’est accordé. Lorsqu’un second déploiement de connecteur partage une instance, ses utilisateurs portent un suffixe (`pcm_scraper_`) et disposent des mêmes ensembles d’autorisations.
### RBAC Kubernetes
Le chart crée uniquement des rôles limités à l’espace de noms ; aucun ClusterRole ni ClusterRoleBinding n’est créé.
| Ressources | Verbes | Portée |
| ----------------------------------------------------------------------------------------------- | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| `secrets` | `get` | Uniquement les noms exacts : le secret mTLS, le secret HMAC et chaque secret de bundle d’accès par instance |
| `secrets` | `update` | Uniquement le secret mTLS, par son nom exact, afin que les démons puissent conserver le certificat client renouvelé automatiquement |
| `serviceaccounts/token` | `create` | Uniquement les noms exacts : le ServiceAccount du composant lui-même et chaque ServiceAccount de bundle d’accès par instance |
| `pods`, `pods/log`, `pods/status`, `services`, `configmaps`, `events`, `persistentvolumeclaims` | `get`, `list`, `watch` | Uniquement pour le dépanneur |
| `deployments`, `statefulsets`, `replicasets` (`apps`) | `get`, `list`, `watch` | Uniquement pour le dépanneur |
## Ce que le connecteur ne peut pas faire
* **Aucune écriture dans les données ni dans l’état de ClickHouse.** Les autorisations ci-dessus n’incluent aucun `INSERT`, aucune instruction DDL ni aucun privilège de gestion des utilisateurs, des paramètres ou des processus ; le seul privilège de classe SYSTEM, `SYSTEM FLUSH LOGS` du scraper, permet uniquement aux tables de logs de rendre persistantes les données qu’elles ont déjà mises en mémoire tampon. Le connecteur ne peut pas modifier les données, les schémas, les utilisateurs ni les paramètres.
* **Aucune exécution de commandes.** Le RBAC n’inclut aucun `pods/exec` ; le connecteur ne peut pas exécuter de commandes dans vos pods.
* **Aucune suppression ni aucun patch.** Le RBAC autorise deux mutations : l’`update` ciblant précisément le Secret mTLS du connecteur, et `create` sur `serviceaccounts/token`, qui génère des tokens de courte durée pour les ServiceAccounts du connecteur et ne modifie aucun objet stocké.
* **Aucune portée à l’échelle du cluster.** Chaque Role est associé à un namespace ; le connecteur ne peut pas lister ni lire des ressources en dehors des namespaces que vous avez autorisés.
* **Aucune connexion entrante.** ClickHouse Cloud n’ouvre jamais de connexion vers votre environnement. Le seul canal de commande est le WebSocket sortant du troubleshooter, qui refuse toute commande tant qu’aucune session d’assistance que vous avez activée n’est en cours. Même pendant une session, la portée est limitée des deux côtés : les requêtes ClickHouse sont limitées à la liste d’autorisation des tables, `query_log` et `text_log` étant refusés par le validateur quelle que soit la configuration, et l’accès à Kubernetes est limité séparément aux vues en lecture seule et aux logs des pods accordés par les Roles limités au namespace.
## Éléments nécessitant votre intervention
* **Sessions d'assistance.** Le dépannage interactif ne peut avoir lieu que dans une session que vous activez, limitée à 4 heures par défaut et à 24 heures maximum. La désactivation prend effet immédiatement. Consultez les [sessions d'assistance](/docs/fr/products/bring-your-own-cloud/connector/support-sessions).
* **Liste d'autorisation des opérateurs.** Chaque requête adressée à la passerelle doit inclure un jeton OIDC dont l'adresse e-mail attestée figure dans votre liste d'autorisation. Une liste d'autorisation vide interdit tout accès. Vous gérez cette liste ; consultez le [guide de configuration](/docs/fr/products/bring-your-own-cloud/connector/configuration).
* **Exposition de la passerelle.** La passerelle de session est désactivée tant que vous ne l'activez pas et n'est accessible que via une redirection de port, sauf si vous choisissez d'utiliser un Ingress. Sur une VM, chaque opérateur doit épingler l'empreinte de son certificat auto-signé avant que les commandes de session puissent communiquer avec lui.
* **Trafic réseau sortant.** Avec un CNI appliquant les règles, le connecteur n'a aucun accès sortant tant que vous n'avez pas ajouté les CIDR des points de terminaison à la liste d'autorisation de la NetworkPolicy du chart.
## Attribution des accès
* **Identité du déploiement.** Le nom commun du certificat client mTLS correspond à l’ID de votre org, avec un seul nom DNS associé à l’hôte de votre point de terminaison, afin que chaque connexion API puisse être attribuée à votre org. Le renouvellement est automatique et effectué par le démon ; aucun opérateur ne manipule les éléments de clé.
* **Intégrité des requêtes.** Chaque requête d’API inclut également une signature HMAC-SHA256 (`Authorization: HMAC-SHA256 AccessKey=..., Signature=..., Timestamp=...`) calculée à partir de la méthode, du chemin, de l’horodatage et du hash du corps, à l’aide de la paire de clés émise lors de l’inscription.
* **Identité de l’opérateur.** Les appels de la passerelle sont attribués à l’e-mail attesté par le jeton d’ID OIDC de l’opérateur, vérifié par rapport au JWKS de votre fournisseur d’identité ; un nom déclaré par l’utilisateur n’est jamais considéré comme fiable lorsqu’un jeton est disponible.
* **Piste d’audit.** Chaque appel à la passerelle et chaque commande de dépannage, qu’ils soient acceptés ou bloqués, sont ajoutés au journal d’audit NDJSON : les entrées de la passerelle incluent l’e-mail attesté de l’opérateur, les modifications de session locale de la VM incluent l’utilisateur hôte à l’origine de l’appel, et les commandes de session incluent l’identité de l’org transmise sur le canal authentifié. Consultez-le avec `clicklink clctl troubleshoot audit tail` ; voir la [référence de la CLI](/docs/fr/products/bring-your-own-cloud/connector/reference/cli).
## Paramètres par défaut de minimisation des données
* **`query_log` est exclue des scrapes par défaut.** Ses colonnes contiennent du SQL brut avec des valeurs littérales, qui peuvent inclure des données personnelles ou des secrets ; elle ne quitte donc pas votre périmètre, sauf si vous l'ajoutez délibérément.
* **L'outil troubleshooter lit uniquement les tables de la liste d'autorisation**, et le validateur refuse systématiquement `query_log` et `text_log`, de sorte que l'historique des requêtes n'est jamais accessible en lecture. La liste d'autorisation par défaut inclut `system.processes` (texte des requêtes en cours) ; restreignez la liste des tables autorisées pour les sessions (`troubleshooter.allowedTables` sur Kubernetes, `troubleshooter.allowed_tables` sur une VM) si ces informations doivent rester masquées pendant les sessions.
* **Toute la sortie du troubleshooter est expurgée** à l'aide de motifs intégrés pour les adresses IPv4 et IPv6, les jetons Bearer, les clés d'accès AWS, les e-mails, les JWT, les clés privées SSH et les informations d'identification des chaînes de connexion, ainsi que de tous les motifs que vous définissez. Le démon refuse de démarrer si le fichier de motifs n'est pas valide plutôt que de s'exécuter sans expurgation.
* **Les informations d'identification sont minimisées au repos.** Le SQL de provisionnement contient des hachages bcrypt, jamais de mots de passe en clair ; le jeton d'inscription n'est jamais écrit sur la ligne de commande, sur le disque ou dans les journaux ; les clés sont stockées dans des Kubernetes Secrets ou des fichiers avec le mode 0600.