Install using OpenShift

GitGuardian has been tested with OpenShift 4.

Several requirements specific to OpenShift are required for installing GitGuardian application on OpenShift clusters.

Deactivate securityContext

GitGuardian Self-Hosted enforces securityContext directives by default. These settings can conflict with the securityContext requirements for some OpenShift security context constraints (SCCs) and must therefore be disabled.

Security note

Disabling our default securityContext does not mean a securityContext will not be set--it just means the SCC is responsible for setting the securityContext.

KOTS-based installations

KOTS-based installations automatically detect OpenShift clusters and deactivate securityContext on all deployments.

Helm-based installations

With Helm, the securityContext must be disabled in the values:

securityContext:
  enabled: false

Use OpenShift Route instead of Ingress

OpenShift proposes Route instead of regular Kubernetes Ingress. In order to leverage Routes, the default Ingress must be disabled in the KOTS Admin Console. Helm installations do not enable Ingress by default.

The Route can be defined as:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: gitguardian-helm
spec:
  host: <INSTANCE FQDN>
  path: /
  port:
    targetPort: http
  tls:
    certificate: |
      <CERTIFICATE FULLCHAIN>
    insecureEdgeTerminationPolicy: Redirect
    key: |
     <CERTIFICATE PRIVKEY>
    termination: edge
  to:
    kind: Service
    name: nginx
    weight: 100
  wildcardPolicy: None

Where:

• <INSTANCE FQDN> is the full qualified domain name of your instance
• <CERTIFICATE FULLCHAIN> is the TLS Certificate
• <CERTIFICATE PRIVKEY> is the TLS Certificate's private key

Note that if your GitGuardian instance has been created before October 2023, the service name is called gitguardian instead of nginx

Handle resource quotas per Project

When setting resource quotas per Project, it’s essential to ensure that the quotas are sufficient for all your pods. Depending on your installation type (KOTS-based or Helm-based), there are differences in how resource requests and limits can be configured, particularly regarding ephemeral storage.

For KOTS-based installations:

• You can set CPU and memory requests, limits for each deployment, and configure replicas.
• However, configuring requests and limits for ephemeral-storage is not possible.
• Only the long-tasks and scanner deployments have hard-coded ephemeral-storage requests of 5GB.

For Helm-based installations:

• All resource requests and limits, including those for ephemeral storage, can be fully configured (same default as KOTS-based installations). Refer to our Scaling GitGuardian page for more details.

Ephemeral Storage

Ephemeral Storage is used to clone repositories during Historical Scans. Ensure that your scanner pods are allocated sufficient space to handle the largest repositories.