Aller au contenu

Vault — stratégie secrets, CI (Maven/Gradle) & feuille de route

Cette page fixe ce que DYNORS retient pour HashiCorp Vault, l’alimentation des secrets en CI (registry Maven GitLab, etc.), et l’état des chantiers (fait / en cours / à faire). Elle complète la doc Maven : Maven — settings.xml & registry GitLab.

Sources de vérité détaillées (workspace dynors/, hors MkDocs obligatoire pour les runbooks) :

  • docs/VAULT_SECRETS_STRATEGIE.md — ESO, chemins KV, exemple TAKKU
  • docs/adr/ADR-2026-04-26-vault-strategie-completion.md — 5 chantiers adoptés
  • docs/architecture/reference-resilience/JOURNAL_REVUE_ARCHI.md — entrée AR-20260426-009
  • Règle ingénierie : .cursor/rules/vault-secrets-dynors.mdc

1. Stratégie adoptée (résumé)

Pilier Décision
Coffre unique HashiCorp Vault = source de vérité des secrets techniques (JDBC, JWT signing hors flux navigateur, SLY_FORWARD_SECRET, tokens outils, clés API, etc.).
Ce que Vault ne remplace pas Le tenant métier (tenant dans le JWT, TenantContext) — modèle applicatif multi-tenant, pas clé Vault.
Kubernetes External Secrets Operator (ESO) : Vault KV v2 → Secret K8s → Deployment (env.valueFrom.secretKeyRef). Alternative ponctuelle : Vault Agent Injector.
Convention de chemins secret/data/dynors/{env}/{app}/... avec policies au moindre privilège (une app ne lit que son préfixe). Exemples : .../takku/database, .../takku/gitlab, .../platform/sly.
CI GitLab Cible : OIDC JWT GitLab → Vault ou AppRole TTL court pour les jobs ; éviter la duplication durable « coffre + variable GitLab » sans processus. Transition : variables masquées alimentées manuellement ou par script de rotation jusqu’à branchement OIDC/AppRole stable.
Scan de fuites Gitleaks (pre-commit + CI) — ne pas versionner PAT/clés ; si fuite : révocation immédiate. Voir Gitleaks — usage, précautions & dépannage.

2. Registre Maven GitLab (com.dynors) et Vault

2.1 Aujourd’hui (pragmatique)

  • Poste dev : export GITLAB_TOKEN=… ou gitlab.token dans un gradle.properties non commité — le PAT reste hors dépôt ; idéalement durée courte + scope minimal.
  • CI :
  • CI_JOB_TOKEN + en-tête Job-Token (Gradle/Maven) quand l’accès inbound aux projets dynors-core / dynors-extensions est configuré (voir doc Maven §4.1).
  • Sinon : variable GITLAB_TOKEN (masquée) = PAT technique ou jeton projet.

2.2 Cible (alignement Vault)

  1. Stocker le secret dans Vault, ex. :
    secret/data/dynors/{env}/gitlab/registry-read → clé token (PAT lecture registry + API minimale) ou modèle AppRole dédié sans PAT longue durée.
  2. Runtime K8s : ESO synchronise vers Secret (ex. clé gitlab-token → env GITLAB_TOKEN pour un outil interne qui build dans le cluster — cas rare pour runners GitLab SaaS).
  3. GitLab CI (runners managés) :
  4. Option A — Job initiale « vault-auth » : JWT OIDC → Vault, récupération temporaire du secret, export GITLAB_TOKEN pour la durée du job (nécessite config JWT auth sur Vault + rôle limité).
  5. Option B — Rotation périodique : un processus (humain ou automation) met à jour la variable masquée GitLab depuis Vault pour les projets qui ne peuvent pas encore utiliser OIDC.

Pour un mapping type « Vault → Secret K8s » déjà documenté avec gitlab / GITLAB_TOKEN, voir la table TAKKU dans docs/VAULT_SECRETS_STRATEGIE.md (workspace).

3. Feuille de route — 5 chantiers Vault & équivalent (ADR 2026-04-26)

Statut ci-dessous = indicateur de documentation / direction ; l’équipe infra / sécu ajuste après revue des déploiements réels.

# Chantier Objectif Statut indicatif Runbook / trace (workspace dynors)
1 Transit Engine — Mediconnect Clé maître santé : chiffrement/déchiffrement sans export de clé fichier / heap durable À finaliser côté prod (runbook + alignement app) docs/runbooks/vault-transit-engine-mediconnect.md
2 Gitleaks CI + pre-commit Bloquer secrets dans Git avant merge En déploiement (ex. dynors-core + template ; étendre aux autres dépôts) docs/runbooks/gitleaks-secret-scanning.md
3 HA Vault — Raft 3 nœuds + autounseal KMS Supprimer le SPOF Vault À faire (priorité prod K8s) docs/runbooks/vault-ha-raft-autounseal.md
4 Database Secrets Engine Credentials Postgres courte durée (blast radius) À faire (FISCAL, BOOKS, paiement, Mediconnect, etc.) docs/runbooks/vault-database-secrets-engine.md
5 Snapshots Raft → S3 chiffré Restauration coffre À faire (cron + test DR trimestriel) docs/runbooks/vault-snapshots-raft.md

Transverse ADR : vault-dev + bootstrap dans docker-compose.infra.yml racine workspace ; onboarding §Vault / Gitleaks dans ONBOARDING_DEVELOPPEUR.md — fait (voir ADR §standardisation dev local).

4. Suivi « Vault + dynors-media » (état humain)

Un fichier d’état — mis à jour lors d’actions concrètes (chemins Vault, buckets, routes SLY, smoke tests) — alimente le suivi interne :

  • dynors-ops/reports/media-vault/PROGRESS_STATE.yml (workspace racine dynors)

Champs utiles : status (in_progress | blocked | done), last_user_action_at, next_priority, blocked_reason.
Tant que last_user_action_at reste vide ou dépasse stale_threshold_days, les rapports planifiés rappellent qu’une action est attendue (spec agent : docs/agents/MEDIA_VAULT_PROGRESS_AGENT.md).

À compléter par l’équipe

Renseigner last_user_action_at et next_priority après chaque itération réelle (pas seulement specs) pour que la feuille de route reflète le terrain.

5. À faire — liste opérationnelle (backlog transverse)

À répartir entre infra, SRE et owners d’apps ; ordre indicatif :

  1. Généraliser Gitleaks : inclure le template .gitlab/ci/gitleaks.template.yml sur tous les dépôts dynors/* et dynors-projects/* qui versionnent du code.
  2. OIDC GitLab → Vault : design rôle + policy + TTL pour jobs CI qui ont besoin de secrets (registry, déploiement) ; réduire les PAT « techniques » multi-mois.
  3. Compléter ESO : pour chaque app critique en prod, ExternalSecret + runbook rollback aligné sur docs/VAULT_SECRETS_STRATEGIE.md.
  4. DR Vault : rehearsal trimestriel (restauration snapshot sur cluster staging) — ADR §9.
  5. Média / stockage : fermer les écarts AR-20260426-007 (signed URLs, Transit/SSE, alignement backend) en synchronisation avec PROGRESS_STATE.yml.

6. Liens rapides internes

Sujet Emplacement
Stratégie Vault & ESO (détail) Workspace → docs/VAULT_SECRETS_STRATEGIE.md
ADR complément Vault Workspace → docs/adr/ADR-2026-04-26-vault-strategie-completion.md
Journal d’architecture Workspace → docs/architecture/reference-resilience/JOURNAL_REVUE_ARCHI.md
Maven + CI GitLab Maven — settings.xml & registry GitLab
Gitleaks Gitleaks — usage, précautions & dépannage

Cette page MkDocs est une porte d’entrée : les runbooks techniques restent dans le workspace ; mettre à jour le tableau §3 lors des revues d’avancement trimestrielles ou après chaque chantier livré.