Here is a list with more detailed information about each application configuration option available in the admin console.
- Hostname: This is the hostname for the application. It will be accessible under this hostname.
The following fields are used to create the first administrator user for the application.
- Username: admin username
- Email: admin email
- Password/Confirm password: admin password. This password doesn't have any constraints. It will be reset during the first connection.
Changing this after the installation has no effect.
CPU limits refer to the Kubernetes resource limits.
By clicking the Advanced Options button, you have access to scaling the number of replicas and the CPU limits for three kinds of pods:
- Front: front-end workers, serving API requests and static web frontend files.
- Workers: workers handling incremental changes, new commits, etc. These workers are usually processing short-running tasks.
- Scanning workers: workers are usually processing long-running tasks, like historical scans.
Changing the number of replicas doesn't affect the rollout upgrade strategy.
Workers are configured to spread across nodes if there are multiple nodes. If you have configured your cluster for high availability, do not use less than 2 workers of each type.
Only for existing clusters
On existing clusters, a default ingress is provided. You can disable it and use your own.
The service backend listens only on HTTPS, the ingress needs to be configured for this behavior. If you are using the Nginx ingress controller, this is already done in the included ingress. If you are using another ingress controller, you will probably need to add the appropriate annotations in the text area for this. You will also need to configure this if you bring your own ingress.
The annotation area can also be used to add an ingress class if you need it.
Only for existing clusters
On existing clusters, you can change the Service type from ClusterIP to Load Balancer. This allows you to create a dedicated cloud load balancer (for example an ALB in AWS) for the GitGuardian dashboard. This does not affect the KOTS admin console, which is only accessible with a port forward. Unless you manually configure another way to access it.
The annotation area can be used to customize the service, if necessary.
You need to configure TLS certificates. For now, you can:
- Use self-signed certificates. Useful for a quick and dirty setup, to test the deployment of the application. They will be some issues with the integration. Not recommended for anything else than initial testing.
- Upload your certificates.
- Use an existing Kubernetes secret containing the certificates. If you have a certificate manager in your k8s cluster, this can be useful.
This is an experimental feature.
Warning: Using a custom CA will deactivate system provided CAs.
If your VCS is using a custom CA, you need to provide it and tell GitGuardian to use it. To provide it, you need to generate a bundle using the following steps:
- Get your certificates to establish the chain of trust, and put them in a folder, one file per certificate. Here we use
$ tree $HOME/gitguardian/trusted-certs/home/centos/gitguardian/trusted-certs├── my-other-ca.pem└── my-private-ca.pem 0 directories, 2 files
# On CentOS/RHELyum install openssl-perl # On Debian/Ubuntuapt-get install openssl
- Prepare the directory for
opensslto consume using
$ c_rehash $HOME/gitguardian/trusted-certsDoing /home/centos/gitguardian/trusted-certs $ tree $HOME/gitguardian/trusted-certs/home/centos/gitguardian/trusted-certs├── 4dfd5795.0 -> my-private-ca.pem├── da4e607d.0 -> my-other-ca.pem├── my-other-ca.pem└── my-private-ca.pem 0 directories, 4 files
- Zip the folder. Make that all files are at the root of the archives, without any directory in between.
$ cd $HOME/gitguardian/trusted-certs$ zip -r ../trusted-certs-bundle.zip .
- Your bundle is created in
Parameters here should not be changed after installation unless you know what you are doing, as it may result in data losses.
You can use the provided database, or bring your own. Both can be used with any installation method (embedded cluster or existing cluster).
The embedded PostgreSQL requires no additional configuration. It is great for testing and small-size instances. It does not provide high availability. For backups, refer to the backup page.
The external PostgreSQL requires having an external database set up (e.g. with RDS on AWS). This is the recommended setup for large-scale deployments. Scaling, high availability, and backups should be managed with the provider's tools.
The embedded PostgreSQL is a PostgreSQL 12 running on a single pod. The only configurable option is the size of the disk. The default value should be enough for most cases. You may increase it after installation, but not decrease it. See here for detailed procedure and prerequisites.
For an external PostgreSQL, you have the following configuration options:
- Host: the IP or hostname for your PostgreSQL. Defaults to "postgres".
- Port: the port on which PostgreSQL listens. Defaults to "5432".
- Username: the user used to connect to the database. Required.
- Password: the password used to connect to the database. Required.
- Database: the name of the database to connect to. Defaults to "prm". The database must exist.
To configure TLS for an external PostgreSQL you have the following configuration options:
- PostgreSQL TLS mode: PostgreSQL server supports the following TLS mode:
- Allow: first try an SSL connection; if that fails, try a non-SSL connection.
- Require: only try an SSL connection. If a root Certificate Authority file is present, verify the certificate in the same way as if Verify Certificate Authority was specified.
- Verify Certificate Authority: only try an SSL connection, and verify that the server certificate is issued by a trusted certificate authority (CA).
- Verify Certificate Authority and Hostname: only try an SSL connection, verify that the server certificate is issued by a trusted CA and that the requested server hostname matches that in the certificate.
- Custom certificate authority: custom certificate authority to use to authenticate PostgreSQL server identity.
- Client authentication required: PostgreSQL server configured to authenticate a client.
- PostgreSQL client TLS key.
- PostgreSQL client TLS certificate.
To disable TLS configuration, you should first set "Postgres TLS mode" to Allow in the Admin Console and deploy the configuration. Then you can disable TLS on the PostgreSQL server. Finally, disable the TLS configuration within the Admin Console.
You can use the provided cache, or bring your own. Both can be used with any installation method (embedded cluster or existing cluster).
The embedded Redis requires no additional configuration. It is great for testing and small-size instances. It does not provide high availability. For backups, refer to the backup page.
The external Redis requires having an external cache set up (e.g. with Elasticache on AWS). This is the recommended setup for large-scale deployments. Scaling, high availability, and backups should be managed with the provider's tools.
The embedded Redis is a Redis 5 running on a single pod. The only configurable option is the size of the disk. The default value should be enough for most cases. You may increase it after installation, but not decrease it. See here for detailed procedure and prerequisites.
For an external Redis, you have the following configuration options:
- Host: the IP or hostname for your Redis. Defaults to "redis".
- Port: the port on which Redis listens. Defaults to "6379".
- Username: the user used to connect to the cache. Can be left empty.
- Password: the password used to connect to the cache. Required.
- Use TLS: checkbox to specify how to communicate to Redis.
To configure TLS for Redis, you have the following configuration options:
- Require Redis server authentication: force GIM application to require the Redis server to authenticate with a valid certificate. By checking this setting, you can provide a custom certificate authority to validate the Redis server certificate.
- Client authentication required: if the Redis server is configured to require client authentication, you need to check this box and provide:
- a TLS key,
- a TLS certificate.