Chapitre 8. Initialisation, seal et unseal
Objectifs pédagogiques¶
Expliquer ce que l'initialisation crée, en le reliant à la hiérarchie du chapitre 6. Choisir les paramètres de partage et remettre les parts proprement. Lire les trois états et conduire leurs transitions. Appliquer la doctrine du root token. Exécuter les premiers gestes d'une installation sérieuse.
Prérequis¶
Chapitre 6 pour la hiérarchie des clés, chapitre 7 pour un serveur installé et scellé, section 2.6 pour les quorums.
Cours¶
8.1 Ce que l'initialisation crée¶
Acte de naissance cryptographique du serveur : unique dans sa vie, irréversible autrement qu'en détruisant le stockage. [Laboratoire]
La sortie, affichée une seule fois et jamais stockée par Vault :
Chaque objet se relie au chapitre 6. Vault a généré la première clé du keyring, généré la clé racine, chiffré le keyring avec elle, puis, plutôt que de stocker cette clé racine, l'a partagée selon le schéma de Shamir : cinq parts, dont trois quelconques suffisent à la reconstituer et dont deux n'apprennent rien. Ces parts sont l'unique voie de retour vers la clé racine ; Vault n'en garde aucune copie. S'y ajoute l'Initial Root Token, objet strictement temporaire.
Note de version : le préfixe hvs. identifie les tokens de service depuis la version 1.10. Les textes anciens disent « master key » là où ce cours dit clé racine.
Les paramètres traduisent l'arbitrage de la section 2.1 : le seuil élève la confidentialité, il faut compromettre k détenteurs, et abaisse la disponibilité, il faut réunir k humains un dimanche de panne. Le couple 5/3 du fil rouge est un point d'équilibre courant : assez de parts pour survivre à des absences, un seuil qui interdit l'action solitaire.
Deux options complètent l'outillage de cérémonie : -pgp-keys chiffre chaque part avec la clé publique de son détenteur, de sorte que l'écran d'initialisation ne montre plus aucune part en clair, et -root-token-pgp-key fait de même pour le root token. C'est la forme recommandée en production ; la cérémonie complète est l'objet du chapitre 21.
Sous l'angle de l'API, l'initialisation passe par un chemin non authentifié, nécessairement, et qui cesse de répondre dès qu'il a servi.
8.2 Les trois états¶
operator init assemblage du quorum
NON INITIALISE ------------------> SCELLE ------------------------> DESCELLE
(rien n'existe) (tout existe, (cle racine
rien n'est lisible) en memoire)
^ |
| operator seal, |
+----- redemarrage, ---------------+
perte du processus
Trois phrases restituent le diagramme. L'initialisation ne se produit qu'une fois : elle fait exister la hiérarchie. Le descellement se reproduit à chaque démarrage : il fait exister la clé racine en mémoire et nulle part ailleurs, ce qui explique que tout arrêt du processus ramène à l'état scellé. Et l'état scellé n'est pas une panne : c'est l'état de repos conçu du système, où les données sont là, intactes, illisibles.
La lecture croisée de vault status et de sys/health est l'instrument de diagnostic de toute la suite : 501 est devenu 503, initialisé et scellé.
8.3 Desceller, et sceller¶
[Laboratoire]
Chaque appel accepte une part et affiche la progression. Au troisième, la clé racine est reconstituée, le keyring déchiffré, et Sealed passe à false.
Quelques précisions d'usage. La commande sans argument invite à la saisie : passer la part en argument la déposerait dans l'historique du shell. Les trois saisies n'ont aucune raison de venir du même clavier : en production, trois détenteurs saisissent chacun leur part depuis leur session, sans se les montrer ; le serveur assemble, les humains ne se transmettent rien. Enfin vault operator unseal -reset abandonne une progression entamée : la progression n'est pas un état à réparer, elle se remet à zéro.
L'opération inverse est à encadrer de rouge. [Production]. Commande dangereuse : arrêt de service immédiat
Sceller éjecte la clé racine de la mémoire. À la seconde, plus aucune requête authentifiée n'aboutit, et le retour exige le quorum. Ce n'est ni un test ni un redémarrage doux : c'est le bouton d'arrêt d'urgence, dont l'usage légitime est la compromission suspectée. Le chapitre 31 l'inscrira dans la procédure de réponse à incident.
Reste la conséquence à regarder en face : chaque redémarrage exige le quorum humain. Mise à jour, panne, redémarrage de maintenance : trois personnes, leurs parts, une coordination, y compris à trois heures du matin. Pour une production, c'est une contrainte de disponibilité majeure, et c'est le problème que la partie VII résoudra.
8.4 Le root token : s'en servir, puis s'en défaire¶
Le root token échappe à tout ce que ce cours enseigne : policy root que nulle règle ne borne, pas de refus par défaut, pas d'expiration. Objet nécessaire, il faut bien un premier pouvoir pour créer les suivants, et inacceptable en régime permanent. Le root token sert au bootstrap, puis il meurt.
Premier geste : s'authentifier. [Laboratoire]
Deuxième geste : l'audit, avant tout le reste. [Production]
Avant même de créer le premier compte, pour que tout ce qui suit laisse trace. Rappel opérationnel du chapitre 4 : si plus aucun dispositif ne peut écrire, Vault s'arrête. D'où la règle d'un second dispositif hors machine, que le chapitre 30 mettra en place. D'ici là, la supervision de l'espace disque du répertoire d'audit est un point d'attention.
Troisième geste : un administrateur nommé. [Laboratoire]
cat > /tmp/admin.hcl << 'EOF'
# Policy admin -- version bootstrap, a raffiner (chapitre 11).
path "sys/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] }
path "auth/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] }
path "identity/*" { capabilities = ["create", "read", "update", "delete", "list"] }
path "secret/*" { capabilities = ["create", "read", "update", "delete", "list"] }
EOF
vault policy write admin /tmp/admin.hcl
vault auth enable userpass
vault write auth/userpass/users/nadia password=- policies=admin
La méthode userpass est marquée [Laboratoire] : elle sert le bootstrap, les humains d'Astrea passant par OIDC au chapitre 10. Un gestionnaire de secrets n'a pas vocation à devenir la base de comptes qu'on cherchait à quitter.
Quatrième geste : vérifier, puis révoquer. Dans une autre session, se connecter en nadia, vérifier ses droits, puis, une fois l'administrateur prouvé fonctionnel : [Production]. Irréversible à dessein
Si le pouvoir suprême redevient nécessaire, il ne se stocke pas au cas où : il se régénère sous quorum, par vault operator generate-root, procédure détaillée au chapitre 20.
8.5 Les parts elles-mêmes¶
Trois règles, développées au chapitre 21. Jamais deux parts chez la même personne. Jamais toutes les parts dans le même coffre ou le même domaine de compromission. Et jamais de script d'unseal contenant k parts : un tel script est la clé racine posée sur un disque, et il annule toute la construction de Shamir.
Exemple : la cérémonie de laboratoire d'Astrea¶
Cinq détenteurs nommés, choisis pour leur indépendance fonctionnelle : la direction technique, la RSSI, deux membres de l'exploitation, une développeuse senior. Pas cinq personnes de la même équipe, dont absences et compromissions seraient corrélées.
Initialisation en 5/3, saisie constatée à l'écran par les seuls intéressés, chacun rangeant sa part dans un stockage personnel chiffré distinct. Le registre, tenu par la RSSI, note pour chaque part : numéro, détenteur, support, date de remise, date du dernier exercice.
Deux règles y sont inscrites en gras : jamais de part dans un script, jamais de sauvegarde du stockage rangée avec du matériel de scellement. La séquence de bootstrap suit dans l'ordre du cours, et le root token est révoqué le jour même, une fois le compte administrateur éprouvé.
Sécurité : le moment le plus exposé¶
L'initialisation réunit en quelques minutes ce que le reste de l'architecture s'emploiera à ne plus jamais rassembler : la totalité des parts et le pouvoir suprême, affichés ensemble sur un écran.
L'écran. Session locale ou canal maîtrisé, pas de partage d'écran enregistré, pas de terminal à défilement conservé, pas de multiplexeur qui journalise. L'option -pgp-keys supprime le problème à la racine.
Les parts. Jamais en argument de commande, jamais dans un script d'unseal, jamais réunies dans un même coffre.
Le root token. Sa révocation n'est pas une formalité de fin de procédure : c'est ce qui transforme un pouvoir permanent en pouvoir régénérable sous contrôle.
L'audit d'abord. Activer l'audit avant le premier compte garantit que la constitution même des droits est tracée.
Erreurs fréquentes¶
Conserver le root token au cas où. Une valeur éternelle et toute-puissante qui attend son voleur. Bootstrap, révocation, régénération sous quorum si le besoin revient (section 8.4).
Scripter l'unseal avec les parts. Le script qui contient k parts reconstitue la clé racine sur disque : Shamir annulé. Si la contrainte du quorum est intenable, la réponse est la partie VII, pas le contournement (section 8.3).
Saisir parts et tokens en arguments. L'historique du shell est un journal en clair (section 8.3).
Différer l'audit. Trente secondes de configuration contre l'impossibilité de reconstituer les premiers gestes (section 8.4).
Confondre scellé et en panne. L'état scellé est l'état de repos conçu ; les données sont intactes (section 8.2).
Réinitialiser un serveur déjà initialisé. L'opération échoue, et l'insistance conduit parfois à détruire le stockage pour « repartir propre » (section 8.1).
Distribuer les parts à des personnes du même service. Absences et compromissions corrélées, quorum théorique (Exemple).
Mise en pratique : ordonner et diagnostiquer¶
Sans machine ; le TP 2 fera la version réelle. Réponses commentées en fin de partie.
- Remettez dans l'ordre les dix actions suivantes et justifiez la position de chacune : révoquer le root token ; activer l'audit ;
operator init; vérifier le binaire ; créer la policy admin ; desceller ; démarrer le service ; créer le compte nominatif ; se connecter avec ce compte et vérifier ses droits ;vault loginavec le root token. - Diagnostiquez ces trois relevés et donnez le geste suivant : a)
Initialized false / Sealed true; b)Initialized true / Sealed true / Unseal Progress 2/3; c)Initialized true / Sealed false, maisvault loginéchoue en connexion refusée depuis le poste d'administration. - Un collègue propose de stocker les cinq parts dans le gestionnaire de mots de passe de l'équipe, « pour ne pas les perdre ». Rédigez votre réponse en trois arguments, chacun rattaché à un principe du chapitre 2.
Questions de compréhension¶
- Énumérez ce que l'initialisation crée, en situant chaque objet dans la hiérarchie, et ce que Vault n'en conserve pas.
- Pourquoi la sortie d'initialisation ne s'affiche-t-elle qu'une fois, et quelles pratiques cela impose-t-il ?
- Que changent
-pgp-keyset-root-token-pgp-key? - Restituez le diagramme des trois états et expliquez pourquoi tout arrêt ramène à l'état scellé.
- En quoi le choix parts et seuil est-il un cas de l'arbitrage confidentialité contre disponibilité ?
- Quand
operator sealest-il légitime, et pourquoi le pratiquer en laboratoire ? - Énoncez la doctrine du root token et la séquence complète du bootstrap.
- Pourquoi l'audit s'active-t-il avant la création du premier compte ?
- Que reproche-t-on exactement à un script d'unseal contenant les parts ?
Synthèse¶
L'initialisation matérialise la hiérarchie du chapitre 6 : une clé racine générée puis aussitôt partagée en cinq parts au seuil de trois et nulle part conservée, un keyring qu'elle chiffre, un premier token sans borne. Les états s'enchaînent selon un diagramme à réciter : l'initialisation une fois, le descellement à chaque démarrage, le scellement volontaire comme bouton d'arrêt d'urgence. Le quorum à chaque redémarrage est la contrainte fondatrice que la partie VII viendra déplacer. Quant au pouvoir : audit avant tout, administrateur nominal borné par une policy écrite, root token révoqué sitôt le relais prouvé, régénérable sous quorum seulement. Déclenche le TP 2 (énoncé en partie XV).