Gestion des informations sensibles Helm

Introduction

Les installations Helm de GitGuardian sont configurées via un fichier de valeurs (voir Installation Helm de GitGuardian pour plus d'informations). Cela nécessite de configurer des 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 ligne

Le passage des informations sensibles via des secrets doit être privilégié par rapport à l'option en ligne.

Secrets Kubernetes

Dans le namespace préparé pour l'installation de GitGuardian, vous pouvez configurer 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 éventuellement spécifier des secrets Docker utilisés pour extraire les images d'un registre de conteneurs privé.

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

Secret Docker (facultatif)

Vous pouvez créer un secret Docker pour extraire les images d'un registre privé. Une fois créé, vous pouvez spécifier 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 extraire les images du registre privé docker.internal.

Remarque : Replicated SDK n'est pas impacté par l'attribut global.imageRegistry et est extrait directement de docker.io pour le moment. Vous pouvez extraire cette image depuis un autre registre en utilisant 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

Vous pouvez stocker les valeurs de configuration sensibles dans des secrets Kubernetes et les référencer dans votre fichier local-values.yaml à l'aide du paramètre existingSecret.

Utilisation avec des gestionnaires de secrets externes

Le paramètre existingSecret découple GitGuardian de tout gestionnaire de secrets externe. GitGuardian lit uniquement les valeurs sensibles (clé secrète Django pour le chiffrement de la base de données, identifiants de base de données et de cache, certificats SAML) à partir d'un secret Kubernetes déjà présent dans le cluster. Nous ne nous connectons jamais directement à votre gestionnaire de secrets.

Votre propre outillage est responsable de l'injection des secrets dans ce secret Kubernetes. Par exemple :

• External Secrets Operator synchronisant depuis AWS Secrets Manager, GCP Secret Manager ou Azure Key Vault.
• Vault Secrets Operator synchronisant depuis HashiCorp Vault.

GitGuardian n'a aucun rôle dans ce flux et ne nécessite aucun accès au gestionnaire en amont. L'utilisation d'un secret Kubernetes pour ces identifiants est une pratique Kubernetes standard et permet à l'application d'y accéder en toute sécurité sans coupler le déploiement à votre backend de secrets.

Secret obligatoire

Vous devez créer au préalable 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 facultatifs

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

Vous pouvez créer un ou plusieurs secrets pour stocker certaines 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 (facultatif, 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, spécifiez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé si non spécifié).

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 certaines parties de la configuration sont gérées en dehors du chart Helm, vous devriez envisager d'utiliser Reloader pour effectuer automatiquement une mise à jour progressive (rolling upgrade) sur les workloads Kubernetes pertinents tels que 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 modifications du 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, spécifiez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé si non spécifié).

Paramètres en ligne

Vous pouvez stocker toutes les informations requises pour la configuration directement dans votre fichier local-values.yaml. Si vous choisissez de procéder ainsi, le fichier d'exemple 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 facultatifs qui peuvent être nécessaires pour vos installations spécifiques, tels que les paramètres TLS, consultez la documentation de référence des valeurs.

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

Si nécessaire, spécifiez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé si non spécifié).

Secret externe (déprécié)

attention

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

Vous voudrez peut-être stocker les informations sensibles dans votre système de gestion de secrets. Si c'est le cas, vous devez le référencer dans le fichier local-values.yaml de la manière suivante :

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

Le secret décrit ici 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 doit y avoir un secret appelé gim-secrets dans votre namespace. Il est censé 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, spécifiez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé si non spécifié).