ClickHouse

Cette version du connecteur utilise l’interface HTTPS de ClickHouse Cloud, avec un hôte, un port, un utilisateur et un mot de passe. Il ne s’agit pas des identifiants de connexion à la console ClickHouse Cloud.

Préparer l’utilisateur ClickHouseCopier le lien de la section

Le responsable du service crée un utilisateur SQL dédié et lui accorde la lecture des seules tables nécessaires. Il doit également définir un profil de lecture et des limites de ressources adaptées au service.

Exemple à adapter par ce responsable : analytics.weekly_sales doit déjà exister. Remplacez le mot de passe par une valeur unique.

CREATE SETTINGS PROFILE persyst_readonly
SETTINGS readonly = 1, max_execution_time = 30, max_rows_to_read = 10000000;
CREATE USER persyst_reader
IDENTIFIED WITH sha256_password BY '<MOT_DE_PASSE_UNIQUE>'
SETTINGS PROFILE persyst_readonly;
GRANT SELECT ON analytics.weekly_sales TO persyst_reader;
GRANT SELECT(role_name, user_name) ON system.role_grants TO persyst_reader;
GRANT SELECT(database, table, column_names, access_type, user_name, role_name)
ON system.grants TO persyst_reader;

Les limites chiffrées ci-dessus sont des exemples à adapter à votre charge. Les deux droits sur les tables système permettent à Persyst de découvrir les colonnes que cet utilisateur peut lire. Ils exposent des métadonnées de droits : faites valider cette visibilité par le responsable du service. Ils n’accordent pas la lecture des données métier.

Les quotas et limites d’exécution sont à configurer côté ClickHouse selon votre charge. Ajoutez chaque autre table explicitement aux droits de cet utilisateur.

Retrouver l’adresse du serviceCopier le lien de la section

Depuis la console ClickHouse Cloud, ouvrez Connect sur le service concerné et récupérez l’hôte de connexion HTTPS. Le port proposé par défaut dans Persyst est 8443. Utilisez le port HTTPS fourni par votre service, pas le port du protocole natif.

Le service doit accepter les connexions réseau depuis Persyst. Faites confirmer les règles réseau par le responsable ClickHouse.

Connecter le service dans PersystCopier le lien de la section

1. Dans Sources de données → Ajouter une source, choisissez ClickHouse.
2. Donnez un nom à la connexion ; renseignez l’hôte, le port HTTPS, l’utilisateur SQL et le mot de passe.
3. Testez la connexion et créez le connecteur.
4. Sélectionnez les tables à rendre disponibles, puis enregistrez.
5. Dans Gestion des accès, attribuez ces tables et les outils aux équipes ou membres concernés.

Il n’y a pas de champ de base à renseigner dans ce formulaire : la découverte peut afficher les tables de plusieurs bases accessibles à l’utilisateur SQL. Le choix des tables et leurs droits restent nécessaires.

Vérifier et maintenir l’accèsCopier le lien de la section

Un membre autorisé peut demander à son assistant de décrire une table sélectionnée, puis d’y calculer un agrégat. Le connecteur expose des lectures SQL sur les tables accordées.

Utilisez Modifier les identifiants pour changer l’utilisateur ou son mot de passe. Lors d’une modification, un mot de passe laissé vide conserve le secret existant. Actualisez les tables après une évolution des droits côté ClickHouse.

Prompt pour préparer l’accès en lecture seule

Copiez ce prompt dans l’assistant utilisé par votre responsable de base. Il reprend les consignes du guide d’installation : classement des tables, vues filtrées et compte dédié. Faites relire le SQL proposé sur votre schéma réel avant de l’exécuter. Les identifiants restent hors de la conversation.

You are helping prepare a ClickHouse Cloud service for Persyst.
Inspect schema metadata first; do not read production rows unnecessarily.
Persyst uses HTTPS/TLS with a host, HTTPS port (default 8443), SQL username
and password, not a Cloud console login, OAuth token or SDK/API key.

Classify every relevant table as safe, sensitive, or excluded.
Grant safe tables directly. For sensitive tables, create explicit-column
views of approved columns/rows and do not grant the base tables.
Check the view security model for this ClickHouse version so the reader
can use the view without gaining direct access to the sensitive source.
Never use SELECT * in an approved view.

Exclude secrets, credentials, hashes, tokens, keys and OTP/MFA data.
Exclude personal data by default: names, emails, phone/address details,
national/financial identifiers, IP/device identifiers, precise location
and unredacted free text. Opaque IDs are not automatically anonymous.

Create a dedicated user, never an admin/default user, and a SETTINGS
PROFILE with readonly = 1 plus workload-appropriate max_execution_time,
max_rows_to_read and other server-side resource limits.
Grant SELECT only on approved tables/views and the discovery metadata:
GRANT SELECT(role_name, user_name) ON system.role_grants TO <reader>;
GRANT SELECT(database, table, column_names, access_type, user_name, role_name)
ON system.grants TO <reader>;
Persyst reads these grants to discover permitted columns. They expose grant
metadata: review this visibility with the service owner. Do not grant
SELECT on all system tables or all business databases as a shortcut.

Output: classification and exclusions; explicit-column view SQL; settings
profile and dedicated user SQL; minimal grants; verification as the reader
(approved reads and write rejection without modifying real data); and
non-secret host, HTTPS port and username for the Persyst form.
Have the owner validate network access. Use password placeholders only.
Generate/store the password locally and enter it directly in Persyst;
never print it or paste it into this chat. Prepare SQL for review before
applying account or permission changes.

Références : création d’un utilisateur ClickHouse, permissions et limites pour les assistants.

Profils de paramètres ClickHouse.