Modèle de privilèges

Ce que le ClickHouse Connector peut et ne peut pas faire, précisément : identités, connexions sortantes, autorisations ClickHouse, RBAC Kubernetes, accès cloud, attribution et minimisation des données

Cette page constitue la référence de sécurité du ClickHouse Connector : ses identités, ses connexions, ses privilèges exacts, ses limites structurelles et la manière dont chaque action est attribuée. Pour comprendre comment ces éléments s’articulent, consultez l’architecture.

​

Identities

• Le certificat client mTLS du connector, dont le nom commun est votre organization ID, authentifie chaque démon auprès de votre connector endpoint. clicklink clctl instances create utilise le même certificat et la même clé HMAC lorsqu’il appelle l’endpoint.
• pcm_scraper et pcm_troubleshooter sont les ClickHouse users en lecture seule sous lesquels se connectent le scraper et le troubleshooter. L’executor, lui, n’a pas de ClickHouse user.
• Les ServiceAccounts du Troubleshooter, un par deployment provisionné, portent les vues Kubernetes en lecture seule utilisables lors d’une session d’assistance.
• pcm-executor est le ServiceAccount Kubernetes de l’executor pour le cycle de vie des services managés. Une ValidatingAdmissionPolicy restreint ses écritures aux namespaces de service.
• pcm-platform est l’identity de l’executor pour les mises à jour de plateforme. Votre commande clicklink clctl platform approve émet son jeton pour 2 heures et ne le renouvelle jamais ; entre deux approbations, l’executor n’a aucun accès en écriture à la couche plateforme.
• Le rôle IAM propre à chaque service (CH-S3-<service>-<region>-00-Role par défaut) est créé par clicklink clctl executor prepare avec vos identifiants. Sa portée se limite aux buckets de données et de sauvegarde de ce service, et seul le ServiceAccount Kubernetes de ce service lui est approuvé : ni l’executor ni ClickHouse ne peuvent donc l’assumer.
• Le profil d’instance de la VM EC2 du connector assume le rôle ECR puller en lecture seule de votre environnement pour l’accès direct à la plateforme, à la fois pour la connexion aux charts et pour les vérifications d’image. La CLI d’approbation emprunte le même chemin de profil d’instance ; les profils AWS du poste de travail ou les identifiants SSO ne s’y substituent pas. Les autres registries de charts ECR utilisent les identifiants AWS ambient. Les image pulls s’effectuent sur vos nodes sous leur propre rôle de pull. L’executor ne détient aucun identifiant pour vos buckets ni pour IAM et n’effectue aucun appel S3 ou IAM. Voir registry credentials.
• Vos propres identifiants appliquent chaque grant : le grant d’accès de l’executor lors de init --managed, les buckets et le rôle lors de prepare, le volet permissions de chaque mise à jour de plateforme lors de approve, et le nettoyage lors de teardown.

​

Fonctionnalités du connecteur

​

Connexions sortantes

Chaque connexion ouverte par le connecteur est initiée depuis l’intérieur de votre environnement. La liste complète :

Destination	Protocole	Objectif
Votre connector endpoint	HTTPS avec mTLS, chaque requête 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 ; depuis clicklink clctl, POST /v1/pcm/instances (soumettre une définition de service)
Votre connector endpoint	WebSocket sortant, /v1/commands/ws	Le canal de commandes du troubleshooter, conditionné par l’état de la session de support
Votre connector endpoint	WebSocket sortant, /v1/commands/ws/executor	Le canal de commandes de l’executor : commandes de cycle de vie des services managés et leurs résultats
Votre endpoint d’enrollment	HTTPS (enrollment token ou HMAC ; sans mTLS)	Utilisation du jeton et signature du certificat (/v1/pcm/cert/sign) au moment de l’installation
Vos clusters ClickHouse	Protocole natif ClickHouse	Requêtes en lecture seule en tant que pcm_scraper et pcm_troubleshooter, ainsi que l’instruction de vidage des logs du scraper (voir Autorisations ClickHouse) ; l’executor n’ouvre aucune connexion ClickHouse
Le Kubernetes API server	HTTPS	Lectures limitées au namespace et demandes de jetons ServiceAccount pour le scraper et le troubleshooter (les deux cibles) ; les écritures de l’executor dans les namespaces des services et, lors d’une mise à jour de plateforme approuvée, dans les namespaces de la plateforme ; lecture et mise à jour par nom exact du Secret mTLS propre au connecteur afin de conserver les certificats renouvelés (installations Kubernetes uniquement ; sur une VM, les renouvellements sont écrits dans ses fichiers TLS locaux)
Amazon ECR	HTTPS, le rôle de pull en lecture seule assumé via le profil d’instance de la VM EC2 du connecteur pour l’accès direct à la plateforme ; identifiants AWS ambiants pour les autres registries de charts ECR	Connexion au registry lorsqu’une synchronisation ou une création de plateforme récupère un chart depuis ECR ; DescribeImages pendant une mise à jour de plateforme pour confirmer l’existence des images
AWS STS	HTTPS, le profil d’instance de la VM EC2 du connecteur pour l’accès direct à la plateforme ; la chaîne d’identifiants AWS configurée pour les autres registries de charts ECR	Assume le rôle de pull en lecture seule pour la connexion aux charts de plateforme en accès direct et les vérifications d’images ; peut également fournir des identifiants pour d’autres connexions ECR. ECR et STS sont les seuls appels d’API cloud de l’executor
Un registry de conteneurs, depuis les nodes de votre cluster	HTTPS	Récupération des images pour les services managés et les composants de plateforme, via un rôle de pull en lecture seule que ClickHouse accorde aux rôles de nodes que vous avez enregistrés, ou depuis votre propre registry après avoir importé les images
Le JWKS endpoint de votre identity provider	HTTPS	Validation des jetons d’opérateur, uniquement lorsque la passerelle de sessions est activée

En entrée, chaque démon expose un unique port de santé local, qui sert également ses metrics Prometheus, ainsi que la passerelle de sessions optionnelle. L’API de commandes locale de l’executor n’écoute que sur l’interface de bouclage. Rien d’autre n’écoute. ClickHouse Cloud n’initie jamais de connexion vers votre environnement : il ne peut que répondre aux deux WebSockets sortants.

​

Autorisations ClickHouse

Le provisionnement crée un utilisateur en lecture seule par composant d’observation. 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. La ligne ALTER USER qui suit chaque CREATE USER effectue la rotation du hachage lors d’un --force. L’executor n’a pas de user et ne se connecte jamais à ClickHouse. 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>';
ALTER USER `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 nécessaire, car les requêtes de scrape enveloppent chaque table système dans clusterAllReplicas(). SYSTEM FLUSH LOGS est la seule autorisation de niveau système. Elle fait en sorte que les tables système *_log rendent persistantes les entrées déjà présentes dans leur tampon afin que les scrapes voient des données à jour ; elle ne permet ni de lire ni de modifier quoi que ce soit. ClickHouse n’accepte ce privilège qu’au niveau global et ne l’applique qu’aux tables de logs, 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>';
ALTER USER `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 ne sert qu’à un diagnostic. clicklink clctl preflight s’exécute avec les propres identifiants du connector et vérifie si l’instance stocke ses users de façon répliquée ou locale. 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 vérification preflight signale qu’elle est ignorée, tandis que tout le reste se poursuit.

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.

​

RBAC Kubernetes

​

Scraper et dépanneur

Le scraper et le dépanneur n’ont ni ClusterRole ni ClusterRoleBinding. Le chart crée des rôles limités à l’espace de noms dans l’espace de noms du connecteur, et chaque bundle d’accès par instance crée un rôle dans l’espace de noms ClickHouse ou de service de cette instance.

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
clickhouseclusters, backups (clickhouse.com)	get, list, watch	Uniquement pour le scraper, via le rôle par instance dans chaque espace de noms ClickHouse ou de service, pour la synchronisation du statut des services et des sauvegardes
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

​

Executor

En mode managé, clicklink clctl init --managed (ou clicklink clctl executor access grant --cluster suivi de apply --cluster) applique le grant de l’executor avec vos credentials. Ce grant se compose du ServiceAccount pcm-executor (dans le namespace du connector sur Kubernetes, dans clicklink-system pour une installation sur VM), d’un ClusterRole qui lui est associé et de la ValidatingAdmissionPolicy pcm-executor-prefix-guard.

Les verbes sont accordés à l’échelle du cluster, car RBAC ne permet pas d’exprimer un prefix de namespace. La politique d’admission refuse ensuite toute écriture de pcm-executor visant un namespace en dehors du prefix du service (ns- par défaut). Son namespace d’origine autorise trois écritures : le renouvellement de son propre token, le ConfigMap clicklink-instance-registry que lit le scraper et, sur Kubernetes, le certificat client renouvelé réécrit dans le Secret clicklink-mtls. La politique s’applique à ce seul ServiceAccount et utilise failurePolicy: Fail ainsi que validationActions: [Deny]. Le ClusterRoleBinding est appliqué en dernier, après la politique et son binding : ainsi, un grant partiellement appliqué laisse l’executor sans aucune permission plutôt qu’avec des permissions non protégées.

Sur une VM, clicklink clctl executor prepare applique également un bundle par service. Ce bundle se compose d’un ServiceAccount pcm-executor dans ns-<name>, d’un Role portant les mêmes familles de resources et d’un ClusterRole restreint à get et delete sur ce seul namespace. L’executor utilise ce bundle pour le service lorsqu’il est présent, et le grant à l’échelle du cluster sinon. Sur Kubernetes, le pod agit toujours en tant que ServiceAccount pcm-executor du namespace du connector.

Resources	Verbes	Utilité
clickhouseclusters (clickhouse.com)	get, list, watch, create, update, patch, delete	La définition du service telle que la restitue ClickHouse Cloud ; les redémarrages l’annotent, la suppression l’efface
backups (clickhouse.com)	get, list, watch, create, delete	Sauvegarde et suppression de sauvegarde
scalingoverrides (clickhouse.com)	get, create, update	Mise à l’échelle vers le nombre de réplicas demandé par ClickHouse Cloud
pods	get, delete	Redémarrage d’un pod unique
secrets	get, list, create, update, delete	Les Secrets de credentials du service
serviceaccounts	get, create, update, patch, delete	Le ServiceAccount du service, qui porte l’annotation du role IAM
services	get, list, create	Le répartiteur de charge interne du service, lorsqu’il est demandé
namespaces	get, create, update, delete	Création d’un namespace de service et suppression avec le service ; noms préfixés uniquement
roles, rolebindings (rbac.authorization.k8s.io)	get, create, update, patch	L’accès en lecture seule du scraper dans chaque namespace de service ; la prévention de l’escalation par Kubernetes limite ces éléments aux permissions que l’executor détient déjà. L’executor ne provisionne rien pour le troubleshooter ; voir sessions de support pour un service managé
serviceaccounts/token	create	Noms exacts uniquement : pcm-executor et le ServiceAccount du scraper, pour le renouvellement du token
secrets	get, update	Le Secret mTLS du connector uniquement, par nom exact, afin de persister le certificat client renouvelé. Installations Kubernetes uniquement, accordé par le Role du chart dans le namespace du connector
configmaps	get, update, patch, create	Le ConfigMap clicklink-instance-registry dans le namespace du connector. Installations Kubernetes uniquement, accordé par le Role du chart ; get, update et patch sont restreints par nom, et la politique d’admission confine create à ce nom

L’admission ne s’exécute pas sur get, list ou watch : les lectures de ces familles de resources par l’executor ne sont donc pas confinées au prefix.

​

Identity de la plateforme

clicklink clctl platform approve applique le volet permissions d’une mise à jour de la plateforme avec vos identifiants : Namespaces, CustomResourceDefinitions, ServiceAccounts, ClusterRoles et ClusterRoleBindings, Roles et RoleBindings, configurations de webhook et d’admission, PriorityClasses, ainsi que la StorageClass. Il applique ensuite le ServiceAccount pcm-platform, son ClusterRole, la ValidatingAdmissionPolicy pcm-platform-scope-guard et le binding, puis émet un jeton lié valable 2 heures.

Avec ce jeton, l’executor ne peut écrire que des deployments, services, configmaps, secrets, jobs et poddisruptionbudgets, et uniquement dans les namespaces de la plateforme autorisés par le scope guard. Il peut lire les pods, events, namespaces, serviceaccounts, les CustomResourceDefinitions, les objets RBAC, les configurations de webhook, les StorageClasses et les PriorityClasses afin de vérifier que le volet permissions est bien en place avant d’appliquer quoi que ce soit. Il ne détient jamais escalate, bind ni impersonate, n’écrit jamais de kind à portée cluster ni d’objet RBAC, et ne peut ni émettre ni renouveler son propre jeton. Le jeton n’autorise qu’un seul bundle : le digest que vous avez approuvé est enregistré sur le ServiceAccount, et l’executor refuse tous les autres.

​

Ce que le connector ne peut pas faire

• Aucune écriture sur les données ou l’état de ClickHouse. Les grants ci-dessus ne contiennent aucun INSERT, aucun DDL, ni aucun privilège de gestion des USER, de settings ou de contrôle des processus. Le seul grant de classe système, le SYSTEM FLUSH LOGS du scraper, se contente de faire persister dans les log tables ce qu’elles ont déjà en tampon. L’executor n’a aucun ClickHouse user. Aucun component ne peut modifier de données, de schémas, d’utilisateurs ou de settings via ClickHouse.
• Aucun exec. Aucun RBAC ne contient pods/exec ; aucun component ne peut exécuter de commandes dans vos pods.
• Aucune écriture en dehors des namespaces de service et de plateforme. Le scraper et le troubleshooter ne détiennent ni delete ni patch. Leurs seules mutations sont l’update sur le nom exact du Secret mTLS propre au connector et le create sur serviceaccounts/token, qui génère des jetons à courte durée de vie pour leurs propres ServiceAccounts sans modifier aucun objet stocké. L’admission refuse les écritures de l’executor en dehors du préfixe de service, et ses écritures sur la plateforme n’existent que tant qu’un jeton que vous avez généré reste valide.
• Aucune permission d’accorder des permissions. Vos identifiants appliquent les Namespaces, CRD, ServiceAccounts, RBAC, configurations de webhook et d’admission, PriorityClasses et la StorageClass de la plateforme lors de l’approve. L’identity de plateforme de l’executor ne peut pas escalader ses droits, ni effectuer de binding, ni usurper une identity. À l’intérieur d’un namespace de service, l’executor ne peut créer que des Roles accordant des permissions qu’il détient déjà.
• Aucun identifiant pour vos buckets ou votre IAM. clicklink clctl executor prepare crée les buckets et le service role, et clicklink clctl executor teardown les supprime, dans les deux cas avec vos identifiants. Ce role n’est assumable que par les pods de ce service. Pour l’accès direct à la plateforme, l’executor utilise le profil d’instance de la VM EC2 du connector pour assumer le role de pull ECR en lecture seule, à la fois pour la connexion aux charts et pour les vérifications d’image. Les autres registres de charts ECR utilisent les identifiants AWS ambiants ; voir identities. Ses seuls appels d’API cloud vont vers ECR et STS ; il ne peut ni lire ni supprimer vos données.
• Aucune connaissance du mot de passe de votre default user. clicklink clctl executor prepare le génère de votre côté et l’affiche une seule fois (ou clicklink clctl instances create s’en charge, si vous passez les entrées sous forme d’options). Seuls ses hachages sont transmis : ni le connector ni ClickHouse Cloud ne peuvent donc le récupérer.
• Rien en entrée. ClickHouse Cloud n’ouvre jamais de connexion vers votre environnement. Les seuls chemins de commande sont les deux WebSockets sortants. Le troubleshooter refuse toute commande, sauf si une session d’assistance que vous avez activée est en cours. L’executor n’accepte des commandes de cycle de vie que pour les services dont vous avez confié la gestion à ClickHouse, dans les limites des scopes ci-dessus. Même pendant une session, le troubleshooter est borné des deux côtés. Les requêtes ClickHouse sont limitées à la liste d’autorisation de tables, qui refuse query_log et text_log : ils ne sont donc jamais accordés. L’accès à Kubernetes est limité aux vues en lecture seule et aux logs de pods accordés par les Roles délimités au namespace.

​

Éléments nécessitant votre intervention

• Activation du mode managé. L’executor s’exécute, et son grant Kubernetes existe, uniquement après que vous avez activé le mode managé lors de l’init ; le grant est appliqué avec les droits d’administrateur du cluster. Consultez services managés.
• Création d’un service. clicklink clctl executor prepare s’exécute avec vos AWS identifiants pour créer les buckets et le rôle IAM, et clicklink clctl instances create soumet la définition. ClickHouse Cloud ne peut pas créer de service dans votre cluster sans ces deux étapes. Consultez créer un service.
• Mises à jour de la plateforme. Chaque mise à jour des composants de la plateforme n’est appliquée qu’après que vous avez exécuté clicklink clctl platform approve pour ce bundle précis ; le jeton ainsi généré expire au bout de 2 heures et n’est jamais renouvelé. Consultez mises à jour de la plateforme.
• Nettoyage après une suppression. La suppression d’un service ne retire que ses ressources Kubernetes. clicklink clctl executor teardown, exécuté avec vos identifiants, supprime le rôle IAM et, uniquement avec des drapeaux explicites, les données et les backups. Consultez supprimer un service.
• Sessions de support. 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 de support.
• 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é, ou le vérifier à l’aide d’un CA bundle transmis via --gateway-ca, avant que les commandes de session communiquent avec lui.
• Trafic réseau sortant. Avec un CNI appliquant les règles, aucun démon n’atteint votre endpoint de connector tant que vous n’avez pas listé ses CIDR dans networkPolicy.allowEgressCIDRs. L’executor a également besoin des CIDR du Kubernetes API server (networkPolicy.apiserverCIDRs), qu’init --managed déduit du VPC du cluster. Si les charts de la plateforme proviennent d’Amazon ECR, ajoutez également les plages ECR et STS.

​

Comment l’accès est attribué

• Identity de déploiement. Le common name du certificat client mTLS correspond à votre ID d’org, et son unique DNS name est lié à l’hôte de votre endpoint. Chaque connexion à l’API est ainsi attribuable à votre org. Le renouvellement est automatique et effectué dans le démon ; aucun opérateur ne manipule le matériel cryptographique.
• Intégrité des requêtes. Chaque requête d’API porte également une signature HMAC-SHA256 (Authorization: HMAC-SHA256 AccessKey=..., Signature=..., Timestamp=...) couvrant la méthode, le path, le timestamp et le hash du corps, à l’aide de la paire de clés émise lors de l’enrollment.
• Identity de l’opérateur. Les appels au gateway sont attribués à l’e-mail attesté par l’OIDC ID token de l’opérateur, vérifié auprès du JWKS de votre identity provider. Un nom auto-déclaré n’est jamais considéré comme fiable dès lors qu’un jeton est disponible.
• Commandes de cycle de vie. L’executor enregistre chaque commande qu’il reçoit dans son magasin local, avec son origine (ClickHouse Cloud ou un appel local clicklink clctl), son étape et son résultat. Il renvoie le résultat sur le canal de commandes. Consultez l’enregistrement avec clicklink clctl commands list et clicklink clctl commands get ; voir la référence CLI.
• Approbations de la plateforme. Le digest du bundle que vous avez approuvé est enregistré sur le ServiceAccount pcm-platform. Chaque objet appliqué par vos identifiants porte un hash de contenu, que l’executor vérifie avant toute écriture. Tout bundle présentant un autre digest est refusé.
• Piste d’audit. Chaque commande de session, acceptée ou bloquée, est ajoutée à l’audit log NDJSON avec l’identity de l’org issue du canal de commandes. Les appels au gateway sont journalisés sous forme de lignes clctl.gateway structurées dans le log du troubleshooter, avec l’e-mail attesté de l’opérateur. Les modifications de session locales sur la VM enregistrent l’utilisateur hôte dans session.json. Consultez l’audit log avec clicklink clctl troubleshoot audit tail ; voir la référence CLI.

​

Valeurs par défaut de minimisation des données

• query_log est exclu des scrapes par défaut. Ses colonnes contiennent du SQL brut avec des valeurs littérales, susceptibles de comporter des données personnelles ou des secrets. Il ne franchit pas votre périmètre tant que vous ne l’ajoutez pas.
• Le troubleshooter ne lit que les tables figurant dans la liste d’autorisation. query_log et text_log sont refusés dans la configuration même de la liste d’autorisation : ils ne sont donc jamais accordés et l’historique des requêtes n’est jamais lisible. La liste d’autorisation par défaut inclut toutefois system.processes (texte des requêtes en cours d’exécution) ; réduisez-la (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 des patterns intégrés, auxquels s’ajoutent ceux que vous définissez. Les patterns intégrés couvrent les adresses IPv4 et IPv6, les jetons bearer, les access keys AWS, les adresses e-mail, les JWT, les private keys SSH et les identifiants présents dans les chaînes de connexion. Face à un fichier de patterns invalide, le démon refuse de démarrer plutôt que de s’exécuter sans expurgation.
• Le status d’un service managé se limite aux métadonnées. L’executor rapporte l’état d’un service, le nombre de répliques, les versions et le résultat des commandes. Il ne lit jamais les tables ni les buckets du service.
• Les identifiants sont réduits au strict minimum at rest. Le SQL de provisioning contient des hashes bcrypt, jamais des mots de passe en plaintext. Le mot de passe du default user d’un service managé n’est affiché qu’une seule fois et n’en sort que sous forme de hashes. Le jeton d’enrollment n’est jamais écrit sur la ligne de commande, sur disque ni dans les logs. Les clés résident dans des Kubernetes Secrets ou dans des fichiers en mode 0600.