GitLab Secrets Manager

Des agents plus précis, un coût en tokens réduit
Découvrez comment renforcer votre usine logicielle et permettre aux agents d'IA de gagner en autonomie sans sacrifier la sécurité.
Découvrez les dernières fonctionnalités et améliorations.
GitLab Secrets Manager
Centralisez vos secrets avec GitLab Secrets Manager, basé sur OpenBao. Les secrets de pipeline et d'exécution sont lus à partir d'un seul magasin et régis par les autorisations et la piste d'audit qui s'appliquent déjà à votre code.
Gérez les secrets là où vos équipes travaillent déjà
Avec GitLab Secrets Manager, les secrets sont stockés dans les mêmes groupes et projets que le code qui les utilise. Toute demande de secret s'intègre au workflow habituel sans plug-in, agent ni outil supplémentaire à maîtriser.
L'accès suit votre hiérarchie de groupes et de projets existante, et des autorisations à granularité fine offrent un contrôle supplémentaire. Vous n'avez donc pas à synchroniser un second modèle d'accès. Définissez un identifiant de connexion une seule fois au niveau du projet ou partagez-le à l'échelle du groupe. Toute personne qui quitte un projet perd automatiquement son accès.
Un développeur déclare le secret dont un job a besoin avec le mot-clé secrets: dans le fichier de configuration du pipeline. GitLab connaît déjà le projet, la branche et l'environnement du job : aucune identité n'est à connecter entre la CI et un coffre-fort séparé.
Lorsqu'une référence de secret ne fonctionne plus, le correctif est livré dans la même merge request que le code, sans second dépôt ni second approbateur. Comme une seule ligne suffit pour accéder à des identifiants de connexion sécurisés, moins de secrets se retrouvent dans les variables CI, les fichiers de configuration locaux ou le dépôt.
Limitez l'impact des identifiants exposés
Lorsqu'une dépendance compromise s'exécute dans un job, il suffit, avec GitLab Secrets Manager, d'effectuer la rotation et l'audit des secrets auxquels ce job avait accès, sans geler tous les pipelines.
Contrairement aux variables CI, accessibles à tous les jobs du pipeline, un secret n'est accessible qu'aux jobs qui le déclarent et qui entrent dans son périmètre : branche, environnement et statut de protection.
GitLab Secrets Manager écrit la valeur dans un fichier temporaire et n'expose que son chemin d'accès, ce qui limite l'exposition dans les sous-processus, les vidages sur incident et la télémétrie. La valeur est masquée dans les job logs et supprimée à la fin du job : rien ne persiste sur le runner.
Les événements de création, de lecture, de mise à jour et de suppression sont répertoriés dans la même piste d'audit que le reste de GitLab. Les lectures effectuées depuis les pipelines comportent les identifiants du pipeline et du job, permettant aux équipes de réponse aux incidents et aux auditeurs de suivre un identifiant de connexion depuis l'accès jusqu'au déploiement sans avoir à corréler manuellement les logs entre plusieurs systèmes.
Un magasin unique pour les pipelines, les clusters et l'infrastructure
Les pipelines lisent directement les secrets. Les charges de travail Kubernetes, les exécutions Terraform et OpenTofu, les outils CLI compatibles avec Vault et les autres automatisations se connectent via des points d'intégration standard, avec les mêmes autorisations et la même piste d'audit que les pipelines.
External Secrets Operator assure la synchronisation entre les secrets Kubernetes et GitLab, de sorte que les valeurs qui ont fait l'objet d'une rotation se propagent sans redéploiement. Terraform et OpenTofu lisent les secrets en tant que source de données lors de leur exécution, ce qui évite de stocker les identifiants de connexion dans des fichiers ou des variables CI/CD.
Basé sur OpenBao, GitLab Secrets Manager expose une API compatible avec Vault : les équipes qui utilisent déjà des scripts avec la CLI OpenBao ou Vault conservent leurs commandes. Toute autre automatisation récupère les secrets via l'API Secrets Manager, sans coder les identifiants en dur ni maintenir des fichiers de variables séparés.
Les identifiants de connexion suivent les charges de travail multicloud, hybrides et sur site sans fédération d'identité par plateforme. Le transfert d'une charge de travail vers un autre cloud ne nécessite pas la création d'un second magasin. Les secrets qui seraient autrement dispersés dans des magasins par compte et par région sont regroupés en un seul endroit.
GitLab va au-delà de la gestion des identifiants de connexion. La protection contre le push de secrets empêche les identifiants de connexion d'atteindre le dépôt, la détection côté client repère les secrets dans le texte des tickets et des merge requests et la détection des secrets dans les pipelines identifie ceux déjà présents dans le code. GitLab Duo Agent Platform hiérarchise les résultats et signale les faux positifs potentiels.
GitLab Secrets Manager est un module d'extension payant pour GitLab Premium et GitLab Ultimate, facturé via les GitLab Credits : 1 crédit par secret stocké par mois et 1 crédit pour 2 500 opérations de lecture de secrets. Si vous préférez un tarif forfaitaire, un contrat de licence d'entreprise (ELA) est disponible.
// PRENEZ EN MAIN L'AVENIR
Vous êtes déjà client GitLab Premium ou GitLab Ultimate ? Essayez GitLab Secrets Manager gratuitement pendant 30 jours ou avec 500 crédits d'évaluation, selon la première échéance.
GitLab a élaboré ce framework de maturité en s'appuyant sur son expérience acquise auprès de clients de premier plan dans leur secteur. Répondez à quelques questions sur la façon dont votre équipe gère la sécurité et la conformité pour obtenir votre score de maturité, ainsi que des recommandations pour passer à l'étape suivante.
Le questionnaire ne prendra pas plus de 5 minutes.
Elles continuent de fonctionner et aucune migration automatique n'est effectuée. Les variables CI/CD restent adaptées aux configurations non sensibles. Pour identifier les variables à migrer, utilisez l'outil d'au