GitLab Secrets Manager : gérez vos secrets comme votre code

Les identifiants sont souvent créés dans les environnements de développement locaux des ingénieurs, puis copiés dans des variables CI/CD sans portée définie afin d'assurer le bon fonctionnement des pipelines. Stockée sous forme de valeur brute plutôt que de référence à un secret à portée limitée, une clé de signature est accessible à tous les jobs du pipeline, qu'il soit compromis ou non.

Mettre en place un coffre-fort autonome réduit cette exposition, mais exige de répercuter chaque modification apportée aux membres du projet, aux branches protégées et aux environnements de production. Lorsque le coffre-fort n'est plus synchronisé, un pipeline échoue ou le compte de service d'un agent conserve un accès dont il n'a plus besoin.

GitLab Secrets Manager renforce la sécurité des identifiants sans nécessiter un second modèle d'autorisations. Il est désormais en disponibilité générale dans GitLab 19.5 pour les abonnements GitLab Premium et GitLab Ultimate sur GitLab.com et GitLab Self-Managed, et le sera prochainement pour GitLab Dedicated. Basé sur OpenBao, il stocke les identifiants de build et d'exécution sous les mêmes autorisations et avec la même piste d'audit que votre code. Les équipes plateforme peuvent proposer aux équipes de développement un accès en libre-service aux secrets, tandis que les équipes sécurité disposent d'identifiants limités aux jobs qui les utilisent, ainsi que de l'identifiant du pipeline et du job à chaque lecture CI/CD.

« GitLab Secrets Manager nous permet de centraliser les secrets dans le CI/CD, Kubernetes et l'Infrastructure as Code sans avoir à déployer plusieurs coffres-forts ni à gérer des points d'intégration distincts. Il renforce également la sécurité de notre chaîne d'approvisionnement en limitant l'accès aux identifiants à certains utilisateurs et pipelines. » - Jeremy Nauta, Software Architect, OneTrust

Comment Secrets Manager limite l'accès aux secrets lors du build à chaque job

Les agents peuvent effectuer des actions imprévisibles ; les équipes sécurité doivent donc considérer chaque job comme si ses agents allaient utiliser n'importe quel identifiant à leur portée. GitLab Secrets Manager restreint ce périmètre grâce au contexte dont dispose déjà GitLab pour chaque job : son projet, la branche sur laquelle il s'exécute, si cette branche est protégée et l'environnement qu'il cible.

Un développeur déclare le secret dont un job a besoin via le mot-clé secrets: dans le fichier .gitlab-ci.yml, et GitLab injecte la valeur uniquement dans les jobs qui la déclarent et entrent dans son champ d'application. Les conditions de portée acceptent des caractères génériques sur la branche et l'environnement, et se combinent : une règle peut ainsi exiger une branche protégée et un environnement de production/* avant qu'un job reçoive l'identifiant.

À l'intérieur du job, GitLab écrit la valeur dans un fichier temporaire et n'expose que son chemin d'accès, ce qui limite son exposition dans les sous-processus, les crash dumps et les données de télémétrie. GitLab masque la valeur dans les job logs et la supprime à la fin du job. Contrairement à une variable CI/CD, un secret n'est jamais lisible dans la configuration de votre projet. OpenBao chiffre les secrets au repos avec AES-256-GCM, de sorte qu'une copie de la base de données des secrets ne contient que du texte chiffré. Les jobs récupèrent les valeurs directement depuis OpenBao avec des jetons à durée de vie limitée associés à l'identité de chaque job, ce qui permet d'éviter que les secrets en clair ne se retrouvent dans l'application GitLab.

Découvrez comment démarrer avec GitLab Secrets Manager :

Révoquer et tracer un identifiant exposé

Lorsque le paquet npm axios a été compromis, un avis du SANS a recommandé aux équipes de « partir du principe que toutes les variables d'environnement des systèmes affectés avaient été exfiltrées » et d'étendre leurs investigations aux runners CI/CD et à l'infrastructure de build. Les équipes de réponse aux incidents ont dû déterminer quels identifiants chaque job affecté pouvait lire, comment en bloquer l'accès et quelles exécutions les avaient consultés.

Avec GitLab Secrets Manager, lorsqu'un job exécute une dépendance compromise, l'exposition se limite aux secrets que ce job a déclarés et était autorisé à lire. Pour remédier à ce type d'incident, il suffit de révoquer et de remplacer l'identifiant compromis, de mettre à jour la valeur dans GitLab Secrets Manager et d'auditer ce job pendant que les autres pipelines continuent de fonctionner. GitLab Secrets Manager vous permet de définir un rappel de rotation lors de la création d'un secret. Les identifiants dynamiques seront bientôt disponibles et fourniront un accès éphémère sans rotation manuelle.

GitLab transmet chaque événement de création, de lecture, de mise à jour et de suppression de secret vers vos destinations d'événements d'audit et enregistre les modifications dans la piste d'audit. Chaque lecture de pipeline inclut les identifiants du pipeline et du job, qui sont liés au commit, à l'utilisateur déclencheur et à la merge request, le cas échéant. Les équipes de réponse aux incidents et les auditeurs peuvent remonter d'une lecture jusqu'à la modification qui en est à l'origine, sans avoir à corréler les logs d'un système CI, d'un coffre-fort et d'un fournisseur d'identité. Les événements d'audit ne contiennent jamais les valeurs des secrets.

Gérer les secrets avec les autorisations qui régissent votre code

À mesure que les agents prennent en charge davantage de tâches, les équipes plateforme reçoivent de plus en plus de demandes concernant des pipelines et des comptes de service nécessitant des identifiants. Lorsque ces demandes s'accumulent, les équipes ont tendance à recourir à des autorisations générales et à des secrets partagés.

GitLab Secrets Manager utilise l'espace de nommage de GitLab comme limite d'isolation. Les projets héritent des secrets définis dans les groupes qui leur sont supérieurs ; vous ne définissez donc une information d'identification partagée qu'une seule fois. Les propriétaires accordent des autorisations de lecture, d'écriture et de suppression à des utilisateurs spécifiques ou à des rôles par défaut, en utilisant le même modèle d'appartenance que celui qui régit le code. Supprimez une personne ou le compte de service d'un agent d'un projet, et l'accès de cette identité aux secrets du projet prend fin.

Les équipes de développement accèdent aux secrets via les droits d'accès au projet dont ils disposent déjà. Lorsqu'une référence à un secret est rompue, ils la corrigent dans la même merge request que le code, sans avoir besoin d'un deuxième dépôt, d'un approbateur ou d'un ticket d'accès. Avec un identifiant géré à portée de main, moins de secrets se retrouvent dans des variables CI/CD trop larges, des fichiers locaux ou le dépôt.

Un store unique pour les pipelines et les charges de travail d'exécution

Kubernetes, Terraform et les scripts disposent souvent de stores de secrets distincts, chacun avec son propre modèle d'accès et ses propres logs. GitLab Secrets Manager alimente les outils d'exécution à partir du même store que les pipelines, sous les mêmes autorisations et la même piste d'audit :

• Kubernetes, via l'External Secrets Operator (ESO). L'ESO récupère à nouveau le secret à un intervalle défini et met à jour le secret Kubernetes en place, de sorte qu'une valeur ayant fait l'objet d'une mise à jour parvienne au cluster sans qu'il soit nécessaire d'exécuter un pipeline.
• Terraform et OpenTofu. Ils lisent un secret en tant que source de données au moment de la planification ou de l'application et évitent d'inclure les identifiants dans les fichiers .tfvars et les variables CI/CD.
• OpenBao et les CLI de Vault, via l'API compatible avec Vault. Les équipes conservent leurs scripts existants et les orientent vers GitLab Secrets Manager.
• D'autres outils d'exécution, via l'API de GitLab Secrets Manager.

Chaque outil d'exécution s'authentifie à l'aide d’un compte de service ou d'un jeton d'accès, et cette identité nécessite une appartenance au projet ainsi qu'une autorisation de lecture explicite pour le secret. GitLab émet alors un jeton distinct, valable cinq minutes, que l'outil utilise pour le récupérer.

Comment GitLab Secrets Manager s'intègre aux contrôles de la chaîne d'approvisionnement de GitLab

L'usine logicielle gouvernée de GitLab connecte le code, les pipelines, les paquets et les secrets sur une seule plateforme, avec un modèle d'identité et un historique uniques de la façon dont une modification a été déployée en production. GitLab Dependency Firewall détermine quels paquets entrent dans un pipeline, GitLab Secrets Manager limite les identifiants auxquels le pipeline peut accéder, et GitLab Artifact Central gouverne ce que vous livrez.

GitLab Secrets Manager prend en charge deux des cinq étapes du GitLab Security Standard, le framework de GitLab permettant aux agents de gagner en autonomie : pour l'étape Authorize, il lie chaque job aux secrets que son identité et sa portée autorisent ; pour l'étape Respond, il transmet chaque événement CRUD.

La protection contre la publication de secrets bloque les commits contenant des identifiants avant qu'ils n'atteignent le dépôt, tandis que la détection des secrets identifie ceux qui se trouvent déjà dans votre code et votre historique. GitLab Duo Agent Platform trie les résultats de ces analyses et signale les faux positifs potentiels, afin que votre équipe ne révoque, ne renouvelle et n'audite que les véritables fuites.

Les intégrations existantes de GitLab pour HashiCorp Vault, AWS Secrets Manager, Azure Key Vault et Google Cloud Secret Manager continuent de fonctionner aux côtés de GitLab Secrets Manager, ce qui vous permet de migrer à votre propre rythme.

Démarrer

GitLab Secrets Manager est un module d'extension payant pour les abonnements GitLab Premium et GitLab Ultimate, facturé via GitLab Credits : 1 crédit par secret stocké par mois et 1 crédit par 2 500 opérations de lecture. Un contrat de licence entreprise est disponible pour les environnements air-gapped.

• Sur GitLab.com, les propriétaires de groupe principal peuvent essayer GitLab Secrets Manager gratuitement pendant 30 jours ou 500 crédits d'évaluation, selon la première échéance. Accédez à votre groupe principal, sélectionnez Sécurisation > Gestionnaire de secrets, puis Démarrer l’essai de 30 jours.
• Sur GitLab Self-Managed, votre administrateur doit installer et activer GitLab Secrets Manager, en suivant les recommandations documentées en matière de dimensionnement et de haute disponibilité.
• La prise en charge de GitLab Dedicated sera bientôt disponible.

Pour identifier les premiers identifiants à migrer, exécutez l'outil d'audit des secrets pour les variables CI/CD, qui signale les variables susceptibles de contenir des identifiants. Un workflow de migration pour les variables CI/CD est en cours de développement.

Vous avez des suggestions ou des retours ? Partagez-les dans le ticket dédié à GitLab Secrets Manager.