Prérequis système
La version self-hosted de GitGuardian est déployée en tant qu'application Kubernetes. Nous recommandons d'installer GitGuardian sur un existing cluster à l'aide de Helm. Vous trouverez plus d'informations sur la façon de choisir votre méthode d'installation sur notre page dédiée.
Prérequis matériels
Architecture
GitGuardian Platform self-hosted prend en charge les architectures CPU suivantes :
- AMD64 : entièrement prise en charge dans toutes les méthodes d'installation
- ARM64 : prise en charge uniquement pour les installations basées sur Helm (Existing Cluster avec Helm). Les installations KOTS et Embedded Cluster sont uniquement AMD64
Toutes les images de conteneurs sont publiées sous forme de manifestes multi-architecture (multi-arch). Vous n'avez pas besoin de spécifier un flag Docker --platform ; la variante d'image appropriée sera sélectionnée automatiquement en fonction de l'architecture du nœud.
Installation sur un cluster Kubernetes existant
Pour les recommandations de dimensionnement, consultez notre page Scaling GitGuardian.
Installation sur un cluster Kubernetes embarqué
L'embedded cluster est une installation mono-nœud qui exécute la pile complète GitGuardian, y compris les PostgreSQL et Redis embarqués, sur une seule machine virtuelle. Comme tout s'exécute sur un seul nœud, vous devez dimensionner la machine en fonction du volume que vous prévoyez de scanner pendant votre essai ou votre Proof of Concept (PoC).
Les niveaux suivants constituent un point de départ pour les déploiements PoC. Ils reflètent les profils Small / Medium / Large de la page Scaling (y compris les PostgreSQL et Redis embarqués), regroupés sur un seul nœud avec un nombre réduit de réplicas de workers adapté à un PoC :
| Niveau | Profil Scaling comparable | CPU | Mémoire | Espace disque racine |
|---|---|---|---|---|
| Small | Small (jusqu'à ~2 000 dépôts) | 16 cœurs | 64 Go | 400 Go |
| Medium | Medium (jusqu'à ~10 000 dépôts) | 32 cœurs | 128 Go | 600 Go |
| Large | Large (jusqu'à ~40 000 dépôts, ou des sources de documents telles que Slack, MS Teams, SharePoint, OneDrive) | 64 cœurs | 256 Go | 1 To |
L'embedded cluster ne peut pas évoluer horizontalement et convient mieux aux PoC de petite à moyenne taille. Si vous avez besoin de scanner un grand volume de données (nombre élevé de dépôts, ou sources de documents telles que SharePoint et OneDrive, qui nécessitent un stockage éphémère important), nous recommandons plutôt une installation sur un existing cluster. Consultez la page Scaling pour un dimensionnement détaillé au niveau des composants.
Cette installation comporte certaines limitations :
- La prise en charge multi-nœuds est en bêta
- La modification des noms d'hôtes des nœuds n'est pas prise en charge
- Les mises à jour automatiques ne sont pas prises en charge
- Les bundles de support de plus de 100 Mo dans l'Admin Console
- L'installation sur des images OS renforcées STIG et CIS n'est pas prise en charge
Plus de détails sur Replicated.
Prérequis logiciels
Kubernetes pour les clusters existants
Pour les installations sur Existing Cluster, GitGuardian prend en charge les versions Kubernetes suivantes : 1.30 à 1.35.
GitGuardian a besoin d'un namespace dédié.
Si vous prévoyez d'installer GitGuardian sur un cluster OpenShift, veuillez consulter les directives détaillées pour l'installation sur un cluster OpenShift.
GCP Marketplace
Le déploiement GCP Marketplace utilise Helm, offrant tous les avantages des installations basées sur Helm avec une facturation consolidée via votre compte GCP. Le déploiement initial se fait via la console GCP, mais les mises à niveau sont effectuées directement avec Helm. Les mêmes prérequis Helm ci-dessous s'appliquent.
Pour les instructions de configuration de la base de données, consultez Cloud SQL : PostgreSQL sur GCP et Memorystore : Redis sur GCP. Pour les détails de déploiement spécifiques à GCP, consultez le guide de déploiement GCP Marketplace.
Helm
La méthode d'installation Existing Cluster avec Helm nécessite Helm version 3.13+.
- La version 3.18.0 de Helm n'est pas prise en charge en raison d'un bug dans Helm, qui est corrigé dans les versions 3.18.1 et ultérieures.
Utilisez une version de Helm alignée avec votre version de Kubernetes pour éviter les problèmes de compatibilité. Consultez la politique de prise en charge des versions Helm pour la liste des versions compatibles.
La conformité FIPS 140-3 (Federal Information Processing Standards) est disponible exclusivement pour les installations basées sur Helm. Si vous avez besoin de modules cryptographiques conformes à FIPS 140-3 pour la conformité réglementaire, vous devez choisir la méthode d'installation Helm et définir global.fips.enabled: true dans vos valeurs Helm. Pour les installations airgap, des étapes supplémentaires de renommage d'images sont nécessaires. Pour plus de détails, consultez la page Recommandations de sécurité.
L'installation Helm prend également en charge certaines ressources personnalisées facultatives. Si vous souhaitez les utiliser, vous devez disposer des contrôleurs et opérateurs appropriés :
- IngressController : nous fournissons un exemple de contrôleur
ingress. Vous pouvez également configurer n'importe quelle autre classe d'Ingress Controller. Consultez notre rubrique Configuration Ingress. - Istio : nous prenons en charge Istio pour le routage du trafic et le chiffrement de bout en bout (sidecars).
- Prometheus Operator : nous pouvons déployer des ServiceMonitors pour exposer les métriques d'observabilité de notre application.
- Vault : nous permettons l'utilisation de Vault via un SecretStore external-secrets.
- CertManager : nous permettons la gestion des certificats via un ClusterIssuer cert-manager.
PostgreSQL
GitGuardian prend actuellement en charge PostgreSQL 15 à 18, PostgreSQL 17 étant la version recommandée.
Les versions 13 et 14 de PostgreSQL ne sont plus prises en charge à partir de la version 2025.1.0. Nous recommandons vivement de passer à PostgreSQL 16+ dès que possible.
Vous devrez installer les extensions suivantes :
| Extension | Utilisation | Version minimale |
|---|---|---|
| btree_gin | Fournit une capacité GIN aux types de données de base (int, timestamp, ...) afin que toutes les colonnes puissent être utilisées dans des index GIN | 1.3 |
| pg_trgm | Fournit des fonctions et opérateurs permettant une recherche rapide de chaînes similaires à l'aide d'index GiST et GIN | 1.5 |
| plpgsql | Permet la création de procédures stockées et de triggers à l'aide du langage de programmation procédural PL/pgSQL | 1.0 |
| pgvector | Fournit une recherche de similarité vectorielle à l'aide de nouveaux types, fonctions, opérateurs et index | 0.7.0 (0.8.0 recommandé) |
Selon votre installation, certaines extensions peuvent déjà être disponibles. C'est le cas pour les principales bases de données PostgreSQL gérées dans le cloud. Sinon, vous devrez peut-être effectuer quelques actions supplémentaires :
- L'extension plpgsql est installée par défaut.
- Les extensions btree_gin et pg_trgm sont disponibles dans le paquet postgresql-contrib.
- L'extension pgvector est disponible sous forme de paquet pour les OS basés sur Debian, Ubuntu ou Yum. Si vous utilisez Docker, vous pouvez utiliser l'image docker disponible. Vous pouvez également l'installer via le client pgxn.
Pour rendre ces extensions disponibles dans votre base de données, vous devez exécuter les commandes suivantes en étant connecté en tant que superuser sur l'instance de base de données :
CREATE EXTENSION IF NOT EXISTS btree_gin;
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS plpgsql;
CREATE EXTENSION IF NOT EXISTS vector;
Pour des conseils supplémentaires sur les bases de données, consultez Configurer votre base de données.
Pour les recommandations de dimensionnement, consultez notre page Scaling GitGuardian.
Pour les déploiements à grande échelle, nous recommandons d'utiliser une base de données PostgreSQL externe et de tirer parti des mécanismes de réplication de votre fournisseur pour la haute disponibilité.
Nous recommandons d'éviter les connection poolers (tels que PgBouncer) avec GitGuardian, car ils peuvent provoquer un comportement inattendu ou impacter les performances. Les connexions directes à PostgreSQL sont recommandées.
Redis
GitGuardian prend actuellement en charge Redis 6 à 8, Redis 7 étant la version recommandée. De plus, nous prenons en charge Valkey (un fork compatible Redis de Redis 7.2) comme implémentation Redis alternative.
Comment GitGuardian utilise Redis : Redis sert de broker de messages pour le traitement distribué des tâches (Celery), met en cache les données fréquemment consultées et stocke les résultats temporaires de scan.
Pour les déploiements à grande échelle, nous recommandons vivement d'utiliser un Redis externe. Pour les recommandations de dimensionnement, consultez notre page Scaling GitGuardian.
Pour la haute disponibilité, nous prenons en charge Redis Sentinel pour les Existing cluster. Redis Cluster n'est pas pris en charge.
L'instance Redis doit être dédiée exclusivement à l'application GitGuardian. Le partage de l'instance avec d'autres applications peut entraîner un comportement inattendu, une corruption des données et des problèmes de performance.
La commande FLUSHDB doit être activée sur l'instance Redis, car elle est essentielle au bon fonctionnement de certaines fonctionnalités de notre application. Assurez-vous que cette commande n'est pas masquée dans votre configuration Redis (par exemple, rename-command "FLUSHDB" "").
Sachez que si Redis a une politique d'éviction définie (telle que noeviction, allkeys-lru, etc.), et que la politique est définie sur noeviction, Redis n'évincera aucune donnée. Cela peut faire échouer les nouvelles écritures lorsque la limite de mémoire est atteinte, alors choisissez votre politique d'éviction avec soin.
KOTS
La méthode d'installation « Existing cluster with KOTS » utilise KOTS. Nous utilisons la dernière version de KOTS disponible pour valider nos versions. Vous pouvez trouver la compatibilité des versions sur la page de compatibilité KOTS.
L'Admin Console KOTS aura le contrôle total de ce namespace. Le rôle suivant doit être créé :
Name: kotsadm-role
Labels: kots.io/kotsadm=true
Annotations: <none>
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
*.* [] [] [*]
Nous utilisons les objets suivants :
- PersistentVolumeClaims : nous utilisons des persistent volume claims pour KOTS, les workers et les bases de données embarquées.
- IngressController : nous pouvons fournir un ingress par défaut, un Ingress Controller est nécessaire pour le gérer.
Vous devez disposer des contrôleurs et opérateurs appropriés pour les gérer.
Kubernetes et OS pour les clusters embarqués
Pour les installations sur cluster Kubernetes embarqué, veuillez noter que ces configurations sont principalement destinées à des fins d'essai ou de Proof of Concept (PoC) et ne sont pas recommandées pour une utilisation en production.
Kubernetes
Pour les installations sur embedded cluster (instances installées en 2025 ou après), Kubernetes est mis à niveau automatiquement lors de la mise à jour de l'application GitGuardian via l'Admin Console KOTS.
Pour les installations legacy sur embedded cluster (kURL) (instances installées en 2024 ou avant), suivez la procédure de mise à niveau pour mettre à jour votre version de Kubernetes.
Système d'exploitation
Assurez-vous de respecter les prérequis système Replicated et Embedded Cluster.
Nous recommandons vivement d'appliquer les derniers correctifs disponibles pour votre distribution de système d'exploitation avant de commencer l'installation.
ClickHouse
Certaines fonctionnalités nécessitent ClickHouse, un composant in-cluster facultatif livré dans le cadre du Helm chart GitGuardian. Il nécessite des volumes persistants locaux et un stockage objet (compatible S3, Azure Blob Storage ou GCS) que vous fournissez : consultez ClickHouse storage et Dimensionnement et durcissement.
Prérequis relatifs au nom de domaine
Vous aurez besoin d'un nom de domaine complet (FQDN) pour installer l'application (ex : gitguardian.mycorp.local). Cela ne peut pas être une adresse IP.
Vous aurez également besoin d'un certificat TLS pour l'accès HTTPS ou vous pouvez utiliser les certificats auto-signés par défaut.
