Aller au contenu principal

Configurer votre base de données

Ce guide vous aidera à configurer votre base de données. Les paramètres présentés 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 de l'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.

Intégrée versus externe​

Le PostgreSQL intégré ne nécessite aucune configuration supplémentaire. Il est idéal pour les tests et les instances de petite taille. Il ne fournit pas de haute disponibilité. Pour les sauvegardes, consultez la page de sauvegarde.

Le PostgreSQL externe nécessite la mise en place d'une base de données externe (par exemple avec RDS sur AWS). Il s'agit de 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 des tests, vous pouvez utiliser les presets helm-pg-redis-poc. Ils fournissent des configurations Helm Small/Medium/Large prêtes à l'emploi, alignées sur le guide Mise à l'échelle. Pour la production, privilégiez les services managés de votre fournisseur cloud.

Configuration intégrée​

info

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

Le PostgreSQL intégré 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ôts de s'exécuter 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. La valeur par défaut est « postgres ».
  • Port : le port sur lequel PostgreSQL écoute. La valeur par défaut est « 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. La valeur par défaut est « 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, consultez les prérequis matériels pour les embedded clusters ou les existing clusters.

Installation via Helm​

L'installation 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 de 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. L'utilisation de secrets devrait être privilégiée par rapport à la définition de 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érez-vous au secret comme au 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 deuxième 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 dedans.

    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 avoir les 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;

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 de haute disponibilité.

Type : intégré/externe​

Le Redis intégré ne nécessite aucune configuration supplémentaire. Il est idéal pour les tests et les instances de petite taille. Il ne fournit pas de haute disponibilité. Pour les sauvegardes, consultez la page de sauvegarde.

Le Redis externe nécessite la mise en place d'un cache externe (par exemple avec Elasticache sur AWS). Il s'agit de 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. La valeur par défaut est « redis ».
  • Port : le port sur lequel Redis écoute. La valeur par défaut est « 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 de Redis Sentinel​

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

  • Host : liste de hôtes Redis Sentinel séparés par des virgules.
  • Port : le port sur lequel Redis écoute. La valeur par défaut est « 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 de 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 complète 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. L'utilisation de secrets devrait être privilégiée par rapport à la définition de 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érez-vous à celui-ci comme au 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.

Selon 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 de 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. L'utilisation de secrets devrait être privilégiée par rapport à la définition de 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érez-vous à celui-ci comme au 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.

Selon 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 dispose des mêmes options de configuration que l'instance 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 Console d'administration KOTS.

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 l'analytique à grande échelle. Contrairement à PostgreSQL et Redis, il n'existe pas d'option « apporter votre propre ClickHouse externe » : ClickHouse est fourni et déployé dans le cadre du Helm chart GitGuardian. Ce que vous configurez, ce sont ses volumes persistants locaux et son backend de stockage objet (compatible S3, Azure Blob Storage ou GCS) : consultez 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