Aller au contenu principal

Configurer votre base de données

Ce guide vous aidera à configurer votre base de données. Les paramètres décrits ici ne doivent pas être modifiés après l'installation, sauf si vous savez ce que vous faites, car cela pourrait entraîner des pertes de données.

attention

Si vous utilisez des bases de données externes, pensez à ouvrir les ports entre le cluster d'application GitGuardian et vos bases de données.

PostgreSQL​

Vous pouvez utiliser la base de données fournie avec l'installation embedded cluster ou apporter la vôtre pour les installations embedded et external cluster. Nous vous encourageons à utiliser une base de données externe.

Embarquée versus externe​

Le PostgreSQL embarqué ne nécessite aucune configuration supplémentaire. Il est parfait pour les tests et les instances de petite taille. Il ne fournit pas de haute disponibilité. Pour les sauvegardes, reportez-vous à la page de sauvegarde.

Le PostgreSQL externe nécessite d'avoir une base de données externe configurée (par exemple avec RDS sur AWS). C'est la configuration recommandée pour les déploiements à grande échelle. La mise à l'échelle, la haute disponibilité et les sauvegardes doivent être gérées avec les outils du fournisseur.

Configuration rapide de PoC sur un existing cluster

Si vous souhaitez exécuter PostgreSQL et Redis à l'intérieur de votre cluster Kubernetes pour une preuve de concept ou pour des tests, vous pouvez utiliser les presets helm-pg-redis-poc. Ils fournissent des configurations Helm Small/Medium/Large prêtes à l'emploi et alignées sur le guide Scaling. Pour la production, préférez les services managés de votre fournisseur cloud.

Configuration embarquée​

info

Si vous n'avez pas encore effectué la mise à niveau vers PostgreSQL version 16, veuillez suivre le guide de migration pour migrer votre embedded cluster existant vers PostgreSQL 16.

Le PostgreSQL embarqué est un PostgreSQL 16 exécuté sur un seul pod.

attention

Si vous utilisez PgBouncer, ajoutez ce qui suit au fichier pgbouncer.ini pour permettre aux tâches GitGuardian telles que l'intégration de dépôt de fonctionner correctement :

[pgbouncer]
pool_mode = session
ignore_startup_parameters = options,[... other parameters if needed]

Pour plus de détails, consultez : Configuration de PgBouncer

Configuration externe​

Pour un PostgreSQL externe, vous disposez des options de configuration suivantes :

  • Host : l'IP ou le nom d'hôte de votre PostgreSQL. Par défaut « postgres ».
  • Port : le port sur lequel PostgreSQL écoute. Par défaut « 5432 ».
  • Username : l'utilisateur utilisé pour se connecter à la base de données. Obligatoire.
  • Password : le mot de passe utilisé pour se connecter à la base de données. Obligatoire.
  • Database : le nom de la base de données à laquelle se connecter. Par défaut « prm ». La base de données doit exister.
  • Schema : GitGuardian utilisera le schéma par défaut défini pour l'utilisateur (généralement « public »).

Pour les recommandations de mise à l'échelle, reportez-vous aux exigences matérielles pour les embedded clusters ou les existing clusters.

Installation via Helm​

L'installation via Helm ne prend actuellement en charge que les bases de données externes. Lors de l'installation via Helm, les paramètres seront transmis via un fichier YAML. Les paramètres suivants doivent être définis en ligne :

  • host
  • username le cas échéant
  • database
  • port (5432 sera utilisé par défaut)
astuce

Pour vous assurer que vos bases de données sont correctement configurées et accessibles, vous pouvez utiliser notre script preflight.

Quant au mot de passe, il peut soit être défini dans un secret Kubernetes, soit être défini en ligne comme les autres paramètres. Il est préférable d'utiliser des secrets plutôt que de définir des paramètres sensibles en ligne dans les values.

Si vous choisissez la première méthode, ajoutez un secret à votre namespace, s'il n'existe pas encore :

kubectl create secret generic gitguardian-postgresql-secret \
  --from-literal=POSTGRES_PASSWORD=my_pg_password

Si vous avez l'intention d'activer TLS pour votre base de données PostgreSQL, le secret contenant le mot de passe doit également contenir les informations TLS. Référencez le secret via le paramètre postgresql.existingSecret. La clé du mot de passe dans ce secret doit être définie comme postgresql.existingSecretKeys.password :

postgresql:
  host: null # PostgreSQL database hostname
  username: null # PostgreSQL database username
  database: null # PostgreSQL database name
  port: 5432
  existingSecret: gitguardian-postgresql-secret
  existingSecretKeys:
    password: 'POSTGRES_PASSWORD'

Si vous choisissez la seconde méthode, votre fichier YAML doit contenir cet extrait :

postgresql:
  host: null # PostgreSQL Database host name
  username: null # PostgreSQL Database username
  database: null # PostgreSQL database name
  port: 5432
  password: 'my_pg_password'

Permissions de l'utilisateur de la base de données​

Lors de la configuration de votre base de données PostgreSQL, il est essentiel de configurer l'utilisateur de la base de données avec les permissions appropriées.

L'utilisateur spécifié dans la configuration (paramètre username) doit être le propriétaire de la base de données :

ALTER DATABASE my_pg_database OWNER TO my_pg_database_user;

Si cela n'est pas possible en raison d'une réglementation interne, l'utilisateur aura besoin des droits suivants :

  1. Connexion et création d'objets dans la base de données : L'utilisateur doit avoir le privilège de se connecter à la base de données et de créer des extensions et des schémas dans celle-ci.

    GRANT ALL ON DATABASE my_pg_database TO my_pg_database_user;

  2. Création de tables et d'autres objets : Pour créer des tables, des index, des triggers et des vues, l'utilisateur a besoin du droit de créer des objets dans le schéma spécifié.

    GRANT ALL ON SCHEMA public TO my_pg_database_user;

  3. Droits de modification des données : L'utilisateur doit disposer des droits nécessaires pour insérer, mettre à jour et supprimer des données dans les tables.

    GRANT ALL ON ALL TABLES IN SCHEMA public TO my_pg_database_user WITH GRANT OPTION;

Schémas d'analytics in-app​

info

Disponible à partir de la version 2026.9.0, sur les installations Helm.

Chaque nuit, le job inapp-analytics reconstruit les données analytics que le dashboard lit. Il écrit deux familles d'objets :

  • les objets que l'application relit, qui doivent se trouver dans le même schéma que les tables GitGuardian ;
  • ses propres objets intermédiaires, qui ne sont lus par rien en dehors du job.

Par défaut, le job attend les tables GitGuardian dans le schéma public, et il crée un schéma analytics pour ses objets intermédiaires. Si votre politique interdit public, ou si votre utilisateur de base de données ne peut pas créer de schéma, définissez la disposition dans vos values Helm :

ValueDéfautDescription
inAppAnalytics.postgresql.applicationSchemapublicSchéma qui contient les tables GitGuardian.
inAppAnalytics.postgresql.useSeparateAnalyticsSchematrueSi les objets intermédiaires obtiennent leur propre schéma.
inAppAnalytics.postgresql.analyticsSchemaanalyticsNom du schéma intermédiaire analytics.

Définissez applicationSchema sur le schéma par défaut de votre utilisateur de base de données. Le job ne le lit pas depuis le search_path de l'utilisateur.

Le job crée analyticsSchema lors de sa première exécution, de sorte que les values ci-dessus suffisent à la plupart des installations :

inAppAnalytics:
  postgresql:
    applicationSchema: gitguardian
    analyticsSchema: gg_analytics

Si votre utilisateur de base de données ne peut pas créer de schémas, vous avez deux options. Créez le schéma vous-même et accordez-le à l'utilisateur, et le job utilise le schéma tel quel :

CREATE SCHEMA gg_analytics;
GRANT USAGE, CREATE ON SCHEMA gg_analytics TO my_pg_database_user;

Ou conservez les objets intermédiaires dans le schéma GitGuardian, de sorte que le job n'exécute jamais CREATE SCHEMA :

inAppAnalytics:
  postgresql:
    applicationSchema: gitguardian
    useSeparateAnalyticsSchema: false
attention

Si vous modifiez la disposition d'une installation en cours d'exécution, le job reconstruit tout au nouvel emplacement lors de sa prochaine exécution. Les objets de la disposition précédente restent là où ils sont : supprimez-les vous-même une fois le job terminé.

Redis​

Vous pouvez utiliser le cache fourni avec l'installation embedded cluster ou apporter le vôtre pour les installations embedded et external cluster.

Compatibilité Redis

Redis Cluster n'est pas pris en charge par GitGuardian. Seul Redis Sentinel est pris en charge pour les configurations à haute disponibilité.

Type : embarqué/externe​

Le Redis embarqué ne nécessite aucune configuration supplémentaire. Il est parfait pour les tests et les instances de petite taille. Il ne fournit pas de haute disponibilité. Pour les sauvegardes, reportez-vous à la page de sauvegarde.

Le Redis externe nécessite d'avoir un cache externe configuré (par exemple avec Elasticache sur AWS). C'est la configuration recommandée pour les déploiements à grande échelle. La mise à l'échelle, la haute disponibilité et les sauvegardes doivent être gérées avec les outils du fournisseur.

Installation via KOTS​

Configuration externe​

Pour un Redis externe, vous disposez des options de configuration suivantes :

  • Host : l'IP ou le nom d'hôte de votre Redis. Par défaut « redis ».
  • Port : le port sur lequel Redis écoute. Par défaut « 6379 ».
  • Username : l'utilisateur utilisé pour se connecter au cache. Peut être laissé vide.
  • Password : le mot de passe utilisé pour se connecter au cache. Obligatoire.
  • Use TLS : case à cocher pour spécifier comment communiquer avec Redis.

Configuration externe Redis Sentinel​

Pour un Redis Sentinel externe, vous disposez des options de configuration suivantes :

  • Host : liste séparée par des virgules des hôtes Redis Sentinel.
  • Port : le port sur lequel Redis écoute. Par défaut « 6379 ».
  • Master Service Name : le nom du Set maître. Obligatoire.
  • Master Username : l'utilisateur maître utilisé pour se connecter au cache. Peut être laissé vide.
  • Master Password : le mot de passe maître utilisé pour se connecter au cache. Obligatoire.
  • Sentinel Username : l'utilisateur sentinel utilisé pour se connecter au cache. Peut être laissé vide.
  • Sentinel Password : le mot de passe sentinel utilisé pour se connecter au cache. Obligatoire.
info

TLS n'est pas pris en charge avec Redis Sentinel.

Lorsque vous utilisez Redis Sentinel pour la haute disponibilité, assurez-vous que le mot de passe maître Redis correspond au mot de passe du sentinel Redis. Par défaut, Sentinel fonctionne sur le port TCP « 26379 ».

Installation via Helm​

Lors de l'installation via Helm, les paramètres seront transmis via un fichier YAML.

Configuration du serveur Redis externe​

Vous pouvez transmettre l'URL entière directement, ou fournir host, username, password et port individuellement. L'URL sera composée de la manière suivante :

redis(s)://$user:$password@$host:$port

De plus, le password et l'url doivent être transmis en ligne ou via un secret Kubernetes existant. Il est préférable d'utiliser des secrets plutôt que de définir des paramètres sensibles en ligne dans les values.

Si vous choisissez la première option, créez un secret Kubernetes dans votre cluster contenant soit l'URL, soit le mot de passe de votre Redis, et référencez-le comme le existingSecret dans votre fichier de values.

kubectl create secret generic gitguardian-redis-secret \
  --from-literal=REDIS_URL=my_redis_url

Si vous avez l'intention d' activer TLS pour votre Redis, le secret contenant le mot de passe doit également contenir les informations TLS.

En fonction de vos choix, votre fichier YAML doit contenir l'un des éléments suivants :

Paramètre sensible dans un secret (préféré)Paramètre sensible en ligne
URL transmise directement
redis:
  main:
    existingSecret: 'gitguardian-redis-secret'
    existingSecretKeys:
      url: 'REDIS_URL'
redis:
  main:
    url: 'redis://:redis_password@123.456.789.123:6379'
URL recomposée à partir d'éléments
redis:
  main:
    user: 'redis_user'
    host: '123.456.789.123'
    port: 6379
    existingSecret: 'gitguardian-redis-secret'
    existingSecretKeys:
      password: 'REDIS_PASSWORD'
redis:
  main:
    user: 'redis_user'
    host: '123.456.789.123'
    port: 6379
    password: 'redis_password'

Configuration externe Redis Sentinel​

Sous redis.main, vous devez configurer user, password. Ces identifiants appartiennent au maître.

Sous redis.main.sentinel, vous devez configurer enabled, url, user, password et masterServiceName.

info

TLS n'est pas pris en charge avec Redis Sentinel.

De plus, les deux champs password et l'url doivent être transmis via un secret Kubernetes, bien qu'il soit possible de les transmettre en ligne, ou via un secret externe. Il est préférable d'utiliser des secrets plutôt que de définir des paramètres sensibles en ligne dans les values.

Si vous choisissez la première option, créez un secret Kubernetes dans votre cluster contenant soit l'URL, soit le mot de passe de votre Redis, et référencez-le comme le existingSecret dans votre fichier de values.

kubectl create secret generic gitguardian-redis-secret \
  --from-literal=REDIS_URL=my_redis_url

Si vous avez l'intention d' activer TLS pour votre Redis, le secret contenant le mot de passe doit également contenir les informations TLS.

En fonction de vos choix, votre fichier YAML doit contenir l'un des éléments suivants :

Paramètre sensible dans un secret (préféré)Paramètre sensible en ligne
Sentinel
redis:
  main:
    existingSecret: gitguardian-redis-secret
    existingSecretKeys:
      password: redis-password
      sentinel:
        url: redis-sentinel-url
        password: redis-password
    sentinel:
      enabled: true
      masterServiceName: gitguardian-redis
redis:
  main:
    password: 'redis_password'
    sentinel:
      enabled: true
      url: 123.456.789.123:26379
      password: 'redis_sentinel_password'
      masterServiceName: gitguardian-redis

Deuxième instance Redis pour le cache de commits​

Vous pouvez configurer une deuxième instance Redis qui sera dédiée à la fonctionnalité de cache de commits.

Le cache de commits permet de meilleures performances pour les scans en temps réel et historiques en conservant les résultats des commits déjà scannés dans un cache.

Vous pouvez configurer une deuxième instance Redis qui sera dédiée à la fonctionnalité de cache de commits. Nous ne recommandons cette option que pour les grandes instances (plus de 100 Go de code pour l'ensemble du périmètre) où le cache de commits doit être configuré avec un minimum de 16 Go.

Cette deuxième instance Redis a les mêmes options de configuration que la principale.

Sur les installations via KOTS, vous pouvez accéder aux options de configuration en cochant la case Commit cache Redis dans la section Redis de la KOTS Admin Console.

Sur les installations via Helm, vous pouvez configurer cette option sous les clés redis.commitCache dans votre fichier de values.

ClickHouse​

Certaines fonctionnalités nécessitent ClickHouse, utilisé pour les analytics à grande échelle. Contrairement à PostgreSQL et Redis, il n'existe pas d'option « apportez votre propre ClickHouse externe » : ClickHouse est fourni et déployé dans le cadre du chart Helm GitGuardian. Ce que vous configurez, ce sont ses volumes persistants locaux et son backend de stockage d'objets (compatible S3, Azure Blob Storage ou GCS) : voir Stockage ClickHouse.

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