Installer sur un cluster existant avec KOTS
Introduction
Cette méthode d'installation sera dépréciée et non prise en charge après la release de juin 2026 (version 2026.6.0). Utilisez plutôt l'installation Helm sur un cluster existant.
⚠️ Utilisez l'installation Helm sur un cluster existant sauf indication contraire.
GitGuardian peut être installé sur votre cluster Kubernetes existant via KOTS, un plugin kubectl et la console d'administration KOTS pour aider à gérer les logiciels Kubernetes Off-The-Shelf.
GitGuardian prend en charge le déploiement sur bare metal, cloud privé ou public.
Prérequis
Infrastructure requise
-
Cluster Kubernetes : un cluster Kubernetes opérationnel. Voir les prérequis système pour les détails. Pour les clusters OpenShift, consultez les recommandations d'installation OpenShift.
-
Base PostgreSQL : une instance PostgreSQL externe avec les extensions requises installées. Voir Configurer votre base de données pour les détails de mise en place.
-
Instance Redis : une instance Redis dédiée. Voir les prérequis système pour les détails de configuration.
Prérequis supplémentaires
-
Fichier de licence : téléchargez votre licence GitGuardian depuis le portail. Voir Gestion de la licence pour les instructions.
-
Accès réseau : assurez-vous que votre cluster respecte les prérequis réseau.
-
Nom de domaine : un Fully Qualified Domain Name (FQDN) pour accéder à l'application. Voir les prérequis système.
Installation
Plugin KOTS
Vous devez d'abord installer le plugin KOTS pour kubectl. Vous pouvez le faire avec
cette commande :
curl https://kots.io/install | bash
RBAC de l'application Kubernetes
La console d'administration KOTS aura un contrôle total sur toutes les ressources de tous les namespaces du cluster. Plus d'informations dans la documentation Replicated.
Si vous n'êtes pas cluster-admin dans votre cluster Kubernetes ou que vous ne souhaitez pas accorder à la console d'administration KOTS de telles permissions étendues, vous devrez appliquer la configuration ci-dessous dans votre namespace cible <gitguardian_namespace> :
Rôles RBAC pour l'installation KOTS
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: kotsadm
namespace: <gitguardian_namespace>
labels:
kots.io/backup: velero
kots.io/kotsadm: 'true'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: kotsadm-role
namespace: <gitguardian_namespace>
labels:
kots.io/backup: velero
kots.io/kotsadm: 'true'
rules:
- apiGroups: ['']
resources:
[
'configmaps',
'persistentvolumeclaims',
'pods',
'secrets',
'services',
'limitranges',
'serviceaccounts',
]
verbs: ['get', 'list', 'watch', 'create', 'update', 'patch', 'delete']
- apiGroups: ['apps']
resources:
[
'daemonsets',
'deployments',
'deployments/scale',
'replicasets',
'statefulsets',
]
verbs: ['get', 'list', 'watch', 'create', 'update', 'patch', 'delete']
- apiGroups: ['batch']
resources: ['jobs', 'cronjobs']
verbs: ['get', 'list', 'watch', 'create', 'update', 'patch', 'delete']
- apiGroups: ['networking.k8s.io', 'extensions']
resources: ['ingresses', 'networkpolicies']
verbs: ['get', 'list', 'watch', 'create', 'update', 'patch', 'delete']
- apiGroups: ['policy']
resources: ['poddisruptionbudgets']
verbs: ['get', 'list', 'watch', 'create', 'update', 'patch', 'delete']
- apiGroups: ['']
resources: ['namespaces', 'endpoints']
verbs: ['get']
- apiGroups: ['authorization.k8s.io']
resources: ['selfsubjectaccessreviews', 'selfsubjectrulesreviews']
verbs: ['create']
- apiGroups: ['rbac.authorization.k8s.io']
resources: ['roles', 'rolebindings']
verbs: ['get', 'list', 'watch', 'create', 'update', 'patch', 'delete']
- apiGroups: ['']
resources: ['pods/log', 'pods/exec']
verbs: ['get', 'list', 'watch', 'create']
- apiGroups: ['batch']
resources: ['jobs/status']
verbs: ['get', 'list', 'watch']
- apiGroups: ['monitoring.coreos.com']
resources: ['servicemonitors']
verbs: ['get', 'list', 'watch', 'create', 'update', 'patch', 'delete']
- apiGroups: ['']
resources: ['events']
verbs: ['list']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: kotsadm-rolebinding
namespace: <gitguardian_namespace>
labels:
kots.io/backup: velero
kots.io/kotsadm: 'true'
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: kotsadm-role
subjects:
- kind: ServiceAccount
name: kotsadm
Et passez à l'étape de la console d'administration KOTS.
Console d'administration KOTS
Une fois le plugin installé, vous pouvez installer la console d'administration KOTS.
Si vous êtes cluster-admin :
kubectl kots install gitguardian
Sinon :
kubectl kots install --ensure-rbac=false gitguardian
Vous serez invité à choisir un namespace pour déployer l'application et un mot de passe pour accéder à la console d'administration KOTS.

Une fois l'installation de la console d'administration KOTS terminée, un port forward sera mis en place, et vous pourrez accéder à la console d'administration KOTS sur http://localhost:8800.
Console d'administration KOTS
Par défaut, on y accède sur http://localhost:8800 via cette commande
kubectl kots admin-console --namespace=<namespace>, qui est un wrapper
autour de kubectl port-forward. Vous pouvez configurer un ingress si vous voulez un endpoint public.
Lancez

Application
- Saisissez le mot de passe fourni à la fin de l'installation du cluster.

- Téléversez la licence téléchargée depuis le portail (voir les instructions pour télécharger le fichier de licence).

-
Configurez l'application. Vous devez remplir tous les champs obligatoires :
- Application Hostname : saisissez le Fully Qualified Domain Name (FQDN) de l'application GitGuardian.
- Champs administrateur : ces champs servent à créer le premier utilisateur GitGuardian. Vous devrez changer le mot de passe lors de la première connexion.
- Bases de données : vous devez sélectionner un PostgreSQL et un Redis externes ; voir Configurer votre base de données. Lors de l'utilisation de Redis Sentinel pour la haute disponibilité, vérifiez que le mot de passe master de Redis correspond à celui du sentinel et que vous utilisez le bon port Sentinel (par défaut : 26379).

Les options de configuration supplémentaires incluent :
- Scaling : ajustez le nombre de réplicas pour chaque composant de l'application. Pour plus de détails, consultez la page Scaling.
- Prometheus : activez un exporter pour Prometheus.
- Certificat TLS Ingress : pour l'application GitGuardian. Vous pouvez utiliser des certificats auto-signés générés automatiquement ou téléverser les vôtres. Pour les certificats auto-signés ou de CA privée, désactivez la vérification SSL pour le webhook GitHub. En savoir plus sur la page Configurer les certificats TLS.
- Load Balancer : le type de Service peut être changé de ClusterIP à LoadBalancer si nécessaire.
- Custom Certificate Authority : fournissez une CA personnalisée si nécessaire.
- Proxy HTTP(S) : référez-vous à la section proxy si nécessaire.
- Vérifiez que les preflight checks passent.
Les preflight checks sont essentiels pour une installation réussie. Les règles suivantes s'appliquent :
- ❌ Échec des preflight checks : si les preflight checks échouent, l'installation ne doit pas continuer tant que l'environnement cible ne satisfait pas tous les prérequis. Contactez notre équipe support si nécessaire.
- ⚠️ Avertissements des preflight checks : si les preflight checks renvoient des avertissements, l'installation peut continuer, mais il est recommandé de traiter ces avertissements pour respecter nos recommandations.

- Lancez
La première installation de l'application nécessite quelques minutes pour créer tous les objets de base de données. Une fois le processus terminé, vous pourrez vous connecter au tableau de bord en utilisant l'utilisateur administrateur que vous avez défini.
Conserver la clé de chiffrement des données
GitGuardian chiffre toutes les informations sensibles dans la base à l'aide d'une clé de chiffrement (aussi appelée Django Secret Key). En cas de reprise après sinistre, cette clé sera nécessaire pour restaurer vos données.
Vous devriez la sauvegarder et la conserver dans un emplacement sûr. Utilisez la commande suivante pour afficher la clé :
kubectl get secrets gim-secrets --namespace=<namespace> -o jsonpath='{.data.DJANGO_SECRET_KEY}' | base64 -d
Si nécessaire, précisez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé sinon).
Dépannage
Si vous rencontrez des problèmes durant l'installation, vous pouvez générer un support bundle pour permettre à l'équipe GitGuardian de diagnostiquer et résoudre les problèmes plus efficacement. Consultez la documentation du support bundle pour des instructions détaillées.
Prochaines étapes
Après une installation réussie :
- Accédez à votre instance GitGuardian via le hostname configuré
- Connectez-vous avec les identifiants administrateur que vous avez définis (changez le mot de passe temporaire à la première connexion)
- Configurez les paramètres d'e-mail pour les notifications
- Mettez en place l'intégration SSO et SCIM (optionnel)
- Intégrez vos premiers dépôts pour démarrer la détection des secrets