10. Architecture fil rouge et nomenclature

10.1 Le contexte Astrea¶

Astrea est une entreprise fictive de services d'environ quatre-vingts personnes. Son application principale, billing (une API de facturation et ses workers), s'appuie sur une base PostgreSQL et migre progressivement vers Kubernetes. Sa chaîne de livraison utilise GitHub Actions. Les exigences posées dès le départ, et qui pilotent toute l'évolution de l'architecture : aucun secret en clair dans le code ou la CI ; rotation démontrable ; audit centralisé ; tolérance à la panne d'un serveur ; et, à partir de la partie VII, une contrainte de souveraineté interdisant l'usage d'un KMS cloud pour le scellement ; ce qui justifie le choix du Transit Seal dans le fil rouge (la variante KMS est traitée en parallèle au chapitre 22 et dans l'étude de cas 4).

10.2 Évolution de l'architecture¶

Étape 0, parties I à IV (laboratoire mono-nœud) :

poste étudiant (CLI)
        |
        v
  vault-core-01
  (Raft mono-noeud, scellement Shamir)

Étape 1, partie IV : l'application remplace l'étudiant et la chaîne de contrôle d'accès apparaît :

app-billing-01
      |
      v   login AppRole (role billing)
 auth/approle
      |
      v   token + policies
 policy billing-kv
      |
      v
 secret/billing/...   (KV v2)

Étape 2, parties V et VI : les moteurs s'ajoutent :

app-billing-01
      |
      v
 vault-core-01
   |- secret/    (KV v2)
   |- database/  (credentials PostgreSQL dynamiques) --> db-pg-01
   |- transit/   (cle billing-data)
   |- pki-int/   (certificats *.astrea.lab)

Étape 3, partie VII : le scellement du mono-nœud est externalisé :

vault-core-01  (seal "transit")
      |
      v   encrypt / decrypt sur la cle autounseal-core
vault-transit-01
(montage transit/ dedie, scelle par Shamir, ceremonie propre)

Étape 4, partie VIII : le cluster (chaque nœud porte la configuration de seal transit) :

app-billing-01
      |
      v
vault.astrea.lab (adresse de service)
      |
  +---+---------------+---------------+
  |                   |               |
vault-core-01   vault-core-02   vault-core-03
  |                   |               |
  +------- Raft (quorum 2/3) ---------+
                  ^
                  |  unseal au demarrage de chaque noeud
                  v
           vault-transit-01

Les TP suivent ce même ordre à une nuance près, choisie pour sa valeur pédagogique : le TP 11 (cluster) se réalise dans un environnement de laboratoire jetable scellé par Shamir, afin d'observer l'unseal nœud par nœud et la perte de quorum ; le cluster définitif du fil rouge, scellé par Transit, est assemblé au TP 12.

Étape 5, partie IX : l'architecture de référence :

app-billing-01    k8s-astrea    CI GitHub (OIDC)    admins (OIDC)
       |               |               |                 |
       +---------------+-------+-------+-----------------+
                               |
                         lb-vault-01
              (passthrough TCP, health sys/health)
                               |
               +---------------+---------------+
               |               |               |
        vault-core-01   vault-core-02   vault-core-03
               |               |               |
               +--- Integrated Storage (Raft) -+
                               ^
                               |  unseal au demarrage
                               v
                        vault-transit-01
                               ^
                               |  snapshots, audit, metriques
                         monitor-01

10.3 Nomenclature contractuelle¶

Machines et zones réseau :

Nom	Rôle	Adresse	Zone
vault-core-01/02/03	nœuds du cluster Vault Core	10.10.20.11 à 13	vault (10.10.20.0/24)
lb-vault-01	répartiteur TCP, VIP `vault.astrea.lab`	10.10.20.10	vault
vault-transit-01	Vault Transit (unsealer), `transit.astrea.lab`	10.10.10.11	confiance (10.10.10.0/24)
admin-01	poste d'administration (bastion)	10.10.10.21	confiance
monitor-01	supervision et collecte d'audit	10.10.10.31	confiance
app-billing-01	application fil rouge	10.10.30.21	applicative (10.10.30.0/24)
db-pg-01	PostgreSQL	10.10.30.31	applicative
k8s-astrea	cluster Kubernetes	10.10.40.0/24	applicative

Ports : 8200 (API et UI, TLS), 8201 (communication de cluster, restreinte aux membres du cluster).

Montages, rôles et policies :

Objet	Nom	Usage
KV v2	`secret/`	secrets statiques, sous `secret/billing/<env>/...`
Database	`database/`	connexion `pg-billing` ; rôle dynamique `billing-app` ; rôle statique `billing-batch`
Transit applicatif (sur le Core)	`transit/`	clé `billing-data` (chiffrement des données de facturation)
Transit de scellement (sur vault-transit-01)	`transit/`	clé `autounseal-core`
PKI	`pki-root/`, `pki-int/`	racine et émettrice ; rôle `astrea-services` (`*.astrea.lab`)
SSH	`ssh/`	rôle `admin-ssh` (signature de certificats)
Auth	`auth/approle` rôle `billing` ; `auth/kubernetes` rôle `billing-k8s` ; `auth/jwt-github` rôle `ci-billing` ; `auth/oidc` (humains) ; `auth/userpass` [Laboratoire]
Policies (Core)	`admin`, `ops-backup`, `ops-audit`, `billing-kv`, `billing-db`, `ci-deploy`
Policy (Transit)	`seal-core`	`encrypt`/`decrypt` sur la seule clé `autounseal-core`
Audit	device `file` → `/var/log/vault/audit.log` (+ syslog vers monitor-01)
TLS	serveurs émis par `pki-int` (amorçage auto-signé au ch. 7, remplacé au ch. 28)

Cette nomenclature est contractuelle pour l'ensemble du cours, des TP, des études de cas et de l'examen. Toute variante (par exemple la déclinaison KMS de l'étape 4) est nommée explicitement comme telle.