Skip to main content

Install on an Existing cluster using KOTs


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 covers the existing Kubernetes installation. For embedded clusters, please refer to this documentation.


Do not forget to check the installation requirements before starting the installation:

You also need to download your license.


KOTS plugin#

First, you need to install the KOTS plugin for kubectl. You can do this with this command:

curl | bash

Kubernetes Application RBAC#

The KOTS admin console will have full control over all resources across all namespaces in the cluster.
More information in Replicated documentation.

If you are not cluster-admin in your Kubernetes cluster or do not want to grant the KOTS admin console such wide permissions, you will need to apply the below configuration in your targeted namespace:

---apiVersion: v1kind: ServiceAccountmetadata:  name: kotsadm  labels: velero "true"
---apiVersion: Rolemetadata:  name: kotsadm-role  labels: velero "true"rules:  - apiGroups: [""]    resources: ["configmaps", "persistentvolumeclaims", "pods", "secrets", "services", "limitranges", "serviceaccounts"]    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]  - apiGroups: ["apps"]    resources: ["daemonsets", "deployments", "deployments/scale", "statefulsets"]    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]  - apiGroups: ["batch"]    resources: ["jobs", "cronjobs"]    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]  - apiGroups: ["", "extensions"]    resources: ["ingresses"]    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]  - apiGroups: ["policy"]    resources: ["poddisruptionbudgets"]    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]  - apiGroups: [""]    resources: ["namespaces", "endpoints"]    verbs: ["get"]  - apiGroups: [""]    resources: ["selfsubjectaccessreviews", "selfsubjectrulesreviews"]    verbs: ["create"]  - apiGroups: [""]    resources: ["roles", "rolebindings"]    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]  - apiGroups: [""]    resources: ["pods/log", "pods/exec"]    verbs: ["get", "list", "watch", "create"]  - apiGroups: ["batch"]    resources: ["jobs/status"]    verbs: ["get", "list", "watch"]
---apiVersion: RoleBindingmetadata:  name: kotsadm-rolebinding  labels: velero "true"roleRef:  apiGroup:  kind: Role  name: kotsadm-rolesubjects:  - kind: ServiceAccount    name: kotsadm

And proceed with the KOTS console step (see below).

KOTS console#

Once you have the plugin installed, you can install the KOTS admin console.

If you are cluster-admin:

kubectl kots install gitguardian-seal/prod

If not:

kubectl kots install --ensure-rbac=false gitguardian-seal/prod

You will be prompted to choose a namespace to deploy the application and a password to access the admin console.

Namespace and password prompt

Once the installation of the admin console is finished, a port forward will be set up, and you will be able to access the admin console on http://localhost:8800.


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.

  1. Launch

End of existing cluster installation


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

Admin console password

  1. Upload the license downloaded on the portal for instructions on how to download the license file).

License upload

  1. Configure the application. You need to fill in all the required fields:
    • Application URL: URL for GitGuardian application.
    • Admin user fields: Used to create the first GitGuardian user. The password will need to be changed after the first login.
  • Ingress: A default ingress is provided.
    • 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 the GitHub webhook.

Admin console application configuration

Other configuration options available:

  • Scaling (advanced): how many replicas for each application component.
  • Databases/datastores: Whether to use an embedded PostgreSQL/Redis or an external one.
  1. Check if preflight checks pass.

Admin console preflights

  1. Launch

The first installation of the application requires a few minutes to create all database objects.
Once the process is completed, you will be able to log in to the dashboard using the administrator user you defined.

  1. Save the Data Encryption Key

GitGuardian encrypts all sensitive information in the database using an encryption key (aka Django Secret Key). In case of disaster recovery, this key will be needed to restore your data.

You should save it and keep it in a secure location. Use the following command to display the key:

kubectl get secrets gitguardian-env-variables  -o jsonpath='{.data.DJANGO_SECRET_KEY}' | base64 -d