GitLab Secrets Manager
Mettez fin à la multiplication des secrets avec GitLab Secrets Manager, basé sur OpenBao. Les secrets de pipeline et d'exécution sont lus depuis un magasin unique et régis par les autorisations et la piste d'audit qui couvrent déjà votre code.
Gérez les secrets là où vos équipes de développement travaillent déjà
Avec GitLab Secrets Manager, les secrets résident 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 second outil à maîtriser.
L'accès suit la hiérarchie existante de vos groupes et projets, et des autorisations granulaires offrent un contrôle supplémentaire : vous n'avez pas de second modèle d'accès à synchroniser. Définissez un identifiant une seule fois au niveau du projet ou partagez-le dans tout le 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. Avec des identifiants sécurisés à portée d'une seule ligne, 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, le nettoyage avec GitLab Secrets Manager consiste à effectuer la rotation et l'audit des secrets auxquels ce job pouvait accéder, et non à geler tous les pipelines.
Contrairement aux variables CI, qui atteignent chaque job du pipeline, un secret n'atteint que les jobs qui le déclarent et qui respectent sa portée : branche, environnement et statut de protection.
GitLab Secrets Manager écrit la valeur dans un fichier temporaire et n'expose que son chemin, ce qui limite l'exposition dans les sous-processus, les vidages mémoire et la télémétrie. La valeur est masquée dans les logs de job 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 consignés dans la même piste d'audit que le reste de GitLab. Les lectures depuis les pipelines comportent les ID du pipeline et du job : les équipes de réponse aux incidents et les auditeurs retracent ainsi un identifiant de l'accès au déploiement, sans 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 maintient les secrets Kubernetes synchronisés avec GitLab : les valeurs ayant fait l'objet d'une rotation se propagent sans redéploiement. Terraform et OpenTofu lisent les secrets comme source de données lors de leur exécution, ce qui évite de stocker les identifiants dans des fichiers et 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 OpenBao CLI ou Vault CLI conservent leurs commandes. Toute autre automatisation récupère les secrets via l'API GitLab Secrets Manager, sans coder les identifiants en dur ni maintenir des fichiers de variables séparés.
Les identifiants suivent les charges de travail multicloud, hybrides et sur site, sans fédération d'identités par plateforme. Déplacer une charge de travail vers un autre cloud ne nécessite pas de mettre en place un second magasin, et les secrets qui seraient autrement dispersés entre des magasins par compte et par région sont regroupés en un seul endroit.
[ PROTECTION ]
Bloquez et détectez les fuites de secretsGitLab va au-delà de la gestion des identifiants. La protection contre le push des secrets empêche les identifiants 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 qui se trouvent déjà dans le code. GitLab Duo Agent Platform trie les résultats et signale les faux positifs probables.
[ TARIFICATION ]
Ne payez que ce que vous utilisezGitLab 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 forfait fixe, un contrat de licence d'entreprise (ELA) est disponible.
// PRENEZ EN MAIN L'AVENIR
Vous êtes déjà client GitLab Premium ou GitLab Ultimate ? Les propriétaires de groupes principaux peuvent essayer GitLab Secrets Manager gratuitement pendant 30 jours ou dans la limite de 500 crédits d'évaluation, selon la première échéance atteinte.
Commencer votre essaiVotre modernisation de la sécurité
est-elle efficace à grande échelle ?
GitLab a créé ce framework de maturité en s'appuyant sur son expérience 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é et des recommandations pour passer à l'étape suivante.
Le questionnaire ne prend pas plus de 5 minutes.
Foire aux questions