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

Chapitre 38

1. La liaison porte sur le nom du compte de service et sur le namespace. Sans la seconde, un compte homonyme créé dans n'importe quel namespace obtient les droits du rôle : quiconque peut créer un namespace peut donc emprunter l'identité de l'application, ce qui vide le contrôle de sa substance.

2. L'audience garantit que le jeton présenté a été émis pour Vault, et non pour un autre destinataire. Côté pod, elle suppose un volume de jeton projeté demandant explicitement cette audience : le manifeste doit donc être écrit en conséquence, et un jeton par défaut sera refusé.

3. Un compte de service dédié dans le cluster, autorisé à valider des jetons et rien d'autre. Le principe du chapitre 18 s'y applique : c'est le compte racine d'un moteur transposé, avec le moindre privilège côté cible, pour que la compromission de Vault ne donne pas l'administration de la plateforme, et réciproquement.

4. L'injecteur offre la meilleure fraîcheur, puisqu'il maintient les valeurs à jour et suit les baux, au prix d'un conteneur adjacent par pod. Le pilote monte les secrets comme un volume, avec une surface plus discrète et un rafraîchissement moins naturel. L'opérateur offre le meilleur confort et la moins bonne fraîcheur, la valeur étant copiée dans un objet du cluster qui vit sa vie ensuite.

5. Le secret est copié hors de la barrière, où il est protégé par le chiffrement au repos du cluster s'il est activé et par les droits de l'API. Révocation, durées courtes et imputabilité s'arrêtent à cette frontière : révoquer un bail ne retire pas la valeur déjà écrite, et la rotation devient un problème de synchronisation.

6. Les administrateurs de la plateforme deviennent de fait administrateurs des secrets, ce qui est intenable sur un cluster mutualisé. La dépendance circulaire au démarrage complique toute reprise. Le stockage persistant exigé par Raft n'est pas également prévisible partout. Et sauvegardes, matériel de scellement et procédures deviennent tributaires de la plateforme.

7. Il permet à Vault de fabriquer des accès au cluster, jetons de comptes de service éphémères et bornés à un namespace, pour l'outillage d'administration et les pipelines. Il traite le constat 6 du chapitre 1 dans sa version Kubernetes : le fichier de configuration à longue durée copié partout est remplacé par un accès de quelques minutes, nominatif et tracé.

8. Parce qu'elles sont lisibles par les moyens du chapitre 1 et, dans le monde des conteneurs, par l'inspection du conteneur, qui affiche la configuration complète à quiconque dispose du socle d'exécution. Elles finissent en outre dans des définitions versionnées et dans les journaux d'outillage. Les patrons corrects sont l'agent adjacent qui écrit un fichier en mémoire, ou l'identité de plateforme.

9. Parce qu'une charge éphémère ne doit rien porter de durable : avec le chiffrement comme service, l'application ne détient aucune clé, seulement le droit d'appeler les opérations. Son image et son système de fichiers ne contiennent alors rien qui vaille d'être volé, et la compromission du conteneur ne donne accès qu'à un droit borné et révocable.

Mise en pratique du chapitre 38. 1. Un rôle liant le compte de service unique aux deux namespaces, avec l'audience exigée, une policy limitée à la lecture du chemin d'émission des credentials de stockage, et des durées alignées sur la vie utile de ces credentials. Le nom de compte reste unique pour que la même identité serve dans les deux namespaces, ce qui est légitime tant qu'ils relèvent de la même équipe et du même niveau de sensibilité ; sinon deux rôles distincts s'imposent. À vérifier en recette : un pod d'un troisième namespace est refusé, et un jeton sans l'audience attendue l'est aussi. 2. Une clé d'API de prestataire de paiement est un secret à forte valeur, dont la compromission a un coût direct. La copier hors barrière la place sous le modèle de sécurité de Kubernetes, où elle sera lisible par les détenteurs des droits de lecture du namespace, présente dans les sauvegardes du cluster, et hors de portée de la révocation. Proposition : l'injecteur avec gabarit, qui rend un fichier en mémoire et suit les changements, l'effort portant sur une annotation et une lecture de fichier. Condition d'acceptation de la synchronisation : uniquement si le chiffrement du magasin est activé et vérifié, si les droits de lecture du namespace sont restreints et audités, si la valeur est de faible sensibilité, et si le périmètre est écrit avec une revue trimestrielle. Ce qui n'est pas le cas d'une clé de paiement. 3. Critères retenus : fraîcheur, surface d'attaque, effort pour l'équipe applicative, compatibilité avec les secrets dynamiques, sort du secret en cas de compromission du cluster. L'injecteur obtient une bonne fraîcheur, une surface moyenne du fait du conteneur supplémentaire, un effort faible après la première fois, une compatibilité complète, et garde le secret hors du magasin du cluster. Le pilote se situe entre les deux, avec un secret présent dans le volume. L'opérateur donne la moins bonne fraîcheur, une surface élargie côté cluster, un effort quasi nul, une mauvaise adaptation aux baux courts, et expose le secret dans le magasin. Règle d'aiguillage : credential dynamique, certificat ou clé, l'injecteur ; valeur de configuration peu sensible avec une équipe qui ne peut pas modifier ses manifestes, l'opérateur sous conditions ; le pilote quand la plateforme le standardise déjà pour d'autres usages.

Chapitre 39

1. Revue par pairs, historique des changements, reproductibilité entre environnements, et comparaison entre l'état déclaré et l'état réel. Cette dernière est devenue un signal de supervision au chapitre 32, la divergence entre les policies actives et le dépôt levant une alerte.

2. L'outil conserve un état décrivant les ressources créées, attributs compris : tout secret créé ou manipulé par lui s'y retrouve en clair. Le problème est structurel plutôt qu'accidentel, le chiffrement du stockage et les droits d'accès limitant l'exposition sans empêcher quiconque peut exécuter l'outil de lire l'état. Règle : le code décrit la structure, jamais les valeurs.

3. Les identifiants secrets et tout credential généré, les valeurs de secrets statiques, les identifiants des comptes racines des moteurs, les tokens. Ils se créent par des gestes tracés, hors du code : commandes d'administration avec enveloppe, pipelines dédiés, ou génération par Vault lui-même, l'état ne voyant alors qu'un identifiant sans valeur.

4. L'outil ne manipule qu'un jeton d'enveloppe à usage unique et à durée très courte : c'est lui qui apparaît dans l'état, et non le secret. Sa fuite ultérieure est sans effet, puisqu'il a déjà été consommé, et une tentative de consommation par un tiers constitue l'alarme d'interception du chapitre 12.

5. La vérification de l'émetteur et de la signature du jeton ; la liaison de sujet, qui restreint à un dépôt et à une référence précise ; la liaison d'audience, qui empêche le rejeu. S'y ajoutent des durées taillées pour la vie d'un travail de pipeline.

6. Parce que sans elle le rôle accepte les jetons d'autres dépôts, potentiellement de toute la plateforme puisque l'émetteur est commun, ce qui donne les droits du pipeline à des tiers. Elle se vérifie par un essai réel : une tentative d'authentification depuis un dépôt ou une branche non autorisés doit échouer, et cet échec se consigne comme preuve de recette.

7. Séparer par environnement en s'appuyant sur les références du dépôt ; préférer l'écriture à la lecture ; fournir des credentials éphémères pour ce que le pipeline doit réellement faire. Quand un pipeline demande à lire un secret de production, la question à poser est : pourquoi l'application ne le lit-elle pas elle-même avec sa propre identité ?

8. Ne pas afficher, en évitant les modes verbeux sur les étapes sensibles ; ne pas passer de secret en argument de commande ; nettoyer les artefacts et fichiers temporaires ; révoquer le token en fin de travail. Le contrôle rétrospectif est une recherche périodique de motifs dans les journaux conservés, avec mise à jour régulière de ces motifs.

9. Le pipeline s'authentifie par jeton d'identité, obtient un token court, demande un accès de déploiement éphémère, construit l'image, la signe sans détenir la clé, publie, déploie, puis révoque son token ; les pods s'authentifient ensuite eux-mêmes. Le constat 4 est dissous parce qu'il n'existe plus de clé dans le pipeline : le problème n'est pas mieux protégé, il n'a plus d'objet.

Mise en pratique du chapitre 39. 1. Gérés en code : les montages avec leurs réglages de durées ; les policies ; les méthodes d'authentification et leurs rôles, liaisons comprises ; les rôles des moteurs dynamiques et leurs instructions ; la création des clés Transit ; les dispositifs d'audit. Exclus : les identifiants secrets, créés à la demande et livrés enveloppés par la CI ; les valeurs des secrets statiques, écrites par leur propriétaire ; les identifiants des comptes racines des moteurs, saisis une fois puis tournés de sorte que plus personne ne les connaisse ; les tokens de seal, créés à la main sur le gardien ; les parts et recovery keys, produites en cérémonie. Justification commune : ces objets sont des valeurs, et toute valeur passée à l'outil se retrouve dans son état. 2. Rôle de préproduction lié à la branche principale, avec une policy accordant l'écriture dans les chemins de préproduction et la lecture d'un accès de déploiement correspondant, sur une durée courte. Rôle de production lié aux étiquettes de version, avec les protections d'étiquettes activées côté dépôt, une policy accordant uniquement l'accès de déploiement de production et la signature d'artefacts, sans aucune lecture des secrets de production. Recette : une exécution sur une branche de fonctionnalité échoue à s'authentifier ; une exécution sur la branche principale obtient le token de préproduction et se voit refuser l'accès à la production ; une exécution déclenchée par une étiquette obtient le rôle de production et se voit refuser l'écriture dans les chemins de secrets. Les trois refus sont consignés. 3. Réponse immédiate : considérer le mot de passe comme compromis et le faire tourner, ce qui suppose une coordination avec la cible s'il s'agit d'un compte statique ; rechercher dans les journaux conservés toutes les autres occurrences de ce motif et des motifs voisins ; vérifier dans l'audit et dans les journaux de la base si des accès inattendus ont eu lieu depuis la date de la fuite. Quatre mesures de fond : supprimer la lecture de secrets de production par le pipeline ; remplacer le secret statique par un credential dynamique quand la cible le permet ; interdire les modes verbeux sur les étapes sensibles et supprimer tout passage de secret en argument ; ajouter la recherche périodique de motifs, avec une rétention alignée sur la fenêtre d'enquête.

Chapitre 40

1. La maîtrise du code, une application non modifiable imposant l'agent. Le nombre d'équipes, l'agent centralisant ce que quinze bibliothèques dupliqueraient. La finesse d'usage, un besoin contextuel ou du chiffrement à chaque requête exigeant un client. La culture d'exploitation, l'agent ajoutant un processus à superviser. Le client direct reste le bon choix pour le chiffrement comme service et pour tout usage qui ne peut pas être précalculé en fichier.

2. L'authentification automatique, qui obtient et entretient le token et le dépose dans un puits, évite à l'application d'implémenter la chaîne du chapitre 13. Les gabarits, qui rendent des fichiers et exécutent une commande de rechargement, lui évitent de connaître Vault, les baux et les renouvellements. Le cache, qui mutualise réponses et renouvellements pour les clients passant par l'écouteur local, évite que la flotte interroge le serveur en parallèle.

3. Depuis la version 1.14, les fonctions de mandataire sont assurées par un binaire distinct, tandis que l'agent conserve l'authentification automatique et les gabarits. Le proxy sert d'intermédiaire pour des clients qui parlent l'API ; l'agent produit des fichiers pour des applications qui n'en parlent pas.

4. Variables au démarrage : simple, mais lisible par les moyens du chapitre 1 et incompatible avec tout changement sans redémarrage, donc avec les baux courts. Fichier rendu avec rechargement : le mode recommandé, en mémoire, permissions strictes, transition sans coupure. Appel direct : nécessaire pour ce qui ne se précalcule pas, au prix d'un code correct.

5. Le rechargement sur signal plutôt que le redémarrage. Un pool qui ouvre les nouvelles connexions avec le credential frais et laisse les anciennes s'éteindre naturellement. Une marge de renouvellement suffisante pour que le nouveau secret existe avant la mort de l'ancien. L'erreur classique est la purge brutale du pool à chaque rotation.

6. Indisponibilité au démarrage : réessais espacés, journalisation claire, sondes tolérantes, jamais l'arrêt immédiat ni la boucle rapide. Indisponibilité en régime établi : continuer, les credentials restant valables, et retenter les renouvellements. Bascule du cluster : quelques secondes d'erreurs, retentées. Credential révoqué ou expiré : réobtenir plutôt que réessayer.

7. Parce qu'elle signale une action à mener et non une attente : retenter avec un credential invalide n'aboutira jamais, quel que soit le nombre d'essais. La distinction évite à la fois les boucles inutiles et l'arrêt d'une application qui aurait simplement dû demander un nouveau credential.

8. L'exception de durée des certificats d'infrastructure, accordée au chapitre 28 faute d'automatisation : l'agent rend le certificat par gabarit et déclenche le rechargement, ce qui permet de revenir à la durée standard. Le contrôle conservé est l'alerte de dernier filet sur l'échéance, parce qu'un renouvellement automatisé peut échouer en silence.

9. Deux chemins de fichiers, un signal de rechargement et une consigne de réessai. C'est l'objectif parce que la sécurité ne tient alors plus à la discipline de quinze équipes applicatives : la logique d'authentification, de durée, de renouvellement et de rotation appartient à l'infrastructure et évolue sans qu'une ligne de code applicatif ne change.

Mise en pratique du chapitre 40. 1. Un bloc de connexion pointant sur le nom de service, jamais sur un nœud. Un bloc d'authentification automatique avec la méthode de la plateforme et la suppression de l'identifiant secret après lecture. Un puits fichier aux permissions strictes, propriétaire dédié, dans un répertoire en mémoire, parce que ce fichier porte les droits complets de l'application. Un premier gabarit pour les credentials de base, destination en mémoire, avec commande de rechargement. Un second pour le certificat client, avec une durée courte et le même rechargement. Un bloc de cache et un écouteur restreint à la boucle locale, pour que l'application appelle le chiffrement comme service sans gérer son propre token, l'écoute au-delà offrant les droits du token à tout voisin. 2. Lire les deux fichiers au démarrage, avec une boucle de réessai à espacement croissant si les fichiers sont absents, puisque l'agent peut ne pas les avoir encore rendus. Construire le pool avec les identifiants lus. Installer un gestionnaire de signal qui relit les fichiers, crée un nouveau jeu de connexions et marque les anciennes comme non réutilisables sans les fermer. Encapsuler les appels de chiffrement dans une fonction qui distingue trois cas : succès, erreur de service donc réessai borné, erreur d'authentification donc relecture du token du puits puis un seul nouvel essai. Sur échec de connexion à la base, ne jamais purger le pool en réaction, mais laisser les connexions valides servir et retenter l'ouverture. Ne journaliser aucune valeur, seulement des identifiants d'erreur et des compteurs. 3. Ce qui fonctionnera : le démarrage, tant que Vault est disponible à cet instant précis, et la première heure de service. Ce qui cassera : à la première expiration du bail, les identifiants deviennent invalides et l'application perd la base sans comprendre pourquoi, puisque rien ne renouvelle ; à la première bascule pendant une lecture, l'appel unique échoue sans réessai ; au premier redémarrage pendant une indisponibilité, l'application ne démarre pas et reste arrêtée. Échéance : la première panne survient au plus tard à l'expiration du premier bail, soit une heure avec les durées du fil rouge. Le dispositif est donc en défaut avant la fin de la journée de mise en service. Conclusion à leur proposer : si l'agent est refusé, la même logique doit être écrite dans l'application, testée et maintenue par l'équipe. Le coût d'exploitation n'est pas supprimé, il est déplacé et dupliqué.