Aller au contenu principal

Gestion des informations sensibles Helm

Introduction​

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

GitGuardian prend en charge trois façons 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 d'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 récupérer les 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 éventuellement être ajouté pour les paramètres de chiffrement.

Secret Docker (facultatif)​

Vous pouvez créer un secret Docker pour récupérer les images depuis 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 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 actuellement récupéré directement depuis docker.io. Vous pouvez récupérer 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 :

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 avec le paramètre existingSecret.

Travailler avec des magasins de secrets externes

Le paramètre existingSecret découple GitGuardian de tout magasin de secrets externe. GitGuardian ne lit 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) que depuis un secret Kubernetes déjà présent dans le cluster. Nous ne nous connectons jamais directement à votre gestionnaire de secrets.

Vos propres outils sont responsables de l'insertion des secrets dans ce secret Kubernetes. Par exemple :

GitGuardian ne joue aucun rôle dans ce flux et ne nécessite aucun accès au magasin 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 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 :

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"

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 relatifs à l'application en utilisant un secret existant.

Vous pouvez créer un ou plusieurs secret(s) pour stocker certaines informations sensibles telles que :

  • ADMIN_PASSWORD : mot de passe admin (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 le SP SAML
  • SP_PRIVATE_KEY : une clé privée X509 valide pour le SP SAML
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é s'il n'est pas 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 à niveau progressive 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 modifications 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, spécifiez le namespace Kubernetes avec --namespace (le namespace par défaut est utilisé s'il n'est pas spécifié).

Identifiants ClickHouse

Si vous activez ClickHouse, il utilise son propre secret séparé clickhouse-credentials contenant admin-password, api-password et api-username, et non le secret partagé gitguardian-secret ci-dessus. Consultez ClickHouse → Prérequis pour la configuration complète.

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 le faire, 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é s'il n'est pas 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 plutôt les paramètres existingSecrets. Cela vous aidera à mieux organiser et sécuriser vos secrets.

Vous pouvez vouloir stocker les informations sensibles dans votre système de gestion des secrets. Si tel est le cas, vous devriez le référencer dans le fichier local-values.yaml de cette façon :

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 le SP SAML
  • SP_PRIVATE_KEY : une clé privée X509 valide pour le SP SAML

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 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é s'il n'est pas spécifié).

Dernière mise à jour le

Il manque quelque chose ?

Voir notre feuille de route
S'abonner sur GitHub
Soumettre une demande
Statut de l’API