Aller au contenu

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

Chapitre 10

1. Toute méthode expose un chemin de login non authentifié, vérifie une preuve, localement ou auprès d'un amont qui fait autorité, et émet un token dont les propriétés viennent de la configuration Vault. La configuration de méthode fixe où et comment vérifier ; le rôle découpe la population et fixe ce que les tokens portent : policies, durées, origines.

2. Parce que leur fonction est de produire le token : exiger un token en amont serait circulaire. Conséquence : chaque méthode activée ajoute un point d'entrée exposé sans authentification. On n'active que ce qui a une population, on désactive le reste, et les échecs de login se surveillent.

3. Le role_id identifie : stable, peu sensible, il vit dans la configuration. Le secret_id prouve : sensible, livré à part, périssable, à usages comptés, bornable en origine. C'est la séparation du chapitre 1 entre ce qui peut circuler et ce qui confère le pouvoir, appliquée au secret zéro lui-même.

4. Le pod présente le jeton de son compte de service, identité que la plateforme génère, monte et renouvelle : rien n'a été distribué par vous, le secret zéro disparaît. En contrepartie, l'API du cluster devient un système d'identité amont de votre modèle de menace : sa compromission fabrique des identités que Vault honorera.

5. En mode jwt, le client détient déjà un jeton signé et le présente directement : machine à machine, la CI en est le cas d'école. En mode oidc, Vault orchestre le flux interactif : l'humain s'authentifie chez son fournisseur, avec le mot de passe et le MFA d'entreprise, et revient avec le jeton.

6. L'émetteur signe des jetons pour des dizaines d'usages : la validité cryptographique prouve l'origine, pas la destination ni le contexte. Deux familles de bornes ferment cela : l'audience, qui exige que le jeton ait été émis pour Vault, et les claims, qui fixent le contexte accepté. Sans elles, le rôle accepte tout ce que l'émetteur signe.

7. Chez le fournisseur d'identité : un seul enrôlement, une seule politique, une seule procédure de récupération pour toute l'entreprise, dont Vault hérite. Un MFA Vault en plus doublerait les coûts sans gain. Le Login MFA de Vault, disponible en édition Community depuis la version 1.10, garde sa place là où il n'y a pas de fournisseur en amont : comptes locaux résiduels, comptes de secours, environnements sans fédération.

8. Humains, oidc, secret zéro supprimé, confiance dans le fournisseur d'identité. Pods, kubernetes, supprimé, l'API du cluster. Charges cloud, méthodes du fournisseur, supprimé, son IAM. Pipelines, jwt, supprimé, l'émetteur de la forge. Machines nues, approle, résiduel mais réduit et borné, Vault seul. Parc à PKI mûre, cert, résiduel et long, la PKI et sa révocation. Laboratoire et secours, userpass, résiduel, Vault seul.

9. L'imputabilité : un rôle partagé fond toutes les applications en une seule identité d'audit. Le moindre privilège : une seule liste de policies force au plus large commun. La révocation : changer la preuve devient un événement collectif, donc différé. Un rôle par application rétablit les trois.

Mise en pratique du chapitre 10. 1. a) Méthode du cloud concerné : les fonctions ont une identité managée, le rôle est borné au compte et au projet, la confiance importée est l'IAM du fournisseur, le secret zéro disparaît. b) oidc vers le fournisseur existant, rôle n'attachant que default, droits portés par des groupes externes ; confiance dans le fournisseur, MFA géré là-bas. c) approle : machine nue, aucun amont. Rôle dédié à l'agent, secret_id à usage unique livré sous enveloppe, doubles bornes d'origine. Le secret zéro subsiste, réduit. d) jwt sur l'émetteur de la forge, rôle borné par audience et claims ; aucun secret stocké dans les pipelines. e) cert est la seule méthode compatible, mais la condition n'est pas remplie : sans PKI outillée, on créerait des clés privées longues à révocation théorique. La recommandation honnête est de construire d'abord la maturité PKI, puis d'activer cert. 2. Les deux populations concernées sont c), dont le secret_id est le secret d'amorçage, et e), dont la clé privée joue ce rôle. Les mesures qui en bornent la portée : livraison sous enveloppe à usage unique et courte durée, bornes d'origine, durées de token courtes avec plafond, révocation par accessor sans manipuler la valeur. 3. Du plus au moins souhaitable : a) et d), où la plateforme fournit l'identité ; b), où la preuve vient de l'annuaire ; c), où le secret zéro subsiste mais reste borné et renouvelable ; e), où il subsiste dans un objet à cycle de vie long que l'organisation ne sait pas renouveler. Pour améliorer les deux dernières : outiller une PKI interne à certificats courts pour la flotte, et rapprocher l'agent d'une identité de plateforme dès que la machine cesse d'être isolée.

Chapitre 11

1. Refus par défaut en l'absence de règle applicable. Union, les policies du token s'additionnant et une seule règle accordante suffisant. deny prioritaire, unique règle soustractive. Et évaluation sur le couple chemin réel et capability requise par l'opération HTTP. Conséquence : ajouter une policy ne peut qu'ouvrir, sauf deny, d'où l'importance de la portée de chacune.

2. Le minimum vital d'un token envers lui-même : se consulter, se renouveler, se révoquer, accéder à son cubbyhole. Elle est attachée d'office à presque tous les tokens. Sa lecture est un exercice de grammaire sur un document réel, court et canonique, et elle apprend ce qu'on retire le jour où on l'exclut d'un rôle.

3. *, en fin de motif seulement, absorbe tout le reste du chemin : le bon choix pour un sous-arbre. + vaut exactement un segment, n'importe où : le bon choix pour un motif transverse comme toutes les applications sur un même objet de production. Ce ne sont pas des expressions régulières, et le besoin de plus est un signal d'arborescence à revoir.

4. create vaut pour l'écriture d'un chemin inexistant, update pour un chemin existant. Le client ne sachant pas toujours lequel s'applique, un rôle qui n'a que l'un des deux échoue par intermittence, selon l'existence préalable du chemin. D'où la pratique de les accorder ensemble sur les préfixes d'écriture.

5. Parce qu'énumérer est un pouvoir en soi : l'inventaire des chemins renseigne même sans lire une valeur, les noms parlant. On l'accorde donc délibérément. Pour KV v2, il s'accorde sur les chemins de métadonnées, où l'énumération opère.

6. sudo déverrouille l'accès aux chemins protégés, en plus de la capability d'opération requise ; seul, il ne donne rien. L'exemple du fil rouge est ops-audit, dont les règles portent sudo parce que la gestion des dispositifs d'audit est un chemin protégé.

7. La commande émet une requête sur le chemin réel contenant data/. La capability requise est read sur ce chemin. La policy ne couvre que le chemin logique, qui ne correspond à aucune requête réelle. Aucune règle ne s'applique, refus par défaut, 403 après authentification réussie : c'est l'étape 4 du cycle qui refuse. Correction : réécrire sur les deux familles de chemins réels.

8. Mettre en forme, publier depuis un dépôt versionné et revu, puis tester sous un token dédié portant la seule policy visée, avec une grille de cas incluant les accès qui doivent échouer. Une policy se définit autant par ses refus que par ses accords, et root ne teste rien. Outils d'appoint : la consultation des capabilities sur un chemin, et l'option qui dérive la policy minimale d'une commande.

9. Trois familles : l'écriture des policies, qui permet de s'écrire tous les droits ; la gestion des rôles d'authentification, qui permet de s'attacher n'importe quelle policy ; la gestion de l'audit, qui permet de s'effacer. Gouvernance : périmètre réduit à admin, usage alarmé, revue régulière de qui peut modifier les droits. L'édition Enterprise ajoute Sentinel, pour des conditions riches, et les control groups, pour l'approbation multi-personnes à la requête.

Mise en pratique du chapitre 11. 1.

path "sys/audit" {
  capabilities = ["read", "sudo"]
}
path "sys/audit/*" {
  capabilities = ["create", "update", "delete", "sudo"]
}
path "sys/health" {
  capabilities = ["read"]
}

La consultation porte sur la liste, l'activation et la désactivation sur chaque dispositif nommé. Les deux familles étant protégées, chaque bloc porte sudo. 2.

path "secret/data/billing/preprod/*" {
  capabilities = ["read"]
}
path "secret/metadata/billing/preprod/*" {
  capabilities = ["read", "list"]
}

Lecture des valeurs et de l'état des versions, énumération, et aucune capability d'écriture ni de suppression. 3.

path "secret/data/billing/prod/*" {
  capabilities = ["read"]
}
path "secret/metadata/billing/prod/*" {
  capabilities = ["list", "read"]
}
path "secret/data/billing/prod/interne/*" {
  capabilities = ["deny"]
}
path "secret/metadata/billing/prod/interne/*" {
  capabilities = ["deny"]
}

Le deny, prioritaire sur toute autre policy du même token, scelle le sous-arbre sur les deux familles de chemins : l'exception chirurgicale dans son cas d'usage légitime.

Chapitre 12

1. Sa valeur ne contient aucun attribut : policies, durées et filiation vivent dans le magasin, indexés par une empreinte salée. La valeur n'est qu'une référence, et le stockage volé ne livre pas de tokens utilisables. Les préfixes de type existent depuis la version 1.10 : ils servent au diagnostic et aux scanners de fuites, pas à la sécurité.

2. Service : persisté, renouvelable, révocable individuellement, descendance possible, cubbyhole. Batch : non persisté, non renouvelable, non révocable à l'unité, sans enfants ni cubbyhole, coût serveur quasi nul. Règle : service par défaut, batch quand le volume éphémère l'exige et que la perte de la révocation unitaire est acceptable.

3. Le TTL est la fenêtre courante, que le renouvellement repousse. Le plafond est compté depuis l'émission et rien ne le franchit : au plafond, ré-authentification obligatoire. C'est une vertu parce que la ré-authentification repasse par le rôle, ses bornes, ses policies et son existence : un rôle durci ou supprimé reprend effet au plus tard au plafond.

4. Un token renouvelable indéfiniment par fenêtres, sans plafond : l'outil des services au long cours qui savent renouveler mais pas se ré-authentifier. Deux contreparties : superviser le renouvellement, dont l'arrêt est une mort silencieuse du service, et surveiller l'existence même, un périodique volé et renouvelé vivant sans fin.

5. Tout token créé par un autre est son enfant, et la révocation cascade sur la descendance. Exception : les tokens issus d'un login naissent sans parent. L'orphelin survit à tout parent : légitime pour un traitement qui doit survivre à la session qui l'a lancé, et rare, car la bonne question est presque toujours pourquoi ce traitement n'a pas sa propre authentification.

6. Une seconde référence qui permet de consulter et de révoquer un token sans pouvoir l'utiliser. La chaîne d'incident : l'audit journalise l'accessor de chaque requête et jamais le token ; on repère l'activité suspecte, on lit l'accessor, on révoque par accessor. Le défenseur coupe le sésame sans l'avoir jamais détenu.

7. La réponse demandée est rangée dans le cubbyhole d'un token à usage unique et à durée courte ; le destinataire l'ouvre une fois, et une consultation dédiée permet d'inspecter sans consommer. Trois propriétés : minimisation, les intermédiaires ne voyant qu'une enveloppe ; péremption, une enveloppe non réclamée mourant ; détection, l'usage unique faisant qu'une ouverture par un intercepteur rend l'ouverture légitime impossible. L'échec chez le destinataire prouve la compromission du canal avant que le secret n'ait servi.

8. Il borne les origines réseau depuis lesquelles le token est accepté : la copie volée sans la position ne vaut rien. Ce n'est pas une violation du Zero Trust, le réseau n'y servant pas de preuve, l'authentification et les policies demeurant. C'est une couche de profondeur, comme une durée dans une autre dimension. Limites : traduction d'adresses et intermédiaires élargissent la borne de fait.

9. Token humain dans le fichier d'aide et non dans une variable d'environnement, ce qui ferme /proc et l'héritage. Jamais en argument de commande, ce qui ferme l'historique. Jamais transmis entre acteurs, chacun ayant son identité et l'enveloppe existant pour les données. Renouvellement scripté ou délégué, ce qui ferme la mort silencieuse. Et révocation de fin de session, qui ferme les tokens abandonnés.

Mise en pratique du chapitre 12. 1. Service, via le rôle de l'ordonnanceur : une heure de TTL, huit heures de plafond pour couvrir les six heures avec marge, renouvellement scripté en cours de traitement. Pas de période : le plafond suffit et se referme seul. 2. Batch : dix mille tokens de quelques minutes non persistés, cas exact du volume éphémère. Durée de cinq minutes, policies minimales ; la révocation unitaire perdue est acceptable à cette durée. 3. Response wrapping : la donnée part dans le cubbyhole d'un token à usage unique, avec une enveloppe de quelques minutes. Le système de déploiement ne transporte que l'enveloppe, et toute interception se détecte à l'ouverture. 4. Service périodique, créé par un rôle prévu pour, policies réduites à la supervision, renouvellement supervisé et token inventorié. C'est le cas d'usage légitime du périodique, avec ses deux contreparties assumées.

Chapitre 13

1. L'entité est l'acteur canonique, avec nom, métadonnées et policies propres. L'alias rattache une méthode d'authentification à cette entité. Le groupe rassemble des entités et porte des policies. C'est l'implémentation du principe 2.2 : droits et imputabilité suivent l'identité, quel que soit le moyen de preuve du jour.

2. Au premier login d'une identité inconnue, Vault crée entité et alias automatiquement, avec des noms techniques : c'est le filet qui garantit qu'une identité existe toujours. La pratique propre pré-crée malgré tout, parce que l'audit se lit avec ces noms, que les policies d'identité s'attachent à ces objets, et que les entités durent plus longtemps que leurs méthodes.

3. Interne : membres gérés dans Vault. Externe : pas de membres gérés, mais un alias vers une méthode, l'appartenance étant déclarée par l'amont à chaque login. Répartition : le fournisseur gère qui appartient à quoi, Vault gère ce que chaque groupe a le droit de faire, et la jointure est une déclaration d'une ligne.

4. La preuve est présentée à la méthode, dont le rôle borne la population et fixe durées et bornes. Elle produit un alias, qui désigne une entité, laquelle appartient à des groupes. Le token porte l'union des policies du rôle, de l'entité et des groupes, plus default sauf exclusion, avec l'entity_id dans chaque entrée d'audit.

5. Parce que les policies d'entité et de groupe sont résolues au moment de l'usage, pas figées à l'émission. Modifier le groupe équipe ou dégraisse immédiatement tous les tokens vivants de ses membres. C'est le levier d'administration courant : accorder ou retirer un droit à une population sans attendre les re-logins.

6. Un : méthode et rôle durcis, bornes et durées des chapitres 10 et 12. Deux : entité pré-créée et alias déclaré au role_id. Trois : secret_id généré sous enveloppe, wrapping du chapitre 12. Quatre : ouverture, login, token rangé en fichier strict en mémoire, canaux de fuite du chapitre 1 fermés. Cinq : vérifications, refus compris, et lecture d'audit. Six : rotation par déploiement et destruction des secret_id orphelins par accessor.

7. Le role_id, comportement documenté. Avec un autre nom, l'alias ne joint jamais : au premier login, l'auto-création fabrique en silence une seconde entité technique, et l'entité soignée reste orpheline. Le symptôme est un entity_id inattendu à la première consultation du token, et c'est pour cela que la vérification en fait partie.

8. L'enveloppe est à usage unique. Si le destinataire ne peut pas l'ouvrir, elle est expirée, incident bénin qui appelle une relivraison, ou déjà ouverte, ce qui signifie que quelqu'un a lu le secret en chemin. Le second cas est une compromission certaine du canal, détectée avant tout usage légitime : destruction du secret_id par accessor, relivraison par un canal sain, enquête. La consultation sans consommation et les journaux du déploiement départagent les deux cas.

9. Une même entité rattachée par plusieurs alias à plusieurs méthodes : un acteur, plusieurs preuves, une seule histoire d'audit et un seul jeu de policies d'identité. Pendant une migration, c'est ce qui évite de fendre l'imputabilité en deux acteurs au moment où l'on a le plus besoin de suivre qui fait quoi.

Mise en pratique du chapitre 13. 1. Côté Vault : activer un montage jwt nommé jwt-github, le configurer sur l'émetteur de la forge avec l'URL de découverte et l'émetteur assorti. Rôle ci-billing : type jwt, audience dédiée à Vault, claims verrouillant le sujet sur le dépôt et sa branche principale, user_claim pour nommer l'identité, policies ci-deploy, durée de dix minutes sans renouvellement attendu. 2. Identité : entité ci-billing pré-créée avec métadonnées de dépôt et de propriétaire, alias sur l'accessor du montage, au nom du user_claim retenu. 3. L'entrée d'audit montrera l'entity_id, l'accessor du token, le chemin écrit, l'opération, l'horodatage et le résultat, valeurs en empreinte. Ce que la chaîne n'a pas eu à livrer : aucun secret, ni mot de passe, ni secret_id, ni token durable dans la forge. La preuve est le jeton d'exécution signé par la forge, éphémère et contextuel : le secret zéro est supprimé, réponse structurelle à l'incident Codecov du chapitre 1.