SCOP d'ingénieurs experts du logiciel libre depuis 2004
+33 1 70 61 60 16

Notre guide pour sécuriser votre instance GitLab

Sécurisez votre instance GitLab auto-hébergée grâce à des conseils pratiques sur les mises à jour, l'authentification, la gestion des permissions et les pipelines CI/CD.
DevSecOps : sécurisez vos instances GitLab

Notre prochain webinar

GitLab est une excellente alternative Open Source et souveraine aux Bitbucket et autres GitHub, c'est aussi l’une des forges logicielles les plus utilisées ; l’accessibilité du code source de nombreux projets logiciels repose sur lui.

Convaincu par cette solution, vous avez choisi d’héberger vous-même votre instance GitLab et, depuis, une question revient régulièrement et vous taraude : Ma forge logicielle est-elle correctement sécurisée ?

La sécurité de GitLab est un sujet qui génère souvent de l’anxiété et de l’incertitude. Plusieurs raisons expliquent cela :

  • GitLab gère des données sensibles (votre code…).
  • GitLab est une application avec un périmètre fonctionnel vaste et une base de code importante.
  • Le rythme de mise à jour de GitLab est rapide.
  • En tant qu’application Open Source, GitLab peut parfois inquiéter certains responsables.

Aujourd’hui, nous vous proposons de nous pencher sur la sécurisation de votre forge logicielle GitLab auto-hébergée.

Peut-être dormirez-vous un peu mieux après avoir lu nos conseils, mais pour une sérénité maximale, nous vous recommandons de confier vos instances à un expert.

Mises à jour et maintenance

Si vous suivez notre flux Twitter, vous savez que le rythme des mises à jour de GitLab est assez élevé. GitLab publie une version stable (XX.YY.0) tous les 3èmes jeudis du mois et des patchs de sécurité planifiés et non planifiés (critiques) entre deux versions stables.

Pour les curieux, voici le tableau des versions GitLab à venir à la date de cet article. Pour suivre ce calendrier et ses évolutions, rendez-vous sur la page dédiée de gitlab.com.

VersionDate de publication
17.315 août 2024
17.419 septembre 2024
17.517 octobre 2024
17.621 novembre 2024
17.719 décembre 2024
17.816 janvier 2025
17.920 février 2025
17.1020 mars 2025
17.1117 avril 2025
18.015 mai 2025

De mémoire d’ours, GitLab publie toujours un patch de sécurité entre deux versions stables, vous devez donc compter sur deux mises à jour par mois.

Ce rythme de mise à jour n’est pas déraisonnable ; il vient avec la complexité de la base de code, qui elle-même reflète les ambitions de GitLab. C’est le prix à payer pour profiter de la vision DevSecOps de GitLab Inc..

Mais vous vous dites peut-être que toutes les mises à jour ne sont pas nécessaires, qu’on peut en sauter. De notre point de vue, il est important de suivre scrupuleusement les mises à jour majeures et patchs de sécurité critiques postés par GitLab. L’équipe de Bearstech fait confiance au bon sens de GitLab et nous mettons toutes les instances de nos clients à jour dans un délai de 48 heures maximum.

Certaines mises à jour sont extrêmement critiques ; pour rappel, en 2021, une mise à jour venait corriger une faille qui avait impacté plus de 30k instances GitLab, mais si vous aviez pris du retard, cette mise à jour devenait très coûteuse à déployer.

GitLab n’est pas une application qu’on installe et qu’on oublie ; elle demande un travail continu et une attention régulière. Si vous attendez trop, les sauts de versions importants peuvent être particulièrement difficiles à gérer.

À noter : si vous avez besoin d’aide pour mettre à jour votre instance GitLab, contactez-nous.

Sécuriser l’accès à votre GitLab

Pour sécuriser vos accès, vous avez à votre disposition deux outils très importants : l’authentification à deux facteurs et l’authentification unique (SSO). Par ailleurs, ces deux outils peuvent être complémentaires.

Nous recommandons à tous les gestionnaires d’instance GitLab d’activer la 2FA parce qu’elle augmente considérablement la sécurité de vos applications. Vous n’avez a priori aucune raison de ne pas l’activer.

Si vous avez un SSO moderne, vous devriez pouvoir l’intégrer à GitLab grâce à OmniAuth. L’intégration du SSO augmente la sécurité, car les utilisateurs ne se connectent qu’une fois par jour et ne doivent pas maintenir une pléthore d’informations d’authentification.

GitLab peut aussi être le fournisseur de référence pour votre SSO, auquel cas l’activation de la 2FA est d’autant plus importante.

Si vous décidez de sauter cette étape de sécurisation des accès à votre GitLab, vous augmentez vos risques de sécurité en augmentant la simplicité et la criticité des intrusions.

Gestion des permissions

Mettez en place une stratégie de gestion des permissions stricte, incluant des règles pour les actions de push, de merge, de fork, etc.

La première tâche évidente est de restreindre les droits d’ajout de membres aux propriétaires et administrateurs.

Ensuite, pensez à limiter l’accès des projets aux utilisateurs qui en ont vraiment l’usage. Et demandez-vous toujours quels sont leurs droits dans ces projets. Vérifiez régulièrement les projets et les utilisateurs pour vous assurer que leurs permissions sont à jour.

GitLab offre une gestion très fine des droits, autant en profiter. En limitant les accès et les permissions de vos utilisateurs, vous limiterez en même temps le potentiel de nuisance d’un attaquant.

Pour résumer, à chaque nouveau compte, demandez-vous ce que l’utilisateur peut voir, modifier, copier ou créer. Cela peut paraître assez évident, mais vous devez vous en souvenir et appliquer une stratégie cohérente.

La confidentialité des informations est l’un des piliers de la cybersécurité et ne doit pas être traitée à la légère. Limiter les droits des utilisateurs à leurs fonctions, par projet, est essentiel pour limiter non seulement les actions malveillantes, mais aussi les erreurs potentielles des utilisateurs disposant de droits trop élevés.

Sécurisation des Runners et des Pipelines CI/CD

Sans mesures de sécurité adaptées, vos pipelines d’intégration continue et de déploiement continu peuvent vous exposer à des risques de sécurité.

Vous devez limiter ces risques en testant de manière approfondie et en respectant les normes de sécurité avant les déploiements en production. Pour en savoir plus sur le GitFlow et les bonnes pratiques spécifiques à cette méthodologie, n’hésitez pas à lire cet article d’Emmanuel Mazurier.

Le gestionnaire d’une instance GitLab doit s’assurer de la sécurisation des runners pour éviter l’exposition accidentelle de données sensibles.

Voici une liste de conseils à suivre pour limiter votre exposition aux risques :

  • Pensez d’abord à déployer des instances Docker en mode non privilégié, et à limiter les permissions avec cap_add/cap_drop et, dans la mesure du possible, à éviter l’utilisation de l’exécuteur Shell dans Docker.
  • Configurez des politiques de pull d’image Docker appropriées : utiliser always ou never selon le contexte pour éviter l’utilisation de versions locales non sécurisées.
  • Utilisez des machines virtuelles éphémères pour les jobs nécessitant --privileged.
  • Limitez l’accès SSH, restreignez le trafic et filtrez l’accès aux points de terminaison de métadonnées du fournisseur de cloud.
  • Pensez à la sécurité du système d’exploitation de l’hôte.
  • Activez le flag **FF_ENABLE_JOB_C

Utilisation des outils de sécurité intégrés et tiers

Rotation des secrets des intégrations tierces

La rotation des secrets des intégrations tierces est une pratique de sécurité importante qui permet d’atténuer les risques associés aux fuites de secrets, tels que les accès non autorisés et les violations de données potentielles. Vous devriez renouveler les secrets de toutes les intégrations tierces au moins une fois par an.

Détection d’intrusions

Vous pouvez mettre en place des solutions de détection d’intrusion de type Honeytokens comme Canary Tokens.

Détection des secrets

En poussant du code, vos développeurs peuvent par inadvertance publier des informations confidentielles (clefs d’API en clair) et autres secrets.

Plusieurs solutions de détection des secrets sont à votre disposition. Des solutions ad hoc existent, telles que Detect Secrets. Nous proposons de notre côté une offre SaaS de SonarQube qui offre cette fonctionnalité et qui s’intègre à votre GitLab.

Configuration sécurisée du GitLab

Bien configurer votre GitLab est évidemment très important. Notamment, pensez à configurer :

  • La Static Application Security Testing (SAST)
  • Si possible la Dynamic Application Security Testing (DAST) (disponible en version Ultimate).
  • L’option asset proxy pour le téléchargement de ressources extérieures.

En bref et pour finir

Sécuriser votre instance GitLab auto-hébergée est essentiel pour protéger vos données sensibles et assurer la continuité de vos opérations. En suivant rigoureusement les mises à jour, en activant l’authentification à deux facteurs (2FA) et l’intégration SSO, en gérant strictement les permissions d’accès, en sécurisant vos pipelines CI/CD, et en utilisant les outils de sécurité intégrés et tiers, vous réduisez significativement les risques de vulnérabilité.

Gardez à l’esprit que GitLab n’est pas un outil à installer puis oublier ; il nécessite une attention continue.

Pour une tranquillité maximale, envisagez de confier vos instances à un expert.


L'équipe Bearstech

Inscrivez-vous à notre newsletter

Mieux comprendre le monde du DevOps et de l'administration système.

Abonnez-vous à notre newsletter

Hébergement & Infogérance

  • ✓ Service Astreinte 24h/7j/365
  • ✓ Supervision, monitoring & Alertes
  • ✓ Mises à jour en continu
  • ✓ Certificat SSL letsencrypt
  • ✓ Hébergement dédié sécurisé en France
  • ✓ Backup vers datacenter distant
Découvrir notre offre

Expertise Technologique

Notre équipe possède une vaste expertise technologique.