Here are some common questions.
The hardware specifications for the instance hosting GitGuardian can be found here.
For the supported distributions, see this question.
Both the application and the VCS must be able to initiate the connection. The application needs to access the VCS to gather information, and the VCS has webhooks. You need to make sure that the firewall is open for both service listening ports.
For more information about network flows, see this page
Embedded cluster: The supported distributions can be found here.
Existing cluster: Any cluster should be supported as long as they have the prerequisites listed here.
GitGuardian is deployed using Kots. It runs on a Kubernetes cluster. There is two methods to deploy GitGuardian:
- You already have an existing Kubernetes cluster that you want to use. In this case, follow this documentation.
- You don't have an existing cluster or you don't want to use the one you have. In this case, follow this documentation.
This is done through the admin console under the "Version History" tab. More information is available here.
This is done through the admin console under the "License" tab. More information is available here.
This is done through the admin console under the "Troubleshoot" tab. More information is available here.
If you want to add processing power to your cluster, for example to scan a lot of repositories, the easiest way to do so is to add worker nodes. To do so, go to this page.
Then, you can add configure the number of parallel GitGuardian workers, under "Advanced Options" in the admin console. All options are detailed here.
SSO integration can create user at their first connection (just-in-time).
SSO integration handles authentication but cannot automatically assign users to role inside the GitGuardian application.
Not supported yet. More coming soon.
The initial historical repository scan is resource intensive, and can be quite long.
On an embedded cluster, to speed up this process, we advise to temporarily add more worker nodes. Make sure they is at least 100Gio of storage on the root device of each node, as large repositories can use a lot of it.
On existing cluster, check the size of your cluster, and the limits on the gitguardian namespace.
In both cases, you will need to increase the number of "Scanning Workers" in the "Avdanced Options" in the admin console. Details about these options are available here. You should count 1 cpu core, 2-3 Gio of memory and about 1-10 Gio of ephemeral storage per additional worker.
All roles and permissions for users are described here.
Emails are configured in the admin area of the dashboard. This page explains how to configure them.
Backups are used when using the embedded Redis or Postgres on an embedded cluster. The storage target and the periodicity can be configured in the "Snaphots" tab of the admin console. More information about backups is available here
- Embedded cluster: Kots will be a cluster admin. This allows to do cluster management operations.
- Existing cluster: Kots will be an admin of the namespace it is assigned to. See here.
rook-ceph requires a raw storage without any filesystem on it. Make sure you have attached a second disk without mounting any filesystem on it.