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.
This documentation cover the existing Kubernetes installation. For embedded clusters, please refer to this documentation.
GitGuardian requires Kubernetes 1.18. We recommend using one of the version supported by the latest version of KOTS.
We need a dedicated namespace. The KOTS admin console will have full control over this namespace. This role will be created:
Name: kotsadm-roleLabels: kots.io/kotsadm=trueAnnotations: <none>PolicyRule: Resources Non-Resource URLs Resource Names Verbs --------- ----------------- -------------- ----- *.*   [*]
We are using the following objects, you need to have the appropriate controllers and operators to handle them.
- PersistentVolumeClaims: We are using persistent volume claims for KOTS, workers and the embedded databases.
- IngressController: We can provide a default ingress, an Ingress Controller is needed to handle it.
This is the requests the application will do with default settings:
|Ephemeral disk space||50GB|
|Persistant disk space||200GB|
- If you want to historical scan large repositories, consider temporarily increasing available ephemeral 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
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.
- 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.
- Outgoing access on TCP 443 to download application installer, prerequisites and application containers, and to access your VCS.
- Incoming access for the admin console. By default, this is accessed on http://localhost:8800 using this command
kubectl kots admin-console --namespace $your_namespace, which is a wrapper around
kubectl port-forward. You can configure an ingress if you want a public endpoint.
- Incoming access for the GitGuardian dashboard. By default, the GitGuardian application ships with an ingress. This should make it available on your ingress listening port for the FQDN you chose.
Go to this page, to learn more about network flows.
We recommend using external databases for GitGuardian as the embedded ones are not configured for High Availability and performance.
First, you need to install the KOTS plugin for kubectl. You can do this with this command:
curl https://kots.io/install | bash
Once you have the plugin installed, you can install the KOTS admin console:
kubectl kots install gitguardian-seal/prod
You will be be prompted to choose a namespace to deploy the application, and a password to access the admin console.
Once the installation of the admin console is finished, a port-forward will be setup, and you will be able to access the admin console on http://localhost:8800.
- Now, connect to the admin console and configure tls. You can upload tls certificates or use the self-signed ones.
- Enter the password provided at the end of the cluster installation.
- Upload the license downloaded on the portal (see here for instructions on how to download the license file).
- 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.
- Ingress: A default ingress is provided. More details to configured it are available here.
- 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 informations about configuration options are available here.
- Check if preflight checks pass.