Helm Sensitive Information Management

Introduction

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 deployment and the configuration.

If you choose this method for the deployment, you can optionally specify Docker secrets used to pull images from a private container registry.

For the configuration, two secrets are needed for PostgreSQL and Redis information, and another one can optionally be added for encryption parameters.

Docker secret (optional)

You can create a Docker secret to pull images from a private registry. Once created, you can specify the secret name in your values-local.yaml file:

global:
  imageRegistry: docker.internal  # The host of the private registry
  imagePullSecrets:
  - name: pull-secret  # The name of the secret previously created

With this configuration, pods will use pull-secret docker secret to pull images from the docker.internal private registry.

Note: Replicated SDK is not impacted by the global.imageRegistry attribute and is pulled directly from docker.io at the moment. You may pull this image from another registry using replicated.images.replicated-sdk and replicated.imagePullSecrets.

Database parameters

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

• PostgreSQL password
• PostgreSQL TLS parameters
• Redis password
• Redis TLS parameters

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-literal=DJANGO_SECRET_KEY=my_django_secret_key \
--from-file /path/to/x509-key \
--from-file /path/to/x509-cert \
--namespace <namespace>

If needed, specify the Kubernetes namespace with --namespace (default namespace is used if not specified).

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

miscEncryption:
  existingSecret: "misc-encryption-secret-name" # The name of the secret previously created
  existingSecretKeys:
    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 --namespace <namespace> -o jsonpath='{.data.DJANGO_SECRET_KEY}' | base64 -d
kubectl get secrets gim-secrets --namespace <namespace> -o jsonpath='{.data.SP_X509_CERT}' | base64 -d
kubectl get secrets gim-secrets --namespace <namespace> -o jsonpath='{.data.SP_PRIVATE_KEY}' | base64 -d

If needed, specify the Kubernetes namespace with --namespace (default namespace is used if not specified).

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.

hostname: gitguardian.internal.yourcompany.com

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

redis:
  main:
    url: redis-url

onPrem:
  adminUser:
    email: your.email@example.com
    firstname: user_name

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

caution

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 --namespace <namespace> -o jsonpath='{.data.DJANGO_SECRET_KEY}' | base64 -d

If needed, specify the Kubernetes namespace with --namespace (default namespace is used if not specified).

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 :

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

The secret described there must contain the following keys :

• DJANGO_SECRET_KEY
• REDIS_URL: redis://username:password@host:port
• POSTGRES_PASSWORD
• 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 :

• ADMIN_PASSWORD
• DJANGO_SECRET_KEY
• POSTGRES_PASSWORD
• REDIS_URL
• SP_PRIVATE_KEY
• SP_X509_CERT

You can check this secret has been correctly created with:

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

If needed, specify the Kubernetes namespace with --namespace (default namespace is used if not specified).

Was this page helpful?