Éléments de réponse aux questions de compréhension

Chapitre 18

1. Les trois défauts : partagé, l'audit disant qui a lu et non qui a agi sur la cible ; durable, la fenêtre courant depuis la dernière rotation manuelle ; irrattrapable, la copie lue ne se reprenant pas. Les quatre propriétés : unique par demandeur, court, révocable pour de vrai puisque la révocation détruit le compte côté cible, et sans rotation puisque ce qui meurt seul ne se tourne pas.

2. Un compte racine sur la cible, l'accès privilégié qui permet de fabriquer. Des instructions de création et de révocation, où Vault injecte nom, mot de passe et échéance. Un nom unique par émission, qui relie les journaux de la cible à l'audit de Vault. Les privilèges du compte créé vivent dans les instructions du rôle : c'est le moindre privilège écrit jusque dans la base, indépendant des droits Vault du demandeur.

3. Parce qu'elle reprend un secret déjà remis : révoquer le bail exécute la logique de destruction côté cible, et le compte cesse d'exister. Tout ce qui précédait coupait l'accès futur à Vault sans rien reprendre de ce qui avait été lu.

4. Une lecture sur le chemin de credentials, qui rend identifiants, identifiant de bail, durée et caractère renouvelable. Puis l'usage direct sur la cible, Vault hors de la boucle. Puis des renouvellements périodiques dans la limite du plafond, au rythme du token. Enfin l'expiration ou la révocation, où le gestionnaire d'expiration exécute le nettoyage. Une application qui meurt sans prévenir laisse un bail qui expire seul.

5. Continue : tout credential déjà émis, la cible ne consultant pas Vault. S'arrête : toute émission nouvelle et tout renouvellement. Les baux échus pendant la panne expirent, et la cible les refuse d'elle-même si l'échéance est locale, sinon la révocation se rattrape au retour. Conclusion : Vault devient dépendance de démarrage et de renouvellement, ce qui est l'argument central de la haute disponibilité et une exigence de conception applicative.

6. Le moindre privilège côté cible, pour qu'un moteur compromis fabrique dans le périmètre des rôles sans devenir administrateur. La rotation du compte racine, qui tue la valeur initiale ayant transité par des terminaux. Le secours hors Vault, pour administrer la cible quand Vault ne le peut pas. La rotation rend définitivement impossible la connaissance humaine du mot de passe : c'est le but, un secret que personne ne connaît ne fuit par personne, et c'est pourquoi le secours se vérifie avant.

7. Un compte permanent existant dont Vault gouverne le mot de passe : rotation automatique ou programmée, distribution de la valeur courante aux autorisés. Il résout la rotation sans humain pour les consommateurs incapables de suivre des identifiants changeants. Il ne résout ni l'unicité, le compte restant un, ni la mort naturelle, le compte survivant à tout.

8. La cible sait-elle créer des comptes et le consommateur suivre ? Dynamique, comme l'API billing. Le consommateur ne suit pas mais la cible accepte un changement de mot de passe ? Statique géré, comme le traitement nocturne. Ni l'un ni l'autre ? Statique en KV, avec versions, métadonnées et échéance, comme la clé du prestataire de paiement : risque résiduel accepté et daté.

Mise en pratique du chapitre 18. 1. L'exporteur de métriques : dynamique, la base créant des comptes et l'exporteur renouvelant son bail, en lecture seule. La clé du service d'envoi : statique en KV, émise par un tiers et immuable, avec métadonnées et échéance. L'ordonnanceur hérité : statique géré, puisqu'il ne relira pas ses identifiants mais que la cible accepte une rotation, période calée sur ses fenêtres. Les développeurs en préproduction : dynamique à durées courtes, un rôle aux privilèges de préproduction, avec l'imputabilité nominative en prime. 2. Créer côté base le compte de gestion, avec les seuls droits d'administration de rôles. Créer et tester le compte de secours, hors Vault, sous scellé procédural. Configurer la connexion avec son gabarit, sa vérification TLS et sa liste fermée. Vérifier une émission de bout en bout sur un rôle de test. Alors seulement tourner le compte racine. Consigner date, périmètre, emplacement du secours et prochaine vérification. L'ordre proscrit est la rotation avant le secours testé. 3. L'instance en régime établi : aucun impact, son bail renouvelé aux deux tiers couvrant largement quarante minutes ; au pire un renouvellement échoue et se retente. L'instance qui démarre : bloquée, faute d'émission possible ; c'est le cas qui dimensionne la haute disponibilité et justifie des retentatives espacées plutôt qu'un échec sec. Le traitement nocturne en statique géré : la rotation programmée est manquée puis rattrapée, le mot de passe courant restant valide entre-temps ; impact nul s'il lit son chemin à son lancement.

Chapitre 19

1. Il sépare les identifiants de la chaîne de connexion : Vault les substitue à chaque usage, donc la rotation du compte racine peut changer le mot de passe sans réécrire la configuration. En dur, le mot de passe est fossilisé : la rotation devient impossible sans reconfiguration, et la valeur traîne dans la configuration du moteur.

2. La base elle-même refuse le compte après l'échéance, indépendamment de Vault. C'est le traitement, dans le SQL, du cas « Vault indisponible à l'échéance ». La révocation par Vault reste le nettoyage, mais l'accès meurt à l'heure quoi qu'il arrive : ceinture et bretelles.

3. Parce que la révocation exécute une suppression de rôle, et qu'un rôle propriétaire d'objets ne se supprime pas proprement. La révocation échoue, le bail se coince, le compte devient orphelin. Les comptes fabriqués consomment le schéma ; la définition de structure appartient aux migrations, sous une identité distincte et durable.

4. L'un fabrique : un compte neuf par lecture, sous bail, détruit à l'échéance. L'autre distribue : la valeur courante du mot de passe d'un compte permanent que Vault fait tourner, sans bail de destruction. Règle : un statique géré lu par dix consommateurs redevient un secret partagé. Un compte géré, un consommateur, une policy.

5. L'utilisateur IAM crée des objets réels, révocables à l'instant, mais lourds et soumis aux quotas. Le rôle assumé rend des credentials temporaires, légers, sans rien à nettoyer, et non révocables avant l'heure. Le jeton de fédération partage ces propriétés d'expiration avec des exigences élargies côté compte racine. Règle : le rôle assumé par défaut avec des durées courtes, la durée étant la seule défense d'un credential irrévocable ; l'utilisateur IAM quand la révocabilité immédiate est exigée.

6. Dix clés au plus par compte de service : un rôle qui génère plus vite qu'elles n'expirent sature le quota et bloque les émissions. D'où la préférence aux jetons courts, qui ne créent rien, les clés étant réservées aux consommateurs qui l'exigent, avec le calcul de quota écrit au dossier.

7. KV changerait l'emplacement, pas le modèle : même clé pour tous, éternelle, révocable seulement en la changeant partout. L'autorité change les quatre défauts : la clé privée de chacun ne voyage jamais, les certificats vivent trente minutes, signature et connexion sont nominatives des deux côtés, et la révocation d'urgence est le retrait du droit de faire signer.

8. Un certificat valide qui ouvre une connexion sans terminal interactif : l'authentification réussit, la session est inutilisable, et le symptôme ne pointe pas sa cause. Il se corrige dans le rôle, pas chez les clients : la politique des extensions appartient à l'autorité.

9. La méthode d'authentification permet aux pods de prouver leur identité à Vault pour obtenir des tokens. Le moteur de secrets, depuis la version 1.11, permet à Vault de fabriquer des accès à Kubernetes : des jetons de comptes de service éphémères, bornés à un namespace. Cas type : remplacer les fichiers de configuration longue durée de l'outillage et de la CI par des jetons de quelques minutes, tracés.

Mise en pratique du chapitre 19. 1. Côté base, un compte de gestion dédié aux analystes et un compte de secours testé hors Vault. Connexion avec gabarit d'identifiants, vérification TLS complète, liste fermée d'un seul rôle, puis rotation du compte racine. Rôle : création d'un rôle avec mot de passe et échéance, puis droit de lecture sur le schéma analytique ; révocation explicite avant suppression. Durées : deux heures par défaut, la session interactive annoncée, plus court forçant des reconnexions en pleine analyse ; huit heures de plafond, la journée de travail. Policy d'une règle, attachée aux entités de l'équipe via leur groupe. 2. Ordre : monter l'autorité et le rôle. Déployer la clé publique et sa directive de confiance sur les hôtes par la gestion de configuration, les clés partagées restant en place, la coexistence étant native. Équiper les personnes, signature testée par chacune. Période de coexistence courte et datée, pendant laquelle l'usage de l'ancienne clé se surveille dans les journaux, son empreinte étant connue. Critère de suppression : zéro connexion par l'ancienne clé sur la période, et toutes les personnes ayant réussi le nouveau rituel. Alors retrait de la clé publique partagée de tous les hôtes, destruction consignée des copies privées recensées, et l'entrée du registre clôt le constat 6. 3. Cause A : révocations échouées, la base ayant été injoignable aux échéances. Cause B : usage de la révocation forcée, le bail ayant été supprimé côté Vault sans confirmation du nettoyage. Diagnostic par l'audit, en cherchant les échecs de révocation et les révocations forcées sur la période ; côté base, les échéances des comptes orphelins pointent vers des suppressions jamais exécutées. Traitement : suppression manuelle des rôles orphelins, qui sont de toute façon refusés à la connexion si leur échéance est passée, correction de la cause d'injoignabilité, et rappel de doctrine, la révocation forcée abandonnant la garantie de nettoyage et imposant le traitement manuel côté cible dans le même ticket.