Chapitre 12. Les tokens

Objectifs pédagogiques¶

Lire l'anatomie d'un token et distinguer service et batch. Raisonner sur les durées. Expliquer la filiation et la révocation en cascade. Employer les accessors. Expliquer le cubbyhole et le response wrapping. Borner un token à ses origines. Appliquer l'hygiène de manipulation.

Prérequis¶

Chapitre 4 pour le magasin de tokens et le gestionnaire d'expiration, chapitre 10 pour les rôles qui émettent, chapitre 11 pour les policies véhiculées.

Cours¶

12.1 Anatomie¶

Un token de service est une référence opaque : sa valeur ne contient rien, ni policies ni durées ; tout vit dans le magasin de tokens, indexé par une empreinte salée de la valeur.

Note de version : depuis la version 1.10, les valeurs sont préfixées par type, hvs. pour les tokens de service et hvb. pour les tokens batch. Le préfixe sert le diagnostic et les scanners de fuites, pas la sécurité.

vault token lookup            # le token courant

La sortie est la carte d'identité à savoir lire : policies, ttl, expire_time, num_uses où zéro signifie illimité, orphan, period le cas échéant, entity_id, et accessor. Réflexe de diagnostic devant un 403 : token lookup d'abord, token capabilities ensuite, accuser la policy en troisième.

12.2 Service et batch¶

Le token service est le cas général : persisté, renouvelable, révocable individuellement, capable d'avoir des enfants, doté d'un cubbyhole. Le token batch est son opposé assumé : blob chiffré autonome, non persisté, non renouvelable, sans descendance, sans cubbyhole, non révocable à l'unité. Il vaut jusqu'à son échéance.

Ce dépouillement achète un coût serveur quasi nul par token, ce qui justifie les batch pour le très haut volume éphémère. Règle de choix : service partout, batch quand le volume l'exige et que la perte de la révocation unitaire est acceptable parce que la durée est très courte.

12.3 Les durées¶

Quatre paramètres se combinent. Le TTL est la durée courante ; le renouvellement la repousse, jamais au-delà du TTL maximal compté depuis l'émission. Un token à une heure de TTL et quatre heures de plafond se renouvelle d'heure en heure, quatre heures au plus, puis meurt : le détenteur doit se ré-authentifier, ce qui repasse par le rôle, ses bornes et son existence même.

Le token périodique échappe au plafond : renouvelable indéfiniment par fenêtres. C'est l'outil des services au long cours qui savent renouveler mais ne peuvent se ré-authentifier. Sa contrepartie est nette : un périodique renouvelé vit pour toujours. Sa création est un acte privilégié, et son renouvellement se supervise dans les deux sens, un périodique qui cesse de renouveler meurt en silence, un périodique volé et renouvelé vit sans fin.

Enfin num_uses borne en nombre : un token à usage unique sert une requête et s'éteint, brique dont le response wrapping fera merveille.

Ordres de grandeur du fil rouge : une heure de TTL et quatre de plafond pour l'application, des minutes pour la CI, la journée pour les humains.

12.4 La hiérarchie¶

Tout token créé par un autre est son enfant, et la révocation cascade : révoquer un token révoque toute sa descendance. Les pouvoirs délégués tombent avec le délégant.

Les tokens issus d'un login naissent sans parent : l'authentification fonde une lignée, elle n'en prolonge pas une.

Quand la cascade est indésirable, le token orphelin existe, détaché de tout parent, opération privilégiée. Il est légitime et rare, et sa création s'interroge toujours : si un service a besoin d'un token durable et autonome, la vraie question est pourquoi il ne s'authentifie pas lui-même avec son propre rôle.

vault token revoke <valeur>            # revoque le token ET sa descendance
vault token revoke -mode=orphan <...>  # revoque lui seul, ses enfants survivent

12.5 L'accessor¶

Chaque token naît avec un accessor : une seconde valeur qui permet de consulter et de révoquer le token, mais pas de l'utiliser. C'est la séparation identifiant contre pouvoir appliquée aux tokens eux-mêmes, et elle change l'exploitation : on tient un registre des tokens émis, on audite et on révoque sélectivement, sans jamais stocker un seul token.

Le pont décisif est avec l'audit : le journal contient l'accessor de chaque requête, jamais le token. La chaîne de réponse à incident s'assemble donc ainsi : repérer l'activité suspecte, y lire l'accessor, révoquer par accessor. L'attaquant perd son sésame sans que le défenseur ne l'ait jamais possédé.

L'énumération des accessors vivants est un inventaire précieux et sensible : c'est le pouvoir de tout révoquer, donc un droit d'administration.

12.6 Cubbyhole et response wrapping¶

Le cubbyhole est le montage privé de chaque token de service : un espace que seul ce token lit et écrit, pas root, pas l'administrateur, personne, et qui disparaît avec lui.

Combiné aux usages comptés et aux durées, il devient le mécanisme de livraison le plus élégant du produit. Toute réponse de Vault peut être enveloppée : au lieu de la donnée, l'appelant reçoit un jeton d'enveloppe à usage unique et à durée courte, dans le cubbyhole duquel Vault a rangé la vraie réponse.

[Laboratoire]

# Cote emetteur : demander la reponse enveloppee (TTL de 120 secondes)
vault write -wrap-ttl=120s -f auth/approle/role/billing/secret-id

# Cote destinataire : ouvrir l'enveloppe, une seule fois
vault unwrap <wrapping-token>

# Inspecter sans consommer (origine, date, chemin d'emission)
vault write sys/wrapping/lookup token=<wrapping-token>

Trois propriétés font la valeur. La minimisation : le secret réel ne transite jamais par les mains des intermédiaires ; l'opérateur, le système de déploiement et le canal de transport ne voient qu'un jeton éphémère. La péremption : non réclamée dans le délai, l'enveloppe meurt, et un secret perdu en route cesse d'exister. Et la propriété reine, la détection d'interception : l'usage unique fait qu'un intercepteur qui ouvre l'enveloppe empêche le destinataire légitime de l'ouvrir, et cet échec est une alarme. On sait immédiatement que le canal est compromis, et le secret enveloppé, qui n'a servi à personne, se révoque avant usage.

12.7 Les bornes d'origine¶

token_bound_cidrs restreint l'usage du token à des origines réseau données. Le token de billing, borné à son unique adresse, refuse de fonctionner ailleurs : un vol sans position réseau sur la machine ne rapporte rien.

C'est une couche de défense en profondeur : elle ne remplace ni les durées ni les policies, et le Zero Trust interdit de faire du réseau une preuve. Elle réduit ce qu'une copie exfiltrée permet, comme un TTL dans une autre dimension. Ses limites se connaissent : des origines traduites ou partagées élargissent la borne de fait.

12.8 L'hygiène de manipulation¶

Le token d'un humain vit dans le fichier d'aide de la CLI, aux permissions strictes, pas dans une variable d'environnement : celle-ci reste l'outil des scripts éphémères, jamais du quotidien.

Un token ne se passe pas : ni messagerie, ni ticket, ni fichier partagé. Si un autre acteur doit agir, il a son identité et son rôle ; si une donnée doit lui être remise, l'enveloppe existe.

Le renouvellement se scripte ou se délègue à l'agent du chapitre 40, et se supervise pour les périodiques. Et la fin de session a un geste : vault token revoke -self.

Exemple : la spécification du token de billing¶

Avant de créer quoi que ce soit, l'équipe écrit la spécification du token que le rôle AppRole émettra. Chaque champ est un arbitrage explicite.

Type : service, il faut la révocation individuelle et le renouvellement. Policies : billing-kv, default, et billing-db en partie VI. Durées : une heure de TTL, quatre heures de plafond ; l'application renouvelle d'heure en heure, puis se ré-authentifie, ce qui revalide le rôle et ses bornes. L'alternative du token périodique est examinée et écartée : la ré-authentification AppRole est peu coûteuse, et l'équipe préfère un plafond dur à un renouvellement perpétuel à superviser. Arbitrage documenté, réversible. Usages : illimités, l'application lit à son rythme. Origine : bornée à l'adresse d'app-billing-01. Orphelin : sans objet, les tokens de login n'ont pas de parent.

Sécurité : le token est un porteur¶

Qui le présente est cru : c'est la définition même du secret, et toute la section en découle.

Les défenses se superposent : des durées courtes, la copie volée périme ; des bornes d'origine, la copie volée sans la position ne vaut rien ; des policies minimales, la copie volée dans les bornes n'obtient que son périmètre ; et la révocation par accessor, préparée à froid, qui coupe le reste.

Les canaux de fuite sont ceux du chapitre 1 : arguments de commande, variables d'environnement, journaux applicatifs. L'audit de Vault ne journalise que des empreintes, mais vos applications journalisent ce qu'on leur donne.

Deux objets montent la garde côté administrateur : la liste des accessors, inventaire et pouvoir de révocation massive, et la création d'orphelins et de périodiques, qui doit rester un acte privilégié et inventorié.

Erreurs fréquentes¶

Le token éternel créé à la main. Un secret durable, hors rôle, hors revue, que le chapitre 1 avait déjà décrit. La réponse est toujours une identité et un rôle (chapitre 10).

Confondre TTL et TTL maximal. « Il se renouvelle donc il ne meurt jamais » : si, au plafond. Le maximum se lit dans la consultation du token (section 12.3).

Le périodique sans supervision. S'il cesse de renouveler, mort silencieuse du service ; s'il est volé, vie éternelle de l'attaquant (section 12.3).

Révoquer un parent sans penser à la cascade. Le token d'un opérateur emporte tout ce qu'il a créé (section 12.4).

Stocker des tokens pour pouvoir les révoquer. L'accessor existe exactement pour cela (section 12.5).

Une enveloppe au TTL généreux. Un secret qui traîne et une détection d'interception diluée. Le délai épouse le trajet (section 12.6).

Traiter l'échec d'unwrap comme une erreur technique. C'est une alarme : soit expiration, soit interception (section 12.6).

Mise en pratique : choisir le bon véhicule¶

Sur papier ; réponses commentées en fin de partie. Pour chaque situation, choisissez le type et les paramètres, et justifiez.

Un traitement de nuit qui tourne six heures d'affilée, lancé par l'ordonnanceur, et lit des secrets tout du long.
Une campagne ponctuelle de dix mille tâches parallèles de trente secondes, chacune lisant un secret au démarrage.
La remise d'un credential initial à une application distante, via un système de déploiement auquel on ne veut pas confier le credential.
Un démon de supervision qui interroge l'état de santé indéfiniment, sans procédure de ré-authentification disponible.

Questions de compréhension¶

Pourquoi un token de service est-il une référence opaque, et où vivent ses attributs ? Que signalent les préfixes de type ?
Dressez le tableau service contre batch et la règle de choix.
Expliquez l'articulation TTL, plafond, ré-authentification : pourquoi le plafond est-il une vertu ?
Qu'est-ce qu'un token périodique, quel problème résout-il, quelles sont ses deux contreparties ?
Énoncez la règle de filiation et de cascade, l'exception des tokens de login, et le cas d'usage de l'orphelin.
Qu'est-ce qu'un accessor, et reconstituez la chaîne audit, accessor, révocation.
Décrivez le response wrapping et expliquez pourquoi une interception se détecte.
Que borne token_bound_cidrs, et pourquoi n'est-ce pas une preuve ?
Citez quatre règles d'hygiène de manipulation des tokens.

Synthèse¶

Le token est le véhicule de toute la chaîne : référence opaque côté service, persistée en empreinte, renouvelable, révocable, avec cubbyhole et descendance ; blob autonome côté batch, léger et sans retour, réservé au volume éphémère. Ses paramètres sont des défenses : le TTL et son plafond qui force une ré-authentification revalidante, la période puissante et à surveiller, les usages comptés, les bornes d'origine comme couche de profondeur et non comme preuve. Sa filiation cascade à la révocation, et son accessor donne le pouvoir d'agir sans détenir, clef de voûte de la réponse à incident. Le cubbyhole privé fonde le response wrapping, qui minimise l'exposition, périme les pertes et fait sonner l'interception. Déclenche le TP 5 (énoncé en partie XV).