Prérequis système
La version Self-Hosted de GitGuardian se déploie comme une application Kubernetes. Nous recommandons d'installer GitGuardian sur un cluster existant via Helm. Vous trouverez plus d'informations sur la manière 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 pris en charge par toutes les méthodes d'installation
- ARM64 : pris en charge uniquement pour les installations basées sur Helm (Existing Cluster with Helm). Les installations KOTS et Embedded Cluster sont AMD64 uniquement
Toutes les images de conteneurs sont publiées sous forme de manifestes multi-architecture (multi-arch). Vous n'avez pas besoin de spécifier le flag Docker --platform ; la variante d'image appropriée est sélectionnée automatiquement selon l'architecture du nœud.
Installation sur cluster Kubernetes existant
Pour les recommandations de dimensionnement, consultez notre page Scaling GitGuardian.
Installation sur cluster Kubernetes Embedded
| Composant | Capacité requise |
|---|---|
| CPU | 8 cœurs |
| Mémoire | 48 Go |
| Espace disque root | 300 Go |
Cette installation présente quelques limitations :
- La prise en charge multi-nœuds est en bêta
- Le changement du hostname des nœuds n'est pas pris en charge
- Les mises à jour automatiques ne sont pas prises en charge
- Les support bundles dépassant 100 Mo dans la console d'administration
- L'installation sur des images d'OS hardenisé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 cluster existant, 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, consultez les recommandations 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 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 spécifiques au déploiement GCP, consultez le guide de déploiement GCP Marketplace.
Helm
La méthode d'installation Existing Cluster with Helm nécessite Helm version 3.13+.
- La version Helm 3.18.0 n'est pas prise en charge à cause d'un bug dans Helm, corrigé dans la 3.18.1 et les versions suivantes.
Utilisez une version de Helm compatible avec votre version de Kubernetes pour éviter les problèmes de compatibilité. Référez-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 des raisons réglementaires, 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 optionnelles. 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 aussi configurer toute autre classe d'Ingress Controller. Consultez notre rubrique Configuration de l'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 des métriques d'observabilité sur notre application.
- Vault : nous permettons l'utilisation de Vault via external-secrets SecretStore.
- CertManager : nous permettons la gestion de certificats via cert-manager ClusterIssuer.
PostgreSQL
GitGuardian prend actuellement en charge PostgreSQL 15 à 18, la version 17 étant la version recommandée.
Les versions PostgreSQL 13 et 14 ne sont plus prises en charge depuis la release 2025.1.0. Nous recommandons fortement de migrer vers PostgreSQL 16+ dès que possible.
Vous devrez installer les extensions suivantes :
| Extension | Utilisation | Version minimale |
|---|---|---|
| btree_gin | Fournit la capacité GIN pour les types 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 la recherche rapide de chaînes similaires via les index GiST et GIN | 1.5 |
| plpgsql | Permet la création de procédures stockées et triggers via le langage de programmation procédural PL/pgSQL | 1.0 |
| pgvector | Fournit la recherche par similarité vectorielle via de nouveaux types, fonctions, opérateurs et index | 0.7.0 (0.8.0 recommandé) |
Selon votre installation, les extensions peuvent déjà être disponibles. C'est le cas pour les principales bases PostgreSQL gérées par les fournisseurs 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 que superuser sur l'instance de base :
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 recommandations 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 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 (comme PgBouncer) avec GitGuardian, car ils peuvent provoquer des comportements inattendus ou affecter les performances. Les connexions directes à PostgreSQL sont recommandées.
Redis
GitGuardian prend actuellement en charge Redis 6 à 8, la version 7 étant la version recommandée. De plus, nous prenons en charge Valkey (un fork compatible Redis 7.2) comme implémentation Redis alternative.
Comment GitGuardian utilise Redis : Redis sert de message broker pour le traitement distribué des jobs (Celery), met en cache les données fréquemment accédées et stocke les résultats temporaires de scan.
Pour les déploiements à grande échelle, nous recommandons fortement 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 clusters existants. Redis Cluster n'est pas pris en charge.
L'instance Redis doit être dédiée exclusivement à l'application GitGuardian. Le partager avec d'autres applications peut entraîner des comportements inattendus, une corruption de 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 ex. rename-command "FLUSHDB" "").
Notez que si Redis a une politique d'éviction définie (comme noeviction, allkeys-lru, etc.), et que la politique est noeviction, Redis n'évincera aucune donnée. Cela peut faire échouer les nouvelles écritures lorsque la limite mémoire est atteinte ; choisissez donc votre politique d'éviction avec soin.
KOTS
La méthode d'installation « Existing cluster with KOTS » utilise KOTS. Nous utilisons la dernière version KOTS disponible pour valider nos releases. Vous trouverez la compatibilité des versions sur la page de compatibilité KOTS.
La console d'administration 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 Embedded
Pour les installations sur cluster Kubernetes Embedded, notez que ces configurations sont principalement destinées à des essais ou Proof of Concept (PoC) et ne sont pas recommandées pour la production.
Kubernetes
Pour les installations sur cluster Embedded (instances installées en 2025 ou plus tard), Kubernetes est mis à niveau automatiquement lors de la mise à jour de l'application GitGuardian via la console d'administration KOTS.
Pour les installations sur cluster Embedded 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 prérequis système Replicated et Embedded Cluster.
Nous recommandons fortement d'appliquer les derniers patchs disponibles pour votre distribution OS avant de commencer l'installation.
Prérequis nom de domaine
Vous aurez besoin d'un Fully Qualified Domain Name (FQDN) pour installer l'application (par ex. : gitguardian.mycorp.local). Cela ne peut pas être une IP.
Vous aurez également besoin d'un certificat TLS pour l'accès HTTPS, ou utilisez les certificats auto-signés par défaut.
