Gérez vos identifiants CI/CD avec le gestionnaire de secrets de GitLab

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 ».

Le gestionnaire de secrets de GitLab, désormais en version bêta publique avec GitLab 19.0, 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 le gestionnaire de secrets dans vos projets et pipelines existants

Le gestionnaire de secrets de GitLab 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. Chaque équipe, application et périmètre de permission que vous avez déjà modélisés dans GitLab doit être reconstruit dans l'outil de gestion des secrets, et maintenu à 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.

Le gestionnaire de secrets 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 le gestionnaire de secrets de GitLab

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.

Le gestionnaire de secrets 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 chaque pipeline et job 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é.

Le gestionnaire de secrets de GitLab 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.

Voir le gestionnaire de secrets en action

Découvrir la version bêta publique

Le gestionnaire de secrets de GitLab est en version bêta publique pour les utilisateurs GitLab Premium et GitLab Ultimate sur GitLab.com et les déploiements auto-gérés, et la prise en charge de GitLab Dedicated arrivera prochainement.

Sur GitLab.com, activez la fonctionnalité et créez votre premier secret. Sur les déploiements auto-gérés, suivez les étapes d'installation et découvrez comment utiliser le gestionnaire de secrets 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 du gestionnaire de secrets de GitLab, vous pouvez donc l'adopter à votre propre rythme.

Le gestionnaire de secrets est gratuit pendant la période bêta. Une fois en disponibilité générale, il deviendra une fonctionnalité payante facturée via GitLab Credits. Vous devrez activer la fonctionnalité avant toute facturation, et nous vous préviendrons à l'avance avant la disponibilité générale.

Une fois que vous aurez testé le gestionnaire de secrets, donnez-nous votre avis afin d'aider à améliorer cette fonctionnalité avant sa mise en disponibilité générale.

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