TP 1. Installer et durcir un serveur Vault

Énoncé de travail pratique

Les commandes ne figurent pas dans les énoncés : elles se construisent à partir du chapitre déclencheur indiqué ci-dessous. Le laboratoire et le livret de corrections ne sont pas encore publiés. Voir les limites du livrable

Chapitre déclencheur : 7. Durée : 1 h 30.

Objectifs

Installer un serveur Vault en respectant les exigences du chapitre 7, écrire sa configuration, produire son matériel TLS de laboratoire, le lancer sous un utilisateur dédié, et vérifier que le service répond avant toute initialisation. Savoir lire l'état d'un serveur non initialisé.

Prérequis

Chapitre 7 lu. Laboratoire démarré, aucun Vault initialisé.

Environnement de départ

Le conteneur core-01 est présent mais le service n'est pas lancé. Le répertoire conf/ contient un fichier core-01.hcl.incomplet dont plusieurs directives manquent ou sont fautives.

Étapes

1. Vérifier le binaire. Depuis admin-01, contrôlez l'empreinte du binaire fourni et sa signature, selon la méthode du chapitre 7. Notez la commande exacte et le résultat.

2. Produire le matériel TLS. Exécutez tls/generate.sh core-01 : le script produit une autorité de laboratoire et un certificat serveur portant en SAN le nom du nœud, son alias de service et son adresse. Relevez les SAN obtenus et expliquez pourquoi chacun est nécessaire.

3. Compléter la configuration. À partir de core-01.hcl.incomplet, écrivez la configuration attendue : stockage intégré avec son chemin et son identifiant de nœud, écouteur TLS avec ses certificats, adresses d'API et de cluster, disable_mlock avec sa contrepartie côté hôte, interface web désactivée. Chaque directive ajoutée est commentée d'une phrase justifiant sa présence.

4. Lancer le service. Le service tourne sous l'utilisateur dédié, avec l'unité fournie. Vérifiez qu'aucun processus Vault ne tourne sous root et que le répertoire de données appartient bien au compte de service.

5. Constater l'état. Exécutez vault status et interprétez chaque ligne. Le serveur doit être non initialisé et scellé.

6. Éprouver le TLS. Depuis admin-01, joignez le serveur sans VAULT_CACERT, puis avec. Constatez l'échec, puis le succès, et expliquez ce que chacun démontre.

Résultats attendus

vault status renvoie un serveur initialisé à faux, scellé à vrai, avec le type de seal shamir. Le processus tourne sous un compte non privilégié. Une connexion TLS sans autorité échoue avec une erreur de vérification. Le fichier de configuration final ne contient aucune directive non commentée.

Erreurs possibles et diagnostic

Le service refuse de démarrer avec un message concernant le verrouillage de la mémoire : la contrepartie de disable_mlock n'a pas été appliquée, ou la directive est absente. Le certificat est rejeté par le client : le SAN utilisé ne correspond pas au nom employé dans VAULT_ADDR, comparez les deux plutôt que de contourner. Le serveur démarre mais l'API répond en clair : l'écouteur a été laissé sans TLS, ce qui est la faute la plus grave de ce travail pratique. Les permissions du répertoire de données empêchent l'écriture : vérifiez le propriétaire, pas les droits seuls.

Questions

1. Parmi les directives que vous avez ajoutées, laquelle protège contre quelle menace précise ? Répondez pour trois d'entre elles.
2. Pourquoi l'interface web est-elle désactivée dans cette configuration, et dans quel cas la réactiveriez-vous ?
3. Le certificat de laboratoire porte trois SAN. Lequel deviendra inutile à l'étape 5 du fil rouge, et pourquoi les deux autres restent-ils nécessaires ?