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 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-literal=DJANGO_SECRET_KEY=my_django_secret_key
--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:
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 -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.
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.
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
secrets:
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 -o jsonpath='{.data}' | python -m json.tool