Gestion des secrets avec HashiCorp Vault dans un pipeline GitLab CI/CD

Pourquoi externaliser les secrets ?

Dans un pipeline CI/CD, les variables d’environnement (tokens d’API, mots de passe, certificats) sont souvent stockées en clair dans le dépôt ou dans les paramètres de GitLab. Cette pratique expose les secrets à plusieurs risques : fuite via les logs, accès involontaire à des contributeurs externes, et rotation difficile. HashiCorp Vault propose un coffre‑fort dynamique, capable de générer des credentials temporaires et de les révoquer automatiquement.

Installation et configuration de Vault

1. Déploiement rapide avec Docker

   docker run -d --name=vault \
     -p 8200:8200 \
     -e 'VAULT_DEV_ROOT_TOKEN_ID=myroot' \
     vault:latest
   

   Le mode dev n’est destiné qu’aux tests ; en production, activez le stockage persistant (Consul, PostgreSQL, etc.) et configurez TLS.
2. Initialisation

   export VAULT_ADDR='http://127.0.0.1:8200'
   vault operator init -key-shares=1 -key-threshold=1 > init.txt
   

   Conservez les clés d’unseal et le token root dans un gestionnaire de secrets interne.
3. Définir une politique d’accès

   # policies/gitlab.hcl
   path "secret/data/*" {
     capabilities = ["read"]
   }
   

   vault policy write gitlab - <<EOF
   $(cat policies/gitlab.hcl)
   EOF
   

   Cette politique autorise la lecture de tous les secrets sous secret/data/.

Intégration avec GitLab CI/CD

a. Authentification via AppRole

1. Création d’un AppRole

   vault auth enable approle
   vault write auth/approle/role/gitlab-role \
     token_policies="gitlab" \
     token_ttl=20m \
     token_max_ttl=30m
   

2. Récupération du RoleID et du SecretID

   vault read auth/approle/role/gitlab-role/role-id
   vault write -f auth/approle/role/gitlab-role/secret-id
   

   Stockez le ROLE_ID et le SECRET_ID dans les variables protégées de GitLab (VAULT_ROLE_ID, VAULT_SECRET_ID).

b. Exemple de .gitlab-ci.yml

stages:
  - test
  - build

variables:
  VAULT_ADDR: "http://vault.example.com:8200"

before_script:
  - apk add --no-cache curl jq
  # Authentification AppRole
  - export VAULT_TOKEN=$(curl -s --request POST \
      --data "{\"role_id\": \"$VAULT_ROLE_ID\", \"secret_id\": \"$VAULT_SECRET_ID\"}" \
      $VAULT_ADDR/v1/auth/approle/login | jq -r .auth.client_token)
  # Récupération du secret
  - export DB_PASSWORD=$(curl -s --header "X-Vault-Token: $VAULT_TOKEN" \
      $VAULT_ADDR/v1/secret/data/db | jq -r .data.data.password)

unit_tests:
  stage: test
  script:
    - echo "Running tests with DB password from Vault"
    - ./run-tests.sh --db-pass $DB_PASSWORD

build_image:
  stage: build
  script:
    - docker build --build-arg DB_PASSWORD=$DB_PASSWORD -t myapp:${CI_COMMIT_SHA} .

Ce pipeline récupère dynamiquement le mot de passe de la base de données depuis Vault, évitant toute persistance locale.

Meilleures pratiques et sécurisation

• Rotation automatique : utilisez les secrets dynamiques (ex. : database/creds/role) afin que Vault génère des credentials à durée de vie limitée.
• Limitation d’accès : créez une politique par projet GitLab, ne donnez que les chemins nécessaires.
• Audit : activez le backend d’audit de Vault (vault audit enable file file_path=/var/log/vault_audit.log) pour tracer chaque lecture de secret.
• TLS obligatoire : en production, forcez HTTPS avec un certificat valide et désactivez le mode dev.
• Sécurisation des variables CI : marquez VAULT_ROLE_ID et VAULT_SECRET_ID comme protected et masked dans les paramètres du projet.

Conclusion

Intégrer HashiCorp Vault à un pipeline GitLab CI/CD élimine le stockage statique de secrets et renforce la traçabilité ainsi que la rotation des credentials. En suivant les étapes ci‑dessus—déploiement de Vault, création d’une politique minimaliste, utilisation d’AppRole, et configuration du fichier .gitlab-ci.yml—vous obtenez un flux CI/CD où chaque job ne possède que les secrets dont il a réellement besoin, pendant le temps requis. Cette approche, bien que légèrement plus complexe à mettre en place, devient rapidement un standard de sécurité pour les équipes DevOps soucieuses de la conformité et du moindre risque d’exposition.