Exigences réseau

Selon la méthode d'installation, vous aurez certaines exigences réseau, même pour les environnements Airgap.

Support IPv6

GitGuardian Self-Hosted prend en charge les réseaux IPv4, IPv6 et double pile. Pour plus de détails, consultez Réseau IPv6.

Services et composants

GitGuardian utilise différents composants pour son fonctionnement :

Nginx : serveur web,
Celery : gestionnaire de files d'attente et de tâches,
Django : framework utilisé pour l'application,
PostgreSQL : base de données,
Redis : gestionnaire de cache,
Replicated : console de gestion (KOTS admin et Replicated SDK).

Services and components

Après avoir installé l'application GitGuardian, vous verrez différents pods créés sur votre cluster Kubernetes.

Pour des informations détaillées sur les noms de déploiements/pods, leurs types et leur utilisation, consultez la page Topologie de l'application GitGuardian.

Accès externe

Les domaines à ajouter à la liste blanche et les ports à ouvrir ci-dessous sont spécifiques à l'installation, à la mise à niveau et à l'utilisation de l'application et de sa gestion.

Assurez-vous que les règles pertinentes sont correctement appliquées à votre pare-feu.

Règles entrantes

Pour que vous puissiez communiquer avec l'application GitGuardian, certains ports entrants doivent être ouverts.

Protocole	Port	Source	Destination	Description
TCP	443	0.0.0.0	Tous les nœuds K8S	Point d'entrée HTTPS GitGuardian
TCP	8800	0.0.0.0	Tous les nœuds K8S	KOTS Admin Console

Remarque : la KOTS Admin Console n'est pas applicable lors de l'utilisation de la méthode d'installation Helm.

La source est basée sur la politique d'accès aux services du client. Par exemple, la KOTS Admin Console peut être limitée à certaines IP internes pour empêcher l'accès public.

Nous recommandons de rejeter tout le trafic entrant à l'exception des ports listés ci-dessus.

Règles sortantes

Pour que l'application GitGuardian puisse communiquer avec des services externes, certains ports sortants doivent être ouverts.

Si vous utilisez un proxy HTTP, vous devrez peut-être également configurer votre proxy pour autoriser le trafic vers les domaines suivants.

Protocole	Port	Source	Destination	Description
TCP	443	Tous les nœuds K8S	*.replicated.com	Registre et proxy Replicated
TCP	443	Tous les nœuds K8S	replicated.app	API Replicated
TCP	443	Tous les nœuds K8S	*.docker.io	Registre Docker Hub (auth & pull)
TCP	443	Tous les nœuds K8S	production.cloudflare.docker.com	Registre Docker Hub

Remarque : le registre Docker Hub n'est pas applicable lors de l'utilisation de la méthode d'installation Helm.

Embedded cluster hérité (kURL) (instances installées en 2024 ou avant)

Si vous utilisez la méthode d'installation Embedded, il y a des ports supplémentaires à ouvrir.

Protocole	Port	Source	Destination	Description
TCP	443	Tous les nœuds K8S	k8s.kurl.sh	Installateur K8S kurl Replicated
TCP	443	Tous les nœuds K8S	s3.kurl.sh, kurl.sh	Installateur kurl Replicated
TCP	443	Tous les nœuds K8S	kurl-sh.s3.amazonaws.com	Ressources de l'installateur kurl Replicated

Replicated maintient une liste à jour des adresses IP associées à ces domaines.

Pour la plage d'adresses IP de k8s.kurl.sh, consultez replicatedhq/ips sur GitHub.
La plage d'adresses IP de s3.kurl.sh est la même que celle du domaine kurl.sh. Pour la plage d'adresses IP de kurl.sh, consultez replicatedhq/ips sur GitHub.
Les ressources de l'installateur kurl (paquets tar.gz) sont téléchargées depuis Amazon S3 lors des installations avec kURL. Pour plus d'informations sur la récupération dynamique des plages IP à autoriser pour accéder à ces paquets, consultez Plages d'adresses IP AWS dans la documentation AWS.

remarque

Selon vos intégrations et paramètres, des domaines ou plages d'IP supplémentaires peuvent devoir être ajoutés à la liste blanche et/ou autorisés dans votre proxy HTTP si vous en utilisez un.

Voici une liste des fonctionnalités qui effectuent des requêtes sortantes :

Honeytoken
Public Monitoring
Vérificateurs de validité de secrets
Intégrations VCS (GitHub, GitHub Enterprise Server, GitLab, Bitbucket...)
Intégrations de messagerie (Slack, Microsoft Teams...)
Intégrations de documentation (Confluence...)
Notificateurs externes (Slack, Jira...)
Notificateur webhook personnalisé
Notifications par e-mail (SMTP ou Sendgrid)

Exemple de proxy inverse Nginx pour l'installation embedded

Si vous souhaitez configurer un proxy inverse devant votre installation embedded, vous devez configurer et transmettre correctement l'en-tête SNI.

Voici un exemple de configuration pour un hôte virtuel Nginx. external_gitguardian_hostname est le nom d'hôte à utiliser dans un navigateur pour accéder au dashboard, et internal_gitguardian_hostname est le nom d'hôte utilisé pour atteindre l'instance GitGuardian en interne depuis le proxy inverse. C'est aussi le nom d'hôte configuré dans la KOTS Admin Console.

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name external_gitguardian_hostname;

    ssl_certificate           /path/to/fullchain.pem;
    ssl_certificate_key       /path/to/privkey.pem;

    set $target_host internal_gitguardian_hostname;

    location / {
      proxy_set_header        Host $target_host;
      proxy_set_header        X-Real-IP $remote_addr;
      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header        X-Forwarded-Proto $scheme;

      proxy_pass          https://$target_host;
      proxy_read_timeout  60;
      proxy_ssl_name $target_host;
      proxy_ssl_server_name on;
      proxy_ssl_protocols TLSv1.2 TLSv1.3;
      proxy_ssl_session_reuse off;
    }
}

Exemples d'architecture

Voici quelques exemples d'architecture qui peuvent vous aider à installer et configurer votre environnement GitGuardian.

Réseau interne

Internal network graph

Si vous disposez d'un réseau interne derrière un pare-feu, vous pouvez facilement vous connecter à un VCS interne (ex. : GitLab Self-Hosted).

Cependant, si vous souhaitez vous connecter à github.com, nécessitant ainsi un accès à Internet, vous devrez ouvrir largement l'accès entrant au port HTTPS de votre instance GitGuardian.

remarque

Il est possible de restreindre le trafic aux adresses IP de github.com, mais cela n'est pas recommandé par GitHub. Vous pouvez utiliser un pare-feu applicatif web (WAF) ou un proxy pour surveiller de près le trafic entrant sur l'instance GitGuardian.

Dans ce scénario, l'instance GitGuardian a besoin d'un port sortant 443 ouvert pour obtenir les mises à jour.

Réseau interne avec DMZ

DMZ network graph

Si en plus d'un réseau interne, vous disposez d'une DMZ et que vous souhaitez vous intégrer à github.com, vous pouvez placer l'instance GitGuardian dans la DMZ. Cela facilite l'accès à github.com, mais vous devrez exposer votre VCS interne en dehors de votre réseau interne afin que l'instance GitGuardian puisse y accéder.

Dans ce scénario, GitGuardian a besoin d'un port sortant 443 ouvert pour obtenir les mises à jour.

Réseau isolé

GitGuardian offre une solution entièrement hors ligne, garantissant que vos données restent dans votre environnement à tout moment.

Isolated network graph

Dans ce scénario, l'instance GitGuardian est complètement isolée d'Internet. Elle est hors ligne et airgap. Cela signifie qu'aucune surveillance de github.com n'est possible, et Public Monitoring ne peut pas fonctionner non plus, car il nécessite un accès sortant au service Public Monitoring de GitGuardian. Cela signifie également que vous n'avez pas besoin d'un port sortant 443 ouvert pour obtenir les mises à jour.

Pour plus de détails sur l'installation de GitGuardian dans un environnement airgap, consultez notre guide d'installation.

info

Cette fonctionnalité Airgap n'est pas disponible par défaut. Veuillez contacter votre représentant commercial si vous souhaitez l'activer.

Exigences réseau

Services et composants