Installation - Embedded Kubernetes Installation

Introduction

GitGuardian Private Repository Monitoring is a Kubernetes application. You can install the software on an existing cluster or use our installer that has an embedded, production-ready Kubernetes distribution packaged with it.

Our deployment is powered by Kots.

You can install our application on bare metal, GovCloud, VPC, Vsphere, or an existing Kubernetes cluster.

This documentation cover the embedded Kubernetes installation. For existing clusters, please refer to this documentation.

Deployment prerequisites

Hardware requirements

Component	Required Capacity
CPU	8 cores
Memory	32GB
Root disk space	100GB
Second disk space	200GB

The second raw storage is required. It should have no filesystem installed on it.

Notes:

• If you want to historical scan large repositories, consider temporarily increasing available root disk space.
• If you want additional workers (see application configuration below), provision 1 cpu core per additional worker.
• See below for recommendations on large scale deployments

Large scale deployment

For a large scale deployment, we highly recommend using a external redis and an external postgres. We recommend the following capacities for 2000 developers and/or 10000 repositories.

Redis: Use a master-slave setup for HA. We recommend an instance with at least 2 vCPU, 4GB RAM and 20GB disk

Postgresql: Use the replication mechanism your provider offers. We recommend an instance with at least 2 vCPU, 8GB RAM and 200GB disk.

System requirements

Distribution	Version
Ubuntu	20.04 LTS / 18.04 LTS / 16.04 LTS / 14.04 LTS
Red Hat EL	7.4 / 7.8
CentOS	7.4 / 7.8
Amazon Linux	2014.03 / 2014.09 / 2015.03 / 2015.09 / 2016.03 / 2016.09 / 2017.03 / 2017.09 / 2018.03 / v2

Source

Note: we highly recommend that you install the latest patch available for your distribution before starting the installation

Application requirements

• The Full Qualified Domain Name (FQDN) that you want to use for the application (ex: gitguardian.mycorp.local). This cannot be an IP.
• A TLS certificate for HTTPS access or use the default self signed certificates.

Network requirements

• Outgoing access on TCP 443 to download application installer, prerequisites and application containers.
• Incoming access on TCP 8800 to access admin console.
• Incoming access on TCP 443 to access GitGuardian dashboard.

Go to this page, to learn more about network flows.

Installation

Embedded cluster

To start the installation, run the following command on your host. This command will run for 10-20 minutes, putting in a screen or a tmux session can prevent an interruption due to a loss of connection.

curl -sSL https://k8s.kurl.sh/gitguardian-seal-prod | sudo bash

info

If a proxy is required for outgoing access to the internet, please create a patch.yaml:

apiVersion: "cluster.kurl.sh/v1beta1"kind: "Installer"metadata:  name: "patch"spec:  kurl:    proxyAddress: http://<IP>:<PORT>    noProxy: false

And run the installer with -installer-spec-file=patch.yaml:

curl -sSL https://k8s.kurl.sh/gitguardian-seal-prod | sudo bash -s installer-spec-file=patch.yaml

This will install a single node managed Kubernetes cluster with everything it needs to run GitGuardian application.

At the end of the installation command, there will be instructions on how to connect to the admin console. Port 8800 will need to be open to access it.

Save these information, especially passwords, they will be useful later.

Application

1. Now, connect to the admin console and configure tls. You can upload tls certificates or use the self-signed ones.

2. Enter the password provided at the end of the cluster installation.

3. Upload the license downloaded on the portal (see here for instructions on how to download the license file).

4. Configure the application. You need to fill all the required fields:
   • Application URL: URL for GitGuardian application.
   • Admin user fields: Used to create the first GitGuardian user. Password will need to be changed after the first login.
   • Nginx TLS certificate: You can either use auto-generated self-signed certificates or upload your own. These are not the same as the TLS certificates for the admin console used during step 1. If you choose to use self-signed certificates or your own private CA, you need to disable SSL verification for GitHub webhook.

Other configuration options available:

• Scaling (advanced): how many replicas for each application component.
• Databases/datastores: Whether to use an embedded postgres/redis or an external one.

More detailed information about configuration options are available here.

5. Check if preflight checks pass.

6. Launch