ClickHouse

GitGuardian utilise ClickHouse, une base de données open-source orientée colonnes, pour alimenter les fonctionnalités qui nécessitent une analyse rapide sur de grands volumes de données (par exemple, l'analyse des occurrences de secrets sur les machines et les endpoints). PostgreSQL reste le datastore principal pour le reste de l'application ; ClickHouse n'intervient que pour les fonctionnalités spécifiques qui en ont besoin.

Obligatoire à partir de 2027.1

À partir de la version 2027.1.0, ClickHouse et son backend de stockage d'objets deviennent obligatoires pour tout déploiement Self-Hosted. Consultez la notice client pour savoir ce qui change et comment vous préparer.

Modèle de déploiement

ClickHouse s'exécute en tant que composant stateful dédié, au sein du cluster, et repose sur un stockage d'objets externe (compatible S3, Azure Blob Storage ou Google Cloud Storage) pour un stockage de données durable. Il ne s'agit pas d'une base de données entièrement gérée en externe comme PostgreSQL ou Redis. Consultez Stockage ClickHouse pour plus de détails.

Topologie par défaut

ClickHouse est déployé en tant que nœud unique. C'est l'option la plus simple et la plus légère, et elle est suffisante pour la grande majorité des déploiements, bien qu'elle ne soit pas hautement disponible : il n'y a pas d'autre réplique vers laquelle basculer.

Version prise en charge

GitGuardian fige la version de ClickHouse livrée avec chaque release à la même version que celle exécutée par notre offre SaaS, et la valide avec notre suite de tests avant la release. N'essayez pas d'exécuter une version de ClickHouse différente de celle livrée avec votre release.

Stockage

ClickHouse répartit son stockage en trois parties : des volumes locaux de métadonnées et de cache du système de fichiers, ainsi qu'un stockage d'objets contenant les données réelles des tables, où réside l'essentiel de l'empreinte de stockage et où clickhouse-backup écrit lors des sauvegardes.

Consultez Stockage ClickHouse pour les volumes locaux et la configuration du stockage d'objets spécifique à chaque fournisseur, Dimensionnement et durcissement pour le dimensionnement matériel, Sauvegarde et restauration pour le runbook de sauvegarde, et Surveillance et alerte pour détecter une sauvegarde en échec que la santé du pod ne vous montrera pas.

Configuration requise

Un déploiement ClickHouse prêt pour la production nécessite que tous les éléments suivants soient configurés :

Quoi configurer	Détails	Où
Dimensionnement du calcul et durcissement	Ressources des nœuds et des instances, planification, stabilité des nœuds	Dimensionnement et durcissement
Identifiants ClickHouse	Mot de passe de l'instance	Prérequis
Configuration du stockage d'objets	Backend S3 / Azure Blob / GCS, authentification du disque	Stockage → Configuration
Configuration des volumes au sein du cluster	Volumes de métadonnées et de cache, storage class	Stockage → Volumes locaux
Configuration de la sauvegarde	Bucket de destination, secret d'identifiants, planification et rétention	Sauvegarde et restauration

Prérequis

Avant l'installation, le mot de passe admin de ClickHouse et le mot de passe de l'API locale du sidecar de sauvegarde doivent être transmis via un secret Kubernetes plutôt que définis directement dans les values, selon le même modèle utilisé partout dans GitGuardian Self-Hosted. Il peut être créé directement ou synchronisé depuis votre propre magasin de secrets. Consultez Gestion des informations sensibles avec Helm pour savoir comment le renseigner.

Si vous le créez directement :

kubectl create secret generic clickhouse-credentials \
  --namespace <namespace> \
  --from-literal=admin-password=<a-strong-password> \
  --from-literal=api-password=<a-strong-password> \
  --from-literal=api-username=<a-username>

Les trois clés sont requises : n'en renommez et n'en omettez aucune

clickhouse-credentials, admin-password, api-password et api-username sont câblés dans les valeurs par défaut du chart sous ces noms exacts : admin-password via clickhouse-server.auth.existingSecret/existingSecretKey (GitGuardian dérive son propre CLICKHOUSE_PASSWORD du même secret), et api-password/api-username sont consommés directement par le sidecar de sauvegarde et son ServiceMonitor. Omettre ou renommer l'un des trois casse l'authentification propre à ClickHouse, le sidecar de sauvegarde ou la connexion de GitGuardian à celui-ci, à moins que vous ne remplaciez également les valeurs correspondantes.

Une fois le secret en place, activez ClickHouse lui-même :

clickhouse:
  enabled: true

Cela seul ne suffit pas pour un déploiement fonctionnel : le backend de stockage d'objets de ClickHouse n'a pas de valeur par défaut et doit être configuré pour votre fournisseur (voir Stockage ClickHouse), et la destination de sauvegarde nécessite la même chose avant que les sauvegardes puissent s'exécuter (voir Sauvegarde et restauration). Suivez ces deux pages avant de considérer ClickHouse comme installé.