Configuration système requise
La version Self-Hosted de GitGuardian est déployée comme une application Kubernetes. Nous recommandons d'installer GitGuardian sur un cluster existant en utilisant Helm. Vous trouverez plus d'informations sur le choix de votre méthode d'installation sur notre page dédiée.
Exigences matérielles
Architecture
GitGuardian Platform Self-Hosted prend en charge les architectures CPU suivantes :
- AMD64 : entièrement pris en charge par toutes les méthodes d'installation
- ARM64 : pris en charge uniquement pour les installations basées sur Helm (cluster existant 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, reportez-vous à notre page Scaling GitGuardian.
Installation sur un cluster Kubernetes embarqué
Le cluster embarqué est une installation mono-nœud qui exécute la pile complète de GitGuardian, y compris les bases PostgreSQL et Redis embarquées, sur une seule machine virtuelle. Étant donné que 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 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), consolidé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 sources documentaires telles que Slack, MS Teams, SharePoint, OneDrive) | 64 cœurs | 256 Go | 1 To |
Le cluster embarqué ne peut pas être mis à l'échelle horizontalement et convient mieux aux PoC de petite à moyenne taille. Si vous devez scanner un grand volume de données (nombre élevé de dépôts, ou sources documentaires telles que SharePoint et OneDrive, qui nécessitent un stockage éphémère important), nous recommandons plutôt une installation sur cluster existant. Consultez la page Scaling pour un dimensionnement détaillé au niveau des composants.
Cette installation présente certaines limitations :
- Le support multi-nœuds est en bêta
- Le changement des noms d'hôte de nœuds n'est pas pris en charge
- Les mises à jour automatiques ne sont pas prises en charge
- Bundles de support de plus de 100 Mo dans l'Admin Console
- L'installation sur des images OS durcies STIG et CIS n'est pas prise en charge
Plus de détails sur Replicated.
Exigences logicielles
Kubernetes pour les clusters existants
Pour les installations sur cluster existant, GitGuardian prend en charge les versions de 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 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 s'effectue via la console GCP, mais les mises à niveau sont effectuées directement avec Helm. Les mêmes exigences 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 Cluster existant avec Helm nécessite Helm version 3.13+.
- Helm version 3.18.0 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 qui s'aligne avec votre version de Kubernetes pour éviter les problèmes de compatibilité. Reportez-vous à la politique de support 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'image sont requises. 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 toute autre classe 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é sur notre application.
- Vault : nous autorisons l'utilisation de Vault via le SecretStore external-secrets.
- CertManager : nous autorisons la gestion des certificats via le ClusterIssuer cert-manager.
PostgreSQL
GitGuardian prend actuellement en charge PostgreSQL 15 à 18, avec PostgreSQL 17 comme 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 mettre à niveau vers PostgreSQL 16+ dès que possible.
Vous devrez installer les extensions suivantes :
| Extension | Utilisation | Version minimale |
|---|---|---|
| btree_gin | Fournit la capacité GIN aux types de données de base (int, timestamp, ...) afin que toutes les colonnes puissent être utilisées dans les index GIN | 1.3 |
| pg_trgm | Fournit des fonctions et des opérateurs permettant la recherche rapide de chaînes similaires à l'aide des 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 la recherche par similarité vectorielle à l'aide de nouveaux types, fonctions, opérateurs et index | 0.7.0 (0.8.0 recommandée) |
Selon votre installation, les extensions peuvent déjà être disponibles. C'est le cas pour les principales bases PostgreSQL managées par les fournisseurs cloud. Sinon, vous devrez peut-être effectuer certaines actions supplémentaires :
- L'extension plpgsql est installée par défaut.
- Les extensions btree_gin et pg_trgm sont disponibles dans le package postgresql-contrib.
- L'extension pgvector est disponible sous forme de package 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, reportez-vous à 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 pools de connexions (tels que PgBouncer) avec GitGuardian, car ils peuvent provoquer un comportement inattendu ou affecter les performances. Les connexions directes à PostgreSQL sont recommandées.
Redis
GitGuardian prend actuellement en charge Redis 6 à 8, avec Redis 7 comme 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, reportez-vous à notre page Scaling GitGuardian.
Pour la haute disponibilité, nous prenons en charge Redis Sentinel pour le cluster existant. 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 performances.
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 entraîner l'échec des nouvelles écritures lorsque la limite de mémoire est atteinte, alors choisissez votre politique d'éviction avec soin.
KOTS
La méthode d'installation "Cluster existant avec KOTS" utilise KOTS. Nous utilisons la dernière version de KOTS disponible pour valider nos versions. Vous trouverez la compatibilité des versions sur la page de compatibilité KOTS.
L'Admin Console KOTS aura un contrôle total sur 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 cluster embarqué (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 sur cluster embarqué legacy (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 exigences système de Replicated et de l'Embedded Cluster.
Nous recommandons vivement d'appliquer les derniers correctifs disponibles pour votre distribution de système d'exploitation avant de commencer l'installation.
Exigences de 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 utilisez les certificats auto-signés par défaut.
