VaultCI/CDSécurité

Intégrer HashiCorp Vault dans vos pipelines CI/CD

25 mars 2026 · Sphinx-Digital

La gestion des secrets dans les pipelines CI/CD est un sujet que beaucoup d’équipes règlent avec des variables d’environnement dans l’interface de leur outil CI. C’est fonctionnel, mais limité : pas de rotation automatique, pas d’audit d’accès fin, pas de secrets dynamiques.

Les secrets dynamiques : le vrai avantage de Vault

Vault peut générer des credentials de base de données éphémères à la demande. Chaque job CI reçoit des credentials uniques qui expirent automatiquement après quelques heures.

# Vault génère un user/password PostgreSQL temporaire
vault read database/creds/my-role
# Key      Value
# ---      -----
# username  v-cicd-xk3j9d2
# password  A1s-Zy3k-...
# lease_duration  1h

Résultat : même si les credentials fuient dans des logs, ils sont expirés avant qu’un attaquant puisse les exploiter.

Authentification depuis GitLab CI avec JWT

# .gitlab-ci.yml
deploy:
  script:
    - |
      export VAULT_TOKEN=$(vault write -field=token auth/jwt/login         role=ci-deploy         jwt=$CI_JOB_JWT)
    - vault kv get -field=api_key secret/myapp/prod

Le job GitLab présente son JWT (signé par GitLab) à Vault, qui le vérifie et émet un token à durée limitée. Aucun secret long-terme ne circule dans GitLab.

Configuration côté Vault

# Politique d'accès pour le role CI
path "secret/data/myapp/prod" {
  capabilities = ["read"]
}

path "database/creds/my-role" {
  capabilities = ["read"]
}
vault write auth/jwt/role/ci-deploy   bound_audiences="https://gitlab.example.com"   bound_claims_type=glob   bound_claims.project_path="mygroup/myproject"   token_policies=ci-deploy-policy   token_ttl=1h

Avec GitHub Actions

jobs:
  deploy:
    permissions:
      id-token: write
    steps:
      - uses: hashicorp/vault-action@v2
        with:
          url: https://vault.example.com
          method: jwt
          role: github-ci
          secrets: |
            secret/data/myapp api_key | API_KEY ;
            database/creds/my-role username | DB_USER ;

Audit : savoir qui a accédé à quoi

Vault enregistre chaque accès dans son audit log :

{
  "time": "2026-03-25T14:32:01Z",
  "auth": {"display_name": "ci-deploy"},
  "request": {"path": "secret/data/myapp/prod", "operation": "read"},
  "response": {"data": {"keys": ["api_key"]}}
}

En cas d’incident, vous savez exactement quel job a accédé à quel secret et quand.

Notre formation HashiCorp Vault couvre l’intégration CI/CD avec GitLab et GitHub Actions sur environnement réel.