Modèle de privilèges

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.

Voici la liste complète des connexions établies par le connecteur. Elles proviennent toutes de votre environnement.

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.

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 :

CREATE USER IF NOT EXISTS `pcm_scraper` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';

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.

CREATE USER IF NOT EXISTS `pcm_troubleshooter` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';

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_<suffix>) et disposent des mêmes ensembles d’autorisations.

Le chart crée uniquement des rôles limités à l’espace de noms ; aucun ClusterRole ni ClusterRoleBinding n’est créé.

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

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

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

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