GitLab Secrets Manager s’ouvre à Kubernetes et Terraform pour unifier la gestion des secrets

6 août 2026. GitLab annonce que son Secrets Manager sort de la seule pipeline CI/CD. Le service, propulsé par OpenBao et exposé via une API compatible Vault KV v2, sait désormais alimenter Kubernetes via l’External Secrets Operator, Terraform et OpenTofu, et toute automatisation externe via une API dédiée. C’est la fin d’un casse-tête familier : le secret éparpillé entre trois magasins que personne n’arrive à corréler.

Le problème de départ est bien connu. Une équipe maintient un coffre pour le CI/CD, un autre pour les workloads Kubernetes, un troisième — souvent des fichiers .tfvars committés par erreur — pour Terraform. Trois outils à administrer, trois modèles d’accès à synchroniser, et une piste d’audit impossible à reconstituer quand un secret fuit. La promesse de GitLab est simple : une seule source de vérité. Et cette source doit être auditable : quand un secret fuit, la première question — qui y avait accès, et depuis quand — doit trouver sa réponse en une requête, pas en trois outils.

Ce qui change réellement

Le Secrets Manager de GitLab n’est pas nouveau. Il est en bêta publique pour les clients Premium et Ultimate, et le CI/CD y accède depuis la version 19.0. Ce qui change, c’est l’ouverture au-delà de la pipeline, selon trois chemins.

D’abord, Kubernetes. L’External Secrets Operator (ESO) synchronise les secrets depuis le Secrets Manager en utilisant son provider Vault. Un workload porte un JWT à courte durée de vie, qu’ESO échange contre un token OpenBao, puis écrit la valeur dans un Secret Kubernetes natif. Le cœur de la configuration tient en deux objets :

apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
  name: gitlab-secrets-manager
  namespace: my-app
spec:
  provider:
    vault:
      server: https://secrets.gitlab.com
      path: secrets/kv
      version: v2
      namespace: org_5/group_42/project_99
      auth:
        jwt:
          path: api_jwt/cel
          role: all_api
          secretRef:
            name: gitlab-access-token
            key: token
---
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: my-secret
  namespace: my-app
spec:
  refreshInterval: 45m
  secretStoreRef:
    name: gitlab-secrets-manager
    kind: SecretStore
  target:
    name: synced-secret
  data:
    - secretKey: value
      remoteRef:
        key: explicit/<secret_name>
        property: value

Le champ namespace du SecretStore mappe la hiérarchie GitLab — organisation, groupe, projet — et borne ce que ce store peut atteindre. L’ExternalSecret récupère ensuite les valeurs toutes les refreshInterval, si bien qu’une rotation se propage sans redéploiement.

Le modèle de sécurité : des jetons courts, des périmètres stricts

Sous le capot, tout repose sur des jetons courts. Aucun workload ne détient d’identifiant permanent : GitLab frappe un JWT à durée de vie limitée, qu’ESO, Terraform ou l’API échangent contre un token OpenBao éphémère. C’est le principe de l’authentification just-in-time : la fenêtre d’exposition d’un secret volé se mesure en minutes, pas en mois.

Le namespace joue le rôle de frontière. Chaque SecretStore est borné à une hiérarchie GitLab précise — une organisation, un groupe, un projet — et ne peut lire que les secrets qui y vivent. C’est le même découpage que les permissions GitLab existantes : un projet ne voit que ses secrets, jamais ceux du voisin. Pour une équipe plateforme, cela écarte le scénario classique du coffre partagé où un token de service finit par ouvrir toutes les portes.

Terraform et OpenTofu, sans .tfvars

Le deuxième chemin vise l’IaC. Le .tfvars et le state Terraform restent deux des plus grosses sources de fuites de secrets : la valeur finit écrite sur disque ou poussée dans un dépôt. GitLab propose de lire le secret en data source, en s’authentifiant avec un JWT frappé au moment du plan ou du apply :

data "external" "gitlab_secrets_token" {
  program = ["bash", "${path.module}/scripts/mint_token.sh"]
  query = { project_id = var.gitlab_project_id }
}

provider "vault" {
  address   = data.external.gitlab_secrets_token.result.server
  namespace = data.external.gitlab_secrets_token.result.namespace
  auth_login_jwt {
    mount = data.external.gitlab_secrets_token.result.auth_path
    role  = data.external.gitlab_secrets_token.result.role
    jwt   = data.external.gitlab_secrets_token.result.jwt
  }
}

data "vault_kv_secret_v2" "my_secret" {
  mount = data.external.gitlab_secrets_token.result.mount
  name  = "${data.external.gitlab_secrets_token.result.secrets_path}/<secret_name>"
}

output "secret_value" {
  value     = data.vault_kv_secret_v2.my_secret.data["value"]
  sensitive = true
}

Rien ne transite par une variable CI/CD ni par un fichier local : le secret est lu à l’exécution, puis exposé en sortie sensitive. Le troisième chemin, l’API du Secrets Manager, couvre tout le reste — un script, un opérateur maison, un outil d’observabilité — qui devait jusqu’ici recopier des identifiants en dur.

Ce que ça coûte, et ce que ça impose

Le modèle économique mérite d’être lu avant de s’engager. Le Secrets Manager est gratuit pendant la bêta ; à la disponibilité générale, ce sera une fonctionnalité payante, facturée via les GitLab Credits, avec un opt-in explicite et un préavis. La disponibilité couvre GitLab.com et le Self-Managed ; GitLab Dedicated suivra.

L’architecture repose sur OpenBao, le fork communautaire de Vault né après le changement de licence de HashiCorp. En pratique, tout outil qui parle Vault — le CLI vault, ESO, les providers Terraform — peut s’y brancher. C’est à la fois la force du produit et sa limite : GitLab ne réinvente pas la roue, il standardise sur une API déjà largement déployée, ce qui réduit la friction d’adoption mais aussi la différenciation face à un Vault ou un OpenBao auto-hébergé.

Pourquoi OpenBao, et ce que ça change pour vous

Le choix d’OpenBao n’est pas un détail. Quand HashiCorp a basculé Vault sous licence BUSL, une partie de la communauté a forké le projet pour créer OpenBao, resté sous licence MPL-2.0. En standardisant son Secrets Manager sur une API compatible Vault KV v2, GitLab évite deux écueils : réinventer un protocole maison, et dépendre d’une licence que certains clients jugent restrictive.

Conséquence pratique : tout l’écosystème Vault existant — le CLI, les providers Terraform, ESO, les SDK — fonctionne tel quel. Vous ne formez pas vos équipes à un nouvel outil, vous branchez ce qu’elles connaissent déjà. Face à un OpenBao auto-hébergé, GitLab n’apporte pas de capacité secrète supplémentaire : il apporte l’intégration et la disparition d’un serveur à opérer.

Migrer sans tout casser

Le piège d’un tel outil, c’est de vouloir tout basculer d’un coup. Ne le faites pas. La séquence prudente tient en trois temps : inventorier les secrets et leurs consommateurs, basculer par périmètre — commencez par un projet non critique, branchez ESO puis Terraform —, et cohabiter quelques semaines, l’ancien magasin et le nouveau tournant en parallèle.

Un point souvent oublié : la sortie. Le jour où GitLab facturera la fonctionnalité, ou le jour où vous changerez d’avis, il faudra pouvoir revenir en arrière. Documentez la provenance de chaque secret — où il est stocké, qui le lit, à quelle fréquence — avant même de migrer. Un secret dont on a perdu la trace est un secret qu’on ne peut plus faire tourner sans casse.

Le verdict à froid

Si vous êtes déjà sur GitLab Premium ou Ultimate et que vous jonglez entre plusieurs magasins de secrets, la consolidation vaut le détour : vous supprimez un outil à administrer, et surtout vous retrouvez une piste d’audit unique — ce que les équipes sécurité réclament depuis des années. Le provider ESO couvre le cas Kubernetes le plus courant, et la lecture en data source règle le problème du .tfvars committé.

Si vous êtes multi-cloud, multi-CI ou que vous avez besoin de secrets dynamiques fins — dynamic secrets, PKI, rotation à grande échelle —, restez sur Vault ou OpenBao auto-hébergé : GitLab Secrets Manager est encore jeune et ses capacités avancées sont limitées face à un Vault mature.

Dans tous les cas, ne migrez pas vos secrets de production pendant la bêta. La gratuité actuelle cache une facturation à venir mal définie ; attendez la GA, le prix des GitLab Credits, et testez la reprise sur un périmètre non critique. Un secret, ça ne se migre pas à la légère.

Références

• GitLab Blog — GitLab Secrets Manager adds ESO, Terraform, API support, 6 août 2026
• GitLab Docs — Non-CI/CD access to the Secrets Manager
• External Secrets Operator — SecretStore API