Gérez vos identifiants CI/CD avec GitLab Secrets Manager

Mise à jour du 20 août 2026 : GitLab Secrets Manager est désormais disponible en accès limité sous forme de module d'extension payant facturé via les GitLab Credits. Il injecte des secrets de pipeline au niveau des jobs et fonctionne désormais également en dehors de l'intégration continue (CI), dans Kubernetes, l'Infrastructure as Code ou via l'API. Essayez-le dès maintenant sur GitLab.com.

De nombreuses fuites d'identifiants commencent par un développeur qui a besoin d'un identifiant, ne sait pas où le stocker et improvise. Ce dernier se retrouve dans une variable CI/CD trop permissive, un fichier de configuration ou un .env validé « temporairement ».

GitLab Secrets Manager conserve les identifiants dans la même plateforme qui exécute votre code et vos pipelines. Chaque secret est limité aux jobs qui en ont besoin et régi par les contrôles d'accès que vous utilisez déjà. Résultat : moins de secrets se retrouvent au mauvais endroit, et si l'un d'eux fuite, les équipes de sécurité et d'ingénierie subissent moins de perturbations.

Lieux de stockage habituels des secrets

Les équipes de développement ont souvent le réflexe de placer les secrets dans des variables CI/CD. Il suffit de définir la variable au niveau du projet ou du groupe, de masquer la valeur et de mettre à jour le pipeline. La valeur est alors injectée dans chaque job, et toute personne ayant accès au pipeline peut la lire. Ce schéma inverse le principe du moindre privilège, mais maintient le build.

Pour y remédier, la solution habituelle est un coffre-fort autonome. Si cette approche permet d'éviter que les secrets ne soient stockés dans la configuration CI/CD, elle ajoute une charge opérationnelle permanente : un autre système à authentifier, un autre modèle d'accès à maintenir et un autre flux d'audit à corréler lors d'un incident.

Essayez GitLab Secrets Manager dans vos projets et pipelines existants

GitLab Secrets Manager est une fonctionnalité native de GitLab, construite sur OpenBao. Elle fait déjà partie de votre plateforme GitLab, de sorte que les identifiants restent dans la structure de vos projets et groupes existants.

Les équipes de développement peuvent déplacer un secret hors des variables CI/CD en le déclarant dans .gitlab-ci.yml avec le mot-clé secrets: :

      deploy:
  secrets:
    DATABASE_PASSWORD:
      gitlab_secrets_manager:
        name: db-password
  script:
    - deploy --password $DATABASE_PASSWORD

    

Par défaut, GitLab écrit le secret dans un fichier temporaire et fournit son chemin sous forme de variable d'environnement limitée à ce job. Transmettre le chemin plutôt que la valeur peut réduire l'exposition dans les sous-processus, les vidages mémoire et la télémétrie.

Le modèle d'accès que vous utilisez déjà

Un gestionnaire de secrets autonome vous oblige à maintenir deux modèles d'accès en parallèle. Les équipes, applications et périmètres de permission que vous avez déjà modélisés dans GitLab doivent être reconstruits dans l'outil de gestion des secrets, et maintenus à jour au fil des arrivées, des changements de rôle et des départs. Lorsque les deux systèmes divergent (les identifiants d'un ingénieur parti persistent ou une application accumule des accès dont elle n'a plus besoin), les écarts deviennent exploitables.

GitLab Secrets Manager utilise la structure de vos groupes et projets existants comme frontière d'isolation pour les secrets, sans structure séparée à construire et à maintenir. Vous définissez les autorisations de lecture, de création, de mise à jour et de suppression par utilisateur, groupe ou rôle, en utilisant les mêmes contrôles que pour le code. Les secrets créés au niveau du groupe sont disponibles pour chaque projet rattaché, de sorte que les identifiants communs sont définis une seule fois et hérités là où ils sont nécessaires. Lorsqu'une personne quitte le projet ou en est retirée, elle perd immédiatement l'accès à ses secrets.

Identifiants de projet stockés dans GitLab Secrets Manager

Chaque secret limité au job qui en a besoin

Lorsque le paquet npm Axios a été compromis en mars, les organisations utilisant une version malveillante ont dû agir comme si chaque identifiant touché par leurs pipelines se trouvait entre les mains d'un attaquant. Elles se sont précipitées pour procéder à une rotation des secrets exposés et auditer chaque système que ces secrets pouvaient atteindre.

Plus la portée d'un secret est large, plus la remédiation est coûteuse en cas d'exposition, et c'est aux équipes de développement d'absorber ce coût aux côtés de l'équipe de sécurité, sous forme de merges bloqués et de builds en échec. Réduire la portée des secrets limite le nettoyage aux systèmes que l'identifiant compromis était réellement autorisé à atteindre.

GitLab Secrets Manager limite le rayon d'impact des secrets compromis en restreignant chaque identifiant au job qui en a besoin. Il détermine quels jobs peuvent effectuer un pull d'un secret donné en fonction de trois attributs du job : l'environnement qu'il cible, la branche sur laquelle il s'exécute et la protection de cette branche. Les caractères génériques s'appliquent à l'environnement et à la branche, vous n'avez donc pas à énumérer chaque cas. Comme les portées sont définies par des attributs de job que GitLab suit déjà, il n'y a pas de second système à réconcilier avec votre pipeline.

Lorsqu'un job s'exécute, il demande la valeur du secret dont il a besoin. Le backend des secrets vérifie l'identité du job, puis contrôle sa branche et son environnement par rapport aux règles de portée avant de transmettre la valeur. Vous pouvez combiner des conditions, de sorte qu'une seule règle peut exiger qu'un job s'exécute sur une branche protégée et cible un environnement en production/* avant de recevoir des identifiants. Lorsque le job se termine, le secret est supprimé. Rien ne persiste sur le runner, et les job logs sont masqués. Une variable CI/CD, en revanche, reste lisible dans la configuration de votre projet indéfiniment.

Suivre un secret jusqu'à son pipeline

Lorsqu'un secret fuite ou qu'une dépendance est compromise, les équipes doivent retracer l'identifiant à travers tous les pipelines et jobs qui l'ont utilisé. Cela déclenche un processus urgent qui consiste à recouper les logs provenant du système CI, de l'outil de gestion des secrets, du fournisseur d'identité et de partout ailleurs où l'identifiant a été utilisé.

GitLab Secrets Manager enregistre les événements de création, de mise à jour et de suppression pour les secrets au niveau du projet et du groupe dans le même journal d'audit que le reste de la plateforme, de sorte que les modifications de votre inventaire de secrets coexistent avec le reste de votre registre de gouvernance. Les lectures de secrets depuis les pipelines CI/CD sont diffusées sous forme d'événements d'audit avec les identifiants du pipeline et du job d'origine afin que les équipes puissent retracer l'utilisation d'un secret sans corréler manuellement des données entre systèmes. La journalisation d'audit est disponible dès aujourd'hui sur les déploiements auto-gérés, avec la prise en charge de GitLab.com attendue pendant la version bêta publique.

GitLab Secrets Manager en action

Essayez GitLab Secrets Manager dès aujourd'hui !

GitLab Secrets Manager est disponible en accès limité sous forme de module d'extension payant facturé via les GitLab Credits pour les utilisateurs GitLab Premium et GitLab Ultimate sur GitLab.com. GitLab Secrets Manager est en version bêta pour les déploiements auto-gérés, et la prise en charge de GitLab Dedicated sera bientôt disponible.

Sur GitLab.com, créez votre premier secret. Sur les déploiements auto-gérés, suivez les étapes d'installation et découvrez comment utiliser GitLab Secrets Manager en tant que développeur.

Nos intégrations pour HashiCorp Vault, AWS Secrets Manager, Azure Key Vault et Google Cloud Secret Manager fonctionnent aux côtés de GitLab Secrets Manager, vous pouvez donc l'adopter à votre propre rythme.

En savoir plus sur GitLab 19.0

• Release de GitLab 19.0
• Plus de modèles d'IA pour GitLab Duo Agent Platform Self-Hosted
• Transformez les merge requests de tâches manuelles en workflow automatisé
• Suivez l'utilisation des composants CI dans votre organisation