Prérequis réseau

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

Prise en charge IPv6

GitGuardian Self-Hosted prend en charge le réseau IPv4, IPv6 et dual-stack. Pour les détails, consultez IPv6 networking.

Services et composants

GitGuardian utilise différents composants pour son fonctionnement :

Nginx : serveur Web,
Celery : gestionnaire de file 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 et types de deployment/pod, et leur usage, consultez la page Topologie applicative GitGuardian.

Accès externe

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

Veillez à appliquer correctement les règles pertinentes à 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 nœuds K8S	Point d'entrée HTTPS de GitGuardian
TCP	8800	0.0.0.0	Tous nœuds K8S	Console d'administration KOTS

Note : la console d'administration KOTS ne s'applique pas si vous utilisez la méthode d'installation Helm.

La source dépend de la politique d'accès aux services du client. Par exemple, la console d'administration KOTS pourrait être limitée à certaines IP internes pour empêcher l'accès public.

Nous recommandons de bloquer 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 nœuds K8S	*.replicated.com	Registre et proxy Replicated
TCP	443	Tous nœuds K8S	replicated.app	API Replicated
TCP	443	Tous nœuds K8S	*.docker.io	Registre Docker hub (auth & pull)
TCP	443	Tous nœuds K8S	production.cloudflare.docker.com	Registre Docker hub

Note : le registre Docker hub ne s'applique pas si vous utilisez la méthode d'installation Helm.

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

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

Protocole	Port	Source	Destination	Description
TCP	443	Tous nœuds K8S	k8s.kurl.sh	Installer K8S kurl Replicated
TCP	443	Tous nœuds K8S	s3.kurl.sh, kurl.sh	Installer kurl Replicated
TCP	443	Tous nœuds K8S	kurl-sh.s3.amazonaws.com	Assets de l'installer 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 assets de l'installer kurl (paquets tar.gz) sont téléchargés depuis Amazon S3 lors des installations avec kURL. Pour récupérer dynamiquement les plages IP à allowlister pour accéder à ces paquets, consultez AWS IP address ranges dans la documentation AWS.

remarque

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

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

Honeytoken
Validity checkers de secrets
Intégrations VCS (GitHub, GitHub Enterprise Server, GitLab, Bitbucket...)
Intégrations de messagerie (Slack, Microsoft Teams...)
Intégrations de documentation (Confluence...)
Notifiers externes (Slack, Jira...)
Custom webhook notifier
Notifications par e-mail (SMTP ou Sendgrid)

Exemple de reverse proxy Nginx pour l'installation embedded

Si vous souhaitez mettre en place un reverse proxy devant votre installation embedded, vous devez configurer et transférer correctement l'en-tête SNI.

Voici un exemple de configuration pour un virtual host Nginx. external_gitguardian_hostname est le hostname à utiliser dans un navigateur pour accéder au tableau de bord, et internal_gitguardian_hostname est le hostname utilisé pour atteindre l'instance GitGuardian en interne depuis le reverse proxy. C'est aussi le hostname configuré dans la console d'administration KOTS.

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 avez un réseau interne derrière un pare-feu, vous pouvez facilement vous connecter à un VCS interne (par ex. GitLab self-hosted).

Cependant, si vous souhaitez vous connecter à github.com, ce qui nécessite un accès Internet, vous devrez ouvrir un large 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 Web Application Firewall (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 443 sortant ouvert pour recevoir 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 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 443 sortant ouvert pour recevoir les mises à jour.

Réseau isolé

GitGuardian propose 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'aucun monitoring de github.com n'est possible. Cela signifie également que vous n'avez pas besoin d'un port 443 sortant ouvert pour recevoir 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. Contactez votre représentant commercial si vous souhaitez l'activer.

Prérequis réseau

Services et composants