Partie XV. Cahier des travaux pratiques et spécification du laboratoire
HashiCorp Vault : de la gestion des secrets à l'architecture de production sécurisée¶
Partie XV. Cahier des travaux pratiques et spécification du laboratoire (TP 1 à 15)
Document 15 du cursus. Se réfère au plan pédagogique (document 0, révision 2) pour la structure d'ensemble, la nomenclature Astrea et les conventions d'écriture.
Présentation de la partie¶
Ce que ce document fournit, et ce qu'il ne fournit pas¶
Ce document contient les énoncés des quinze travaux pratiques et la spécification du laboratoire qui les porte. Il ne contient ni les commandes à exécuter, ni les corrections.
Les commandes ne sont pas données, et c'est un parti pris : chaque travail pratique est déclenché par un chapitre du cours qui contient les commandes, leurs paramètres et leurs pièges. L'exercice consiste précisément à les retrouver et à les composer. Un énoncé nomme les objets à créer, les valeurs à retenir et les constats à produire ; il ne recopie pas le chapitre dont il suppose la lecture.
Deux éléments restent à produire avant qu'une session puisse être animée, et ce document ne prétend pas les fournir : l'archive du laboratoire, dont la section « Le laboratoire à construire » donne la spécification, et le livret de corrections, avec les commandes attendues, les sorties de référence et les réponses aux questions. Tant qu'ils n'existent pas, cette partie se lit comme un cahier des charges pédagogique, pas comme un support prêt à distribuer.
Ce que le parcours pratique demande¶
Quinze travaux pratiques de difficulté croissante, pour un total de trente-deux heures et demie, plus une demi-heure de prise en main. Chacun est déclenché par un chapitre du cours, dont il suppose la lecture ; chacun produit un état vérifiable, et cet état sert de point de départ au suivant. Un travail pratique optionnel, hors barème, complète le parcours pour ceux qui disposent d'un cluster Kubernetes local.
L'ensemble tient sur une machine unique disposant d'environ huit gigaoctets de mémoire vive, sous Linux, macOS ou Windows avec un sous-système Linux. Les composants s'exécutent en conteneurs, orchestrés par un fichier de composition que l'archive doit fournir.
La correspondance avec le fil rouge¶
Le laboratoire reprend le plan d'adressage d'Astrea à l'identique, de sorte que les adresses, les ports et les chemins du cours s'y transposent tels quels. Les noms d'hôtes sont raccourcis pour rester lisibles en ligne de commande : vault-core-01 devient core-01, vault-transit-01 devient transit-01, app-billing-01 devient app-01, db-pg-01 devient pg-01. La table ci-dessous fait foi, et c'est la seule traduction à opérer entre le cours et le laboratoire :
| Conteneur | Adresse | Rôle dans le fil rouge |
|---|---|---|
core-01, core-02, core-03 |
10.10.20.11 à .13 | Les trois nœuds du cluster Vault |
lb-01 |
10.10.20.10 | Le répartiteur, alias vault.astrea.lab |
transit-01 |
10.10.10.11 | Le gardien de seal, alias transit.astrea.lab |
admin-01 |
10.10.10.21 | Le poste d'administration, d'où vous travaillez |
monitor-01 |
10.10.10.31 | La collecte des journaux et des métriques |
pg-01 |
10.10.30.31 | La base PostgreSQL de billing |
app-01 |
10.10.30.21 | L'hôte applicatif de billing |
kc-01 |
10.10.10.41 | Keycloak, pour les volets OIDC optionnels |
Sauf indication contraire, les commandes s'exécutent depuis admin-01, où VAULT_ADDR et VAULT_CACERT sont déjà positionnées. Aucun travail pratique ne demande de désactiver la vérification TLS : si une commande échoue sur un certificat, c'est un exercice de diagnostic, pas une invitation à contourner.
Le laboratoire à construire¶
L'archive du laboratoire n'accompagne pas encore ce document. Elle doit contenir :
- le fichier de composition et les images utilisées ;
- les configurations des nœuds et du gardien, commentées, dans
conf/; - la configuration du répartiteur dans
conf/haproxy.cfg; - un script de génération du matériel TLS de laboratoire dans
tls/; - les scripts d'exploitation dans
scripts/, dont la sauvegarde du TP 14 ; - l'initialisation de la base dans
sql/.
S'y ajoutent les ressources appelées par des travaux pratiques précis : la policy admin du TP 2, le squelette de script du TP 6, le domaine de test du fournisseur d'identité pour le TP 6, l'émulateur local de service de clés du TP 9, le minuteur de renouvellement du TP 12, le script d'injection d'événements du TP 13, le minuteur de sauvegarde du TP 14. Chaque énoncé nomme ce dont il a besoin.
Un script reset.sh doit ramener le laboratoire à son état initial, ce qui autorisera à se tromper franchement : la seule façon d'apprendre certaines choses.
Les énoncés qui suivent décrivent l'environnement tel qu'il existera une fois le laboratoire monté. Lorsqu'un travail pratique parle du binaire, de l'unité de service, du schéma de la base ou d'un script à compléter, il renvoie à cette spécification et non à un fichier joint au présent document.
Comment lire un énoncé¶
Chaque travail pratique suit le même gabarit : objectifs, prérequis, étapes à conduire, résultats attendus, erreurs possibles avec leur diagnostic, questions. Deux sections apparaissent lorsqu'elles sont utiles : l'environnement de départ, quand il ne se déduit pas des prérequis, et l'architecture visée, quand elle change. Les résultats attendus sont formulés de façon vérifiable : ils décrivent ce que vous devez constater, pas ce que vous devez croire.
Trois conventions valent pour tout le parcours. Les marqueurs du cours restent en vigueur : une étape signalée [Production] se conduit comme elle le serait en production, avec ses précautions et son annonce de fenêtre, même si le laboratoire ne coûte rien. Les échecs volontaires font partie des énoncés : plusieurs travaux pratiques demandent de provoquer un refus et de le constater, parce qu'une autorisation qui n'a jamais rien refusé n'a rien prouvé. Enfin, chaque travail pratique se termine par une trace écrite (une ligne de registre, comme au chapitre 29) qui prend cinq minutes et qui constitue, à la fin du parcours, le dossier d'exploitation d'Astrea.
Objectifs de la partie. À l'issue des quinze travaux pratiques, l'étudiant est capable de :
- installer, durcir et gouverner un serveur Vault ;
- conduire les cérémonies de scellement et de régénération ;
- écrire et éprouver des autorisations par leurs refus ;
- mettre en service une chaîne d'authentification applicative, une autorité de certification et des secrets dynamiques ;
- déléguer le descellement à un gardien souverain ;
- monter, exploiter et étendre un cluster ;
- assembler l'architecture cible et en prouver les flux ;
- conduire une réponse à incident, produire une sauvegarde vérifiable et reconstruire un cluster perdu.
Prérequis de la partie. Le chapitre déclencheur de chaque travail pratique, lu avant la séance. Une machine disposant d'environ huit gigaoctets de mémoire vive et d'un moteur de conteneurs. Chaque travail pratique reprend l'état laissé par le précédent.
Plan. TP 1, installation et durcissement. TP 2, initialisation et descellement. TP 3, le moteur KV. TP 4, les policies. TP 5, les tokens. TP 6, AppRole de bout en bout. TP 7, la PKI interne. TP 8, les credentials dynamiques. TP 9, l'Auto Unseal. TP 10, le Transit Seal. TP 11, le cluster Raft. TP 12, l'architecture cible. TP 13, la réponse à incident. TP 14, la sauvegarde. TP 15, la reprise après sinistre. TP optionnel, Kubernetes, hors barème.