Aller au contenu principal

Configurer votre base de données

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

attention

Si vous utilisez des bases de données externes, n'oubliez pas d'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 existing cluster. Nous vous encourageons à utiliser une base de données externe.

Embedded versus externe​

Le PostgreSQL embedded ne nécessite aucune configuration supplémentaire. Il est idéal pour les tests et les petites instances. Il n'offre 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 d'un PoC sur un cluster existant

Si vous souhaitez exécuter PostgreSQL et Redis dans 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 prêtes à l'emploi Small/Medium/Large alignées avec le guide Scaling. Pour la production, préférez les services managés de votre fournisseur cloud.

Configuration embedded​

info

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

Le PostgreSQL embedded est un PostgreSQL 16 fonctionnant sur un seul pod.

attention

Si vous utilisez PgBouncer, ajoutez ce qui suit au fichier pgbouncer.ini pour permettre aux tâches de 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 : PgBouncer Configuration

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. Requis.
  • Password : le mot de passe utilisé pour se connecter à la base de données. Requis.
  • 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, consultez les exigences matérielles pour les embedded clusters ou les clusters existants.

Installation basée sur 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 si pertinent
  • database
  • port (5432 sera utilisé par défaut)
astuce

Pour garantir 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 être défini dans un secret Kubernetes, ou défini en ligne comme les autres paramètres. L'utilisation de secrets doit être privilégiée par rapport à la définition de paramètres sensibles en ligne dans les valeurs.

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 comptez 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 en tant que paramètre postgresql.existingSecret. La clé du mot de passe dans ce secret doit être définie en tant que 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 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, index, triggers et 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 existing 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 : embedded/externe​

Le Redis embedded ne nécessite aucune configuration supplémentaire. Il est idéal pour les tests et les petites instances. Il n'offre 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 basée sur 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. Requis.
  • Use TLS : case à cocher pour spécifier comment communiquer avec Redis.

Configuration de Redis Sentinel externe​

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. Requis.
  • 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. Requis.
  • 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. Requis.
info

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

Lors de l'utilisation de Redis Sentinel pour la haute disponibilité, assurez-vous que le mot de passe maître Redis correspond au mot de passe sentinel Redis. Par défaut, Sentinel fonctionne sur le port TCP "26379".

Installation basée sur Helm​

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

Configuration du serveur Redis externe​

Vous pouvez passer 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. L'utilisation de secrets doit être privilégiée par rapport à la définition de paramètres sensibles en ligne dans les valeurs.

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 en tant que existingSecret dans votre fichier de valeurs.

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

Si vous comptez 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 de :

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 de Redis Sentinel externe​

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 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 doit être privilégiée par rapport à la définition de paramètres sensibles en ligne dans les valeurs.

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 en tant que existingSecret dans votre fichier de valeurs.

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

Si vous comptez 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 de :

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

Seconde instance Redis pour le cache de commits​

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

Le cache de commits permet d'améliorer les performances des scans en temps réel et historiques en conservant en cache les résultats des commits déjà scannés.

Vous pouvez configurer une seconde 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 seconde instance Redis dispose des mêmes options de configuration que la principale.

Sur les installations basées sur 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 basées sur Helm, vous pouvez configurer cette option sous les clés redis.commitCache dans votre fichier de valeurs.

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