Gestion des informations sensibles avec Helm

Introduction

Les installations Helm de GitGuardian sont configurées via un fichier de valeurs (voir Installation Helm GitGuardian pour plus d'informations). Cela nécessite la configuration d'informations sensibles.

GitGuardian prend en charge trois manières de définir ces informations :

• Paramètres sensibles dans des secrets Kubernetes
• Paramètres hérités de secrets externes (déprécié)
• Tous les paramètres en inline

Faire passer les informations sensibles par des secrets doit être privilégié par rapport à l'option inline.

Secrets Kubernetes

Dans le namespace préparé pour l'installation GitGuardian, vous pouvez mettre en place des secrets pour stocker en toute sécurité les informations sensibles nécessaires au déploiement et à la configuration.

Si vous choisissez cette méthode pour le déploiement, vous pouvez optionnellement spécifier des secrets Docker utilisés pour récupérer des images depuis un registre de conteneurs privé.

Pour la configuration, deux secrets sont nécessaires pour les informations PostgreSQL et Redis, et un autre peut être ajouté optionnellement pour les paramètres de chiffrement.

Secret Docker (optionnel)

Vous pouvez créer un secret Docker pour récupérer des images depuis un registre privé. Une fois créé, vous pouvez préciser le nom du secret dans votre fichier local-values.yaml :

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

Avec cette configuration, les pods utiliseront le secret Docker pull-secret pour récupérer les images depuis le registre privé docker.internal.

Note : le SDK Replicated n'est pas impacté par l'attribut global.imageRegistry et est récupéré directement depuis docker.io pour le moment. Vous pouvez récupérer cette image depuis un autre registre via replicated.images.replicated-sdk et replicated.imagePullSecrets.

Paramètres de base de données

Consultez les pages pertinentes pour voir comment implémenter cette option pour :

• Mot de passe PostgreSQL
• Paramètres TLS PostgreSQL
• Mot de passe Redis
• Paramètres TLS Redis

Secrets existants

Secret obligatoire

Vous devez pré-créer le secret de chiffrement de l'application avant le déploiement.

Générez une clé aléatoire et créez le secret :

Linux / macOS

DJANGO_SECRET_KEY=$(openssl rand -hex 32) && \
  echo "⚠️ Please save this key in a secure vault: $DJANGO_SECRET_KEY" && \
  kubectl create secret generic gitguardian-encryption \
    --namespace <namespace> \
    --from-literal=DJANGO_SECRET_KEY="$DJANGO_SECRET_KEY"

Windows (PowerShell)

$DJANGO_SECRET_KEY = -join ((1..32) | ForEach-Object { '{0:x2}' -f (Get-Random -Maximum 256) })
Write-Host "⚠️ Please save this key in a secure vault: $DJANGO_SECRET_KEY" -ForegroundColor Yellow
kubectl create secret generic gitguardian-encryption `
  --namespace <namespace> `
  --from-literal=DJANGO_SECRET_KEY=$DJANGO_SECRET_KEY

Puis référencez-le dans votre values.yaml :

miscEncryption:
  existingSecret: 'gitguardian-encryption'
  existingSecretKeys:
    djangoSecretKey: 'DJANGO_SECRET_KEY'

Secrets optionnels

Vous pouvez choisir de définir des paramètres pertinents pour l'application en utilisant un secret existant.

Vous pouvez créer un ou plusieurs secrets pour stocker des informations sensibles telles que :

• ADMIN_PASSWORD : mot de passe administrateur (utilisé uniquement lors de la première installation)
• DB_ENCRYPTION_KEY : clés de chiffrement (optionnel, nécessaire uniquement pour la rotation de la clé de chiffrement de la base de données)
• REDIS_URL : redis://username:password@host:port
• POSTGRES_PASSWORD
• SP_X509_CERT : un certificat X509 valide pour SAML SP
• SP_PRIVATE_KEY : une clé privée X509 valide pour SAML SP

kubectl create secret generic gitguardian-secret \
  --from-literal=ADMIN_PASSWORD=my_admin_password \
  --from-literal=REDIS_URL=my_redis_url \
  --from-literal=POSTGRES_PASSWORD=my_postgres_password \
  --from-file=SP_PRIVATE_KEY=/path/to/x509-key \
  --from-file=SP_X509_CERT=/path/to/x509-cert \
  --namespace <namespace>

Si nécessaire, précisez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé sinon).

Pour référencer ce secret lors de l'installation, incluez cet extrait dans votre fichier local-values.yaml :

onPrem:
  adminUser:
    email: your.email@example.com
    firstname: user_name
    existingSecret: gitguardian-secret
    existingSecretKeys:
      password: ADMIN_PASSWORD

postgresql:
  existingSecret: gitguardian-secret
  existingSecretKeys:
    password: POSTGRES_PASSWORD

redis:
  main:
    existingSecret: gitguardian-secret
    existingSecretKeys:
      url: REDIS_URL

miscEncryption:
  existingSecret: gitguardian-secret # The name of the secret previously created
  existingSecretKeys:
    x509Cert: SP_X509_CERT
    x509PrivateKey: SP_PRIVATE_KEY

Dans ce cas, comme certains éléments de configuration sont gérés en dehors du Helm chart, vous devriez envisager d'utiliser Reloader pour effectuer automatiquement un rolling upgrade sur les workloads Kubernetes pertinents comme les Deployments.

Par exemple, si vous annotez le secret gitguardian-secret avec reloader.stakater.com/match: 'true', vous pouvez configurer les annotations suivantes dans local-values.yaml pour effectuer un rollout lors des changements de secret :

front:
  nginx:
    annotations:
      reloader.stakater.com/search: 'true'

webapps:
  hook:
    annotations:
      reloader.stakater.com/search: 'true'
  internal_api:
    annotations:
      reloader.stakater.com/search: 'true'
  internal_api_long:
    annotations:
      reloader.stakater.com/search: 'true'
  public_api:
    annotations:
      reloader.stakater.com/search: 'true'

celeryWorkers:
  email:
    annotations:
      reloader.stakater.com/search: 'true'
  long:
    annotations:
      reloader.stakater.com/search: 'true'
  realtime-ods:
    annotations:
      reloader.stakater.com/search: 'true'
  scanners:
    annotations:
      reloader.stakater.com/search: 'true'
  worker:
    annotations:
      reloader.stakater.com/search: 'true'

Après l'installation, si vous n'avez pas défini ces valeurs vous-même, vous devriez récupérer celles générées automatiquement et les stocker dans un emplacement sécurisé.

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

Si nécessaire, précisez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé sinon).

Paramètres en inline

Vous pouvez stocker toutes les informations requises pour la configuration directement dans votre fichier local-values.yaml. Si vous choisissez de le faire, l'exemple de fichier ci-dessous montre les éléments minimaux requis pour une installation réussie.

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

Pour les champs optionnels qui peuvent être nécessaires à vos installations spécifiques, tels que les paramètres TLS, consultez la documentation de référence des values.

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

Si nécessaire, précisez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé sinon).

Secret externe (déprécié)

attention

La gestion des secrets externes est dépréciée et supprimée en 2026.4.0. Vous devez gérer la maintenance des ressources externalSecret vous-même et utiliser à la place les paramètres existingSecrets. Cela vous aidera à mieux organiser et sécuriser vos secrets.

Vous pourriez vouloir stocker les informations sensibles dans votre système de gestion de secrets. Si c'est le cas, vous devriez le référencer dans le fichier local-values.yaml ainsi :

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

Le secret décrit là doit contenir les clés suivantes :

• DJANGO_SECRET_KEY
• REDIS_URL : redis://username:password@host:port
• POSTGRES_PASSWORD
• SP_X509_CERT : un certificat X509 valide pour SAML SP
• SP_PRIVATE_KEY : une clé privée X509 valide pour SAML SP

Résultat attendu

Après l'installation, quelle que soit la méthode choisie, il devrait y avoir un secret appelé gim-secrets dans votre namespace. Il devrait contenir 6 paramètres :

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

Vous pouvez vérifier que ce secret a été correctement créé avec :

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

Si nécessaire, précisez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé sinon).