GitLab Secrets Manager prend en charge ESO, Terraform et les API

Aujourd'hui, vous gérez peut-être des magasins de secrets distincts pour le CI/CD, Kubernetes et Terraform. Cependant, cette approche vous demande de jongler entre plusieurs outils, de maintenir des modèles d'accès synchronisés et de corréler des pistes d'audit dispersées en cas d'incident.

GitLab Secrets Manager prend désormais en charge External Secrets Operator (ESO) et Terraform, et étend ainsi la récupération sécurisée des secrets au-delà des pipelines CI/CD. Alimenté par OpenBao, GitLab Secrets Manager constitue une source de vérité unique pour les secrets de toute votre chaîne de livraison logicielle. Vous pouvez désormais utiliser le même magasin de secrets pour :

• Les charges de travail Kubernetes via ESO
• Les exécutions Terraform ou OpenTofu
• OpenBao ou Vault CLI
• Les jobs CI/CD dans GitLab (à partir de la version 19.0)
• Toute automatisation externe via l'API Secrets Manager

Kubernetes : External Secrets Operator

ESO synchronise les secrets depuis GitLab Secrets Manager à l'aide du fournisseur Vault. Une charge de travail dans votre cluster détient un JSON Web Token (JWT) à durée de vie limitée qu'ESO utilise pour s'authentifier auprès d'OpenBao, puis intègre le secret dans un secret Kubernetes.

Un SecretStore indique à ESO où récupérer les secrets et comment s'authentifier. GitLab Secrets Manager expose une API KV v2 compatible avec Vault, que vous configurez via le fournisseur Vault. Le champ namespace correspond à votre hiérarchie GitLab (organisation, groupe, projet) et délimite les secrets accessibles par ce magasin. L'authentification repose sur un JWT généré par GitLab, stocké dans un secret Kubernetes et référencé par secretRef.

      apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
  name: gitlab-secrets-manager
  namespace: my-app
spec:
  provider:
    vault:
      server: https://secrets.gitlab.com      # provider.vault.server
      path: secrets/kv                        # provider.vault.path
      version: v2
      namespace: org_5/group_42/project_99    # provider.vault.namespace
      auth:
        jwt:
          path: api_jwt/cel                   # provider.vault.auth.jwt.path
          role: all_api                       # provider.vault.auth.jwt.role
          secretRef:
            name: gitlab-access-token         # Kubernetes secret holding the minted token
            key: token

    

Un ExternalSecret définit les secrets à récupérer et l'endroit où les stocker. Il fait référence au SecretStore créé précédemment, puis mappe les secrets distants dans un secret Kubernetes que vos charges de travail peuvent monter ou référencer en tant que variables d'environnement.

ESO crée et gère le secret cible (synced-secret), en le récupérant depuis GitLab à chaque refreshInterval afin que les valeurs mises à jour se propagent sans redéploiement. Chaque entrée sous data associe un secret distant à une clé dans la cible : remoteRef.key correspond au chemin d'accès dans GitLab Secrets Manager, property sélectionne un champ au sein de ce secret, et secretKey est la clé sous laquelle il apparaît dans Kubernetes.

      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>           # <secrets_path>/<secret_name>
        property: value

    

Consultez le tutoriel dédié à GitLab Secrets Manager et ESO.

Infrastructure as Code : Terraform et OpenTofu

Les fichiers d'état Terraform et les fichiers .tfvars sont une source fréquente de fuite d'identifiants, car les secrets finissent par être écrits sur le disque ou intégrés par inadvertance dans le contrôle de version. Terraform peut remédier à cette situation en lisant un secret GitLab comme source de données, en s'authentifiant à l'aide d'un JWT émis au moment de la planification ou de l'application. Référencez les identifiants directement dans Terraform, sans qu'ils soient stockés dans des fichiers .tfvars ou des variables CI/CD.

      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
}

    

Pour en savoir plus, consultez la documentation sur la lecture de secrets dans Terraform.

Ligne de commande : OpenBao ou Vault CLI

Tous les workflows ne passent pas directement par l'API. Si votre équipe utilise déjà des scripts qui s'appuient sur des outils compatibles avec Vault, OpenBao ou Vault CLI permet de lire des secrets depuis GitLab Secrets Manager de la même façon qu'avec Vault.

      export VAULT_ADDR="<server>"
export VAULT_NAMESPACE="<namespace>"

# Exchange the minted JWT for an OpenBao token, then export it.
vault write "auth/<auth_jwt_path>/login" role=<role> jwt=<token>
export VAULT_TOKEN="<client_token>"

# Read the secret value.
vault kv get -mount=<path> "<secrets_path>/<secret_name>"

    

Quand utiliser l'API Secrets Manager

Pour les automatisations qui ne s'intègrent pas à GitLab CI/CD, Kubernetes ou Terraform, l'API Secrets Manager permet à tout système externe de récupérer des secrets depuis GitLab Secrets Manager, sans avoir à coder des identifiants en dur ni à maintenir des fichiers de variables séparés.

      # Request JWT token using Service Account
RESPONSE=$(curl --silent --request POST \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/projects/<project_id>/secrets_manager/access_token")

SERVER=$(echo "$RESPONSE" | jq --raw-output .provider.vault.server)
NAMESPACE=$(echo "$RESPONSE" | jq --raw-output .provider.vault.namespace)
MOUNT=$(echo "$RESPONSE" | jq --raw-output .provider.vault.path)
SECRETS_PATH=$(echo "$RESPONSE" | jq --raw-output .provider.vault.secrets_path)
AUTH_PATH=$(echo "$RESPONSE" | jq --raw-output .provider.vault.auth.jwt.path)
ROLE=$(echo "$RESPONSE" | jq --raw-output .provider.vault.auth.jwt.role)
JWT=$(echo "$RESPONSE" | jq --raw-output .provider.vault.auth.jwt.token)

# Exchange the JWT for a short-lived OpenBao token.
VAULT_TOKEN=$(curl --silent --request POST \
  --header "X-Vault-Namespace: $NAMESPACE" \
  --data "{\"role\":\"$ROLE\",\"jwt\":\"$JWT\"}" \
  "$SERVER/v1/auth/$AUTH_PATH/login" | jq --raw-output .auth.client_token)

# Read the secret value.
curl --silent \
  --header "X-Vault-Token: $VAULT_TOKEN" \
  --header "X-Vault-Namespace: $NAMESPACE" \
  "$SERVER/v1/$MOUNT/data/$SECRETS_PATH/<secret_name>"

    

Premiers pas

GitLab Secrets Manager est disponible en accès limité sous forme de module d'extension payant facturé via les GitLab Credits pour les utilisateurs GitLab Premium et GitLab Ultimate sur GitLab.com. GitLab Secrets Manager est en version bêta pour les déploiements auto-gérés, et la prise en charge de GitLab Dedicated sera bientôt disponible.

Consultez notre documentation pour vous lancer. Si vous constatez une lacune ou souhaitez nous faire part d'une demande, n'hésitez pas à laisser un commentaire dans ce ticket, car nous collectons les retours avant la mise en disponibilité générale.