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 devraient pas être modifiés après l'installation, sauf si vous savez ce que vous faites, sous peine de provoquer 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 fournie avec l'installation embedded ou apporter la vôtre, à la fois pour les installations embedded et sur cluster externe. Nous vous encourageons à utiliser une base externe.

Embedded versus externe​

Le PostgreSQL embedded ne nécessite aucune configuration supplémentaire. Il convient bien aux tests et aux instances de petite taille. Il n'offre pas de haute disponibilité. Pour les sauvegardes, consultez la page backup.

Le PostgreSQL externe nécessite d'avoir mis en place une base externe (par ex. avec RDS sur AWS). C'est la configuration recommandée pour les déploiements à grande échelle. Le scaling, la haute disponibilité et les sauvegardes doivent être gérés avec les outils du fournisseur.

Configuration embedded​

info

Si vous n'avez pas encore mis à niveau vers PostgreSQL 16, suivez 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 GitGuardian comme l'intégration de dépôts de fonctionner correctement :

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

Pour plus de détails, consultez : Configuration PgBouncer

Configuration externe​

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

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

Pour les recommandations de scaling, consultez les prérequis matériels pour les clusters embedded ou les clusters existants.

Installation via Helm​

L'installation Helm prend actuellement en charge uniquement les bases externes. Lors de l'installation via Helm, les paramètres seront passés via un fichier YAML. Les paramètres suivants doivent être définis inline :

  • host
  • username si pertinent
  • database
  • port (5432 sera utilisé par défaut)
astuce

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

Quant au mot de passe, il peut être défini soit dans un secret Kubernetes, soit inline comme les autres paramètres. L'utilisation de secrets devrait être privilégiée plutôt que de définir les paramètres sensibles inline 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 comptez activer TLS pour votre base PostgreSQL, le secret contenant le mot de passe doit aussi contenir les informations TLS. Référencez ensuite le secret via le paramètre postgresql.existingSecret. La clé donnant accès au mot de passe dans ce secret devrait être définie dans 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 devrait 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​

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

L'utilisateur précisé dans la configuration (paramètre username) devrait être le propriétaire de la base :

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 : L'utilisateur doit avoir le privilège de se connecter à la base 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 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 de 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 ou apporter le vôtre, à la fois pour les installations embedded et sur cluster externe.

Compatibilité Redis

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

Type : embedded/externe​

Le Redis embedded ne nécessite aucune configuration supplémentaire. Il convient bien aux tests et aux instances de petite taille. Il n'offre pas de haute disponibilité. Pour les sauvegardes, consultez la page backup.

Le Redis externe nécessite d'avoir mis en place un cache externe (par ex. avec Elasticache sur AWS). C'est la configuration recommandée pour les déploiements à grande échelle. Le scaling, la haute disponibilité et les sauvegardes doivent être gérés 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 hostname de votre Redis. Par défaut "redis".
  • Port : le port sur lequel Redis écoute. Par défaut "6379".
  • Username : l'utilisateur servant à se connecter au cache. Peut être laissé vide.
  • Password : le mot de passe servant à 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 des hosts Redis Sentinel séparés par des virgules.
  • Port : le port sur lequel Redis écoute. Par défaut "6379".
  • Master Service Name : le nom du Set master. Obligatoire.
  • Master Username : l'utilisateur master servant à se connecter au cache. Peut être laissé vide.
  • Master Password : le mot de passe master servant à se connecter au cache. Obligatoire.
  • Sentinel Username : l'utilisateur sentinel servant à se connecter au cache. Peut être laissé vide.
  • Sentinel Password : le mot de passe sentinel servant à 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 master de Redis correspond à celui 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 passés via un fichier YAML.

Configuration du serveur Redis externe​

Vous pouvez passer 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 devraient être passés inline ou via un secret Kubernetes existant. L'utilisation de secrets devrait être privilégiée plutôt que de définir les paramètres sensibles inline 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-y via existingSecret dans votre fichier de values.

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 aussi contenir les informations TLS.

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

Paramètre sensible dans un secret (recommandé)Paramètre sensible inline
URL passée 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 des é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 master.

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 devraient être passés via un secret Kubernetes, même s'il est possible de les passer inline ou via un secret externe. L'utilisation de secrets devrait être privilégiée plutôt que de définir les paramètres sensibles inline 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-y via existingSecret dans votre fichier de values.

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 aussi contenir les informations TLS.

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

Paramètre sensible dans un secret (recommandé)Paramètre sensible inline
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 de meilleures performances pour les 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 recommandons cette option uniquement pour les grandes instances (plus de 100 Go de code pour le périmètre complet) où le cache de commits doit être configuré avec un minimum de 16 Go.

Cette seconde instance Redis a les mêmes options de configuration que la principale.

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

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