Skip to main content

Helm Sensitive Information Management


GitGuardian Helm installations are configured through a values file (see GitGuardian Helm Installation for more information). It requires configuring sensitive information.

Gitguardian supports three ways to set this information:

  • Sensitive parameters in Kubernetes secrets
  • Parameters inherited from external secrets
  • All parameters inline

Passing sensitive information through secrets should be favored over the inline option.

Kubernetes secrets

In the namespace prepared for the GitGuardian installation, you can set up secrets to safely store the sensitive information needed for the configuration. If you choose this method, two secrets are needed for PostgreSQL and Redis information, and another one can optionally be added for encryption parameters.

Database parameters

Check the relevant pages to see how to implement this option for :

Other encryption parameters (optional)

You may choose to set encryption parameters relevant to the application. If you don't, they will be automatically generated during your first installation.

kubectl create secret generic misc-encryption-secret-name \
--from-file /path/to/x509-key \
--from-file /path/to/x509-cert \

To reference this secret for installation, include this extract in your values-local.yaml file:

existingSecret: "misc-encryption-secret-name" # The name of the secret previously created
djangoSecretKey: "DJANGO_SECRET_KEY"
x509Cert: "SP_X509_CERT"
x509PrivateKey: "SP_PRIVATE_KEY"

After installation, if you didn't set these values yourself, you should retrieve the ones generated automatically and store them in a secure location.

kubectl get secrets gim-secrets -o jsonpath='{.data.DJANGO_SECRET_KEY}' | base64 -d
kubectl get secrets gim-secrets -o jsonpath='{.data.SP_X509_CERT}' | base64 -d
kubectl get secrets gim-secrets -o jsonpath='{.data.SP_PRIVATE_KEY}' | base64 -d

Inline parameters

You may store all information required for the configuration directly in your values-local.yaml file. If you choose to do so, the below example file shows the minimal elements that are required for a successful installation.


host: "postgresql"
username: postgres
database: postgres
password: postgres-password

url: redis-url

firstname: user_name

For optional fields that may be needed for your specific installations, such as TLS parameters, see the values reference documentation.


If you don't specify the miscEncryption.djangoSecretKey (which is the preferred method), it will be generated during the first installation, and you should then retrieve it and store it in a secure location.

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

External Secret

You may want to store the sensitive information in your secret management system. If that is the case, you should reference it in the values-local.yaml file in this way :

useExternalSecrets: true

path: "path/to/file"
name: vault # The secretStoreRef name
kind: SecretStore

The secret described there must contain the following keys :

  • REDIS_URL: redis://username:password@host:port
  • SP_X509_CERT: a valid X509 certificate for SAML SP
  • SP_PRIVATE_KEY: a valid X509 private key for SAML SP

Expected result

After the installation, no matter the method you chose, there should be a secret called gim-secrets in your namespace. It is expected to contain 6 parameters :

  • SP_X509_CERT

You can check this secret has been correctly created with:

kubectl get secrets gim-secrets -o jsonpath='{.data}' | python -m json.tool