Skip to main content

Network flows

Services and components#

Services and components

Ingress traffic#

Services and listening port:

ServiceUsageListen address
nginxweb server0.0.0.0:443 and 0.0.0.0:80
rediscache and configuration127.0.0.1:6379
postgresqldatabase and storage127.0.0.1:5432
gitguardianapplication127.0.0.1:5050
consoleadmin console0.0.0.0:8800

We recommend to drop all incoming traffic except on port TCP 80, TCP 443 and TCP 8800.

TCP port 443 is used to access the dashboard, but also for webhooks of your VCS. Please make sure https traffic is allowed both ways between GitGuardian and your VCS.

Egress traffic#

The following is a list of features that will make outbound requests.

  • Secret detector checkers
  • GitLab source
  • GitHub Enterprise source
  • GitHub source
  • Slack notifier
  • Custom webhook notifier
  • Email notifications (either SMTP or Sendgrid)

Nginx reverse proxy example (embedded)#

If you want to setup a reverse proxy in front of your embedded installation, you need to configure and forward the SNI header properly.

Here is an example configuration for an Nginx vhost. external_gitguardian_hostname is the hostname to use in a browser to access the dashboard, and internal_gitguardian_hostname is the hostname use to reach the GitGuardian instance internally from the reverse proxy. This is also the hostname set up in the 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;    }}

Architecture examples#

Internal network#

Internal network graph

If you have a internal network behind a firewall, you can easily connect to an internal VCS (eg: self-hosted GitLab).

However, if you want to connect to github.com, therefore requiring internet access, you will need to open a wide incoming access to the HTTPS port of your GitGuardian instance.

It is possible to restrict traffic to github.com IP addresses, but this is not recommended by GitHub. You can use a Web Application Firewall (WAF) or a proxy to monitor closely the incoming traffic on the GitGuardian instance.

In this scenario, the GitGuardian instance needs an open 443 egress port to get updates.

Internal network with DMZ#

DMZ network graph

If in addition to an internal network, you have a DMZ and you want to integrate with github.com, you can put the GitGuardian instance in the DMZ. This makes it easier to access github.com but you will need to expose your internal VCS outside of your internal network, so that the GitGuardian instance can access it.

In this scenario, the GitGuardian need an open 443 egress port to get updates.

Isolated network#

Isolated network graph

In this scenario, the GitGuardian instance is completely isolated from the Internet. It is offline and airgapped. This means no github.com monitoring is possible. But this also means, you don't need an open 443 egress port to get updates.

This Airgap functionality is not available by default. Please contact your sales representative if you want to enable it.