OpenShift specifics

GitGuardian has been tested with OpenShift 4.

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

Deactivate securityContext

OpenShift default's configuration uses AnyUid SCC, meaning that pods will run as Non Root with a randomly injected UID/GID. As GitGuardian Self-Hosted uses securityContext directives setting UserIds and GroupIds to secure Pods, this setting must be deactivated in order to be able to run on OpenShift clusters.

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

If you set Resource quotas per Project, they must be sufficient for all your pods.

With KOTS-based installation, you can set cpu and memory requests, limits for each deployments, and set replicas. However, configuring requests and limits for ephemeral-storage is not possible."

On KOTS-based installations only long-tasks and scanner deployments will set hard-coded ephemeral-storage requests of 5GB.

On Helm-based installations, all resources requests and limits can be configured but same defaults apply on ephemeral-storage.

Ephemeral storage

Ephemeral Storage is used to clone repositories during Historical Scans. Ensure that your scanner pods have sufficient space to clone your largest repositories.

Was this page helpful?