> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-revert-104359-revert-104251-parquet-single.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # 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 export const Image = ({img, alt, size = "lg", background}) => { const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg"; const backgroundColor = background === "white" ? "white" : background === "black" ? "rgb(31 31 28)" : undefined; return
{alt}
; }; export const PrivatePreviewBadge = () => { return
{'Aperçu privé'}
; }; 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](/fr/products/bring-your-own-cloud/connector/architecture).

Identities

Modèle d’identity du ClickHouse Connector * **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---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](/fr/products/bring-your-own-cloud/connector/platform-updates#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](#clickhouse-grants)) ; 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 : ```sql theme={null} CREATE USER IF NOT EXISTS `pcm_scraper` IDENTIFIED WITH bcrypt_hash BY ''; ALTER USER `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 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. ```sql theme={null} CREATE USER IF NOT EXISTS `pcm_troubleshooter` IDENTIFIED WITH bcrypt_hash BY ''; ALTER USER `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 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_`) 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-`, 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é](/fr/products/bring-your-own-cloud/connector/managed-services#support-sessions) | | `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](#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](/fr/products/bring-your-own-cloud/connector/managed-services#enable-managed-mode). * **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](/fr/products/bring-your-own-cloud/connector/managed-services#create-a-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](/fr/products/bring-your-own-cloud/connector/platform-updates#approve-a-platform-update). * **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](/fr/products/bring-your-own-cloud/connector/managed-services#delete-a-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](/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](/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é, 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](/fr/products/bring-your-own-cloud/connector/reference/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](/fr/products/bring-your-own-cloud/connector/reference/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.