Chapitre 10. Les méthodes d'authentification

Objectifs pédagogiques¶

Décrire le schéma commun à toutes les méthodes. Situer userpass, AppRole, Kubernetes, JWT et OIDC, les méthodes cloud et les certificats clients. Positionner le MFA de connexion. Appliquer une grille de choix par population et lire chaque choix comme un import de confiance.

Prérequis¶

Chapitres 4, 5, 8 et la section 1.9, dont ce chapitre est la réponse.

Cours¶

10.1 Le schéma commun¶

Toutes les méthodes font la même chose. Une méthode est un composant monté sous auth/ ; elle expose un chemin de connexion servi sans token, auquel un client présente une preuve : mot de passe, couple d'identifiants, jeton signé par un tiers, certificat. La méthode vérifie la preuve, localement ou auprès du système amont qui fait autorité, puis émet un token dont les propriétés ne viennent pas de la preuve mais de la configuration côté Vault.

Cette configuration vit à deux niveaux. La configuration de méthode dit où est l'annuaire, quelle autorité de certification, quel émetteur de jetons. Les rôles découpent la population en profils : tel rôle accepte telle sous-population et attache aux tokens émis telles policies, telles durées, telles bornes. Le rôle est l'objet central : c'est lui qui traduit « qui » en « quoi ».

Les paramètres de rôle qui reviennent partout : token_policies, token_ttl et token_max_ttl, token_bound_cidrs.

Conséquence de sécurité immédiate : chaque méthode activée ajoute un chemin de connexion non authentifié à la surface d'attaque. On active ce qui sert, on désactive ce qui ne sert plus, et l'inventaire des méthodes fait partie des revues périodiques.

10.2 userpass¶

Vérifie un mot de passe salé et haché par Vault. Sa place est celle que le fil rouge lui donne : [Laboratoire], apprentissage, démonstrations, bootstrap, et parfois un compte de secours documenté et surveillé.

Sa non-place est aussi nette : la population humaine réelle. Des comptes locaux à Vault, c'est un cycle de vie des arrivées et départs à gérer une seconde fois, sans lien avec l'annuaire, sans le MFA de l'entreprise, avec un mot de passe de plus par personne.

10.3 AppRole¶

Le cas le plus courant est le plus inconfortable : une application sur une machine ordinaire, sans plateforme pour attester quoi que ce soit. Il faut bien qu'elle présente quelque chose, et ce quelque chose devra lui être remis : le secret zéro dans sa forme nue. AppRole ne le fait pas disparaître, c'est impossible ici ; il le réduit, le borne et le trace.

Le modèle découpe le credential en deux moitiés de statut différent. Le role_id identifie le rôle : identifiant stable et peu sensible, qui peut vivre dans la configuration de déploiement. Le secret_id est la preuve : sensible, conçu pour être remis par un canal séparé, avec une durée courte et un nombre d'usages limité.

Toute la valeur d'AppRole tient dans les propriétés du secret_id : livrable à part, périssable par secret_id_ttl, consommable par secret_id_num_uses=1 de sorte qu'une copie volée après usage est un déchet, et bornable en origine. Le secret zéro résiduel devient un objet minuscule : quelques minutes, un usage, une adresse source.

10.4 Kubernetes¶

Dans un orchestrateur, le problème change de nature : le pod a déjà une identité, son compte de service, attesté par un jeton que la plateforme lui monte. Le pod présente ce jeton, Vault le fait valider par l'API du cluster, et le rôle borne qui est accepté par bound_service_account_names et bound_service_account_namespaces.

La portée est considérable : c'est la première réponse complète au secret zéro, puisque aucun secret n'a été distribué. Le prix est celui qu'énonce le chapitre 5 : la confiance est importée, l'API du cluster devient un système d'identité amont, et sa compromission fabrique des identités que Vault honorera.

10.5 JWT et OIDC¶

Une famille, deux modes. Socle commun : un fournisseur d'identité émet des jetons signés, Vault vérifie les signatures et applique ses rôles. La confiance est importée ; ce que Vault contrôle, ce sont les bornes du rôle.

Le mode jwt, machine à machine. Le client détient déjà un jeton et le présente au login. Cas du fil rouge : la CI. GitHub Actions émet pour chaque exécution un jeton décrivant le contexte, dépôt, branche, déclencheur. Le montage jwt-github est configuré sur cet émetteur, et le rôle ci-billing verrouille : bound_audiences pour que le jeton ait été émis pour Vault, bound_claims sur le sujet pour restreindre au dépôt et à la branche, user_claim pour nommer l'identité, policies ci-deploy, TTL bref. Le pipeline s'authentifie sans aucun secret stocké dans la forge.

Le mode oidc, les humains. Le client n'a pas encore de jeton : Vault orchestre le flux interactif, redirection vers le fournisseur, authentification là-bas avec le mot de passe et le MFA d'entreprise, retour avec un jeton.

[Démonstration]. La fédération, côté Vault :

vault auth enable oidc

vault write auth/oidc/config \
  oidc_discovery_url="https://keycloak.astrea.lab/realms/astrea" \
  oidc_client_id="vault" \
  oidc_client_secret=- \
  default_role="astrea-users"

vault write auth/oidc/role/astrea-users \
  role_type="oidc" \
  user_claim="preferred_username" \
  groups_claim="groups" \
  allowed_redirect_uris="https://vault-core-01.astrea.lab:8200/ui/vault/auth/oidc/oidc/callback" \
  allowed_redirect_uris="http://localhost:8250/oidc/callback" \
  token_policies="default" \
  token_ttl=1h

Le secret de client est saisi par l'entrée standard. Les deux URL de retour couvrent les deux clients légitimes, interface web et CLI qui écoute localement ; toute autre destination est refusée, et c'est une borne de sécurité. Enfin le rôle n'attache que default : les droits viendront des groupes, le claim groups étant mappé sur des groupes externes qui portent les policies. L'appartenance se gère dans le fournisseur d'identité, les droits dans Vault.

Point cardinal de la famille : un jeton valide de l'émetteur n'est pas un jeton acceptable. Un fournisseur d'entreprise émet des jetons pour des dizaines d'usages ; GitHub en émet pour tous les dépôts du monde. Sans bound_audiences et bound_claims, un rôle accepte tout ce que l'émetteur signe. Les bornes ne sont pas un raffinement : elles font la différence entre une fédération et une porte ouverte.

10.6 Les méthodes cloud¶

Même raisonnement que Kubernetes avec les moyens de chaque plateforme : la machine ou la fonction possède une identité gérée par le fournisseur, et Vault sait la vérifier auprès de lui. Zéro secret distribué, rôles bornés sur les identifiants de la plateforme, confiance importée depuis l'IAM du fournisseur avec la dépendance de disponibilité et de juridiction que cela implique.

Les clouds sont des deux côtés de Vault : on peut s'authentifier par eux, et obtenir des credentials pour eux (chapitre 19).

10.7 Les certificats clients¶

La méthode cert authentifie par certificat client TLS : le listener réclame un certificat, la méthode le valide contre les autorités configurées et le mappe vers des policies. C'est la méthode des parcs qui possèdent déjà une PKI machine sérieuse.

Ses exigences sont celles de toute PKI : émission courte, renouvellement outillé, et surtout révocation effective, dont le chapitre 17 montrera qu'elle est le talon d'Achille de X.509. Sans cette maturité, cert recrée des secrets longs avec une révocation théorique.

10.8 Le MFA de connexion¶

Note de version : le Login MFA est disponible en édition Community depuis la version 1.10 ; les formes antérieures relevaient de l'édition Enterprise. Le principe : exiger un second facteur au moment du login, par une règle d'application ciblant une méthode, une entité ou un groupe.

L'architecture commande de se poser d'abord la question du bon étage. Pour les humains fédérés, le MFA appartient au fournisseur d'identité : un seul enrôlement, une seule politique, une seule procédure de récupération pour toute l'entreprise. Le Login MFA de Vault trouve sa place là où il n'y a pas de fournisseur en amont : les comptes locaux résiduels (un compte de secours userpass est un excellent candidat) et les environnements sans fédération.

10.9 La grille de choix¶

Deux questions, dans cet ordre : que devient le secret zéro, et quelle confiance importe-t-on ?

Population	Méthode	Secret zéro	Confiance importée
Humains	oidc	supprimé, session et MFA du fournisseur	le fournisseur d'identité
Pods Kubernetes	kubernetes	supprimé, identité de plateforme	l'API du cluster
Charges cloud	aws, azure, gcp	supprimé, identité managée	l'IAM du fournisseur
Pipelines CI	jwt	supprimé, jeton d'exécution	l'émetteur de la forge
Applications sur machines nues	approle	résiduel (réduit, borné, tracé)	Vault seul
Parc à PKI machine mûre	cert	résiduel long (clé privée)	la PKI et sa révocation
Laboratoire, bootstrap, secours	userpass	résiduel (mot de passe)	Vault seul

Règle de synthèse : toujours préférer une identité de plateforme quand elle existe, puisqu'elle supprime le problème le plus dur du chapitre 1. AppRole est la réponse par défaut quand rien n'existe, et sa qualité dépendra de la discipline de livraison du chapitre 13. Chaque ligne de la colonne de droite s'ajoute à votre périmètre d'analyse : choisir une méthode, c'est choisir ses garants.

Exemple : la carte des identités d'Astrea¶

Cinq lignes, cinq justifications, aucune méthode ouverte sans population désignée.

billing sur app-billing-01 : machine nue, donc approle, rôle billing, policies billing-kv puis billing-db, token d'une heure, bornes sur 10.10.30.21.

billing sur k8s-astrea : kubernetes, rôle billing-k8s, borné au compte de service et au namespace, avec la continuité d'identité que le chapitre 13 assurera.

La CI : jwt sur le montage jwt-github, rôle ci-billing borné au dépôt et à la branche principale, audience dédiée, policies ci-deploy, plus aucun secret durable dans la forge.

Les humains : oidc vers le fournisseur d'entreprise, rôle astrea-users n'attachant que default, droits portés par les groupes externes, MFA géré en amont.

userpass demeure, réduit à un compte : laboratoire et secours assumés, connexions surveillées, suppression programmée le jour où la procédure de secours fédérée sera éprouvée.

Sécurité : surface, dépendance, résiduel¶

La surface. Chaque méthode activée est un chemin de login non authentifié exposé. On n'active que ce qui a une population, on désactive le reste, et les échecs de login sont un signal d'audit de premier ordre.

La dépendance. Les méthodes fédérées importent la confiance de leur amont. Sa compromission fabrique des identités valides chez vous, et les bornes de rôle ne compensent pas un amont compromis : elles réduisent ce qu'un jeton légitime mais trop large permettrait.

Le résiduel. Là où un secret zéro subsiste, tout le chapitre 1 s'applique : livraison contrôlée, durée courte, usage compté, origine bornée. Et la partie de la population qui peut s'en passer doit s'en passer.

Erreurs fréquentes¶

Un rôle JWT sans bornes. Le rôle accepte alors tout jeton signé par l'émetteur, ce qui signifie potentiellement n'importe quel dépôt public (section 10.5).

Traiter le role_id comme un secret, ou le secret_id comme de la configuration. Le premier excès complique pour rien ; le second ruine tout, un secret_id versionné recréant exactement le constat du chapitre 1 (sections 10.3, 13.4).

Un rôle unique pour toutes les applications. Imputabilité détruite, moindre privilège impossible, révocation collective. Un rôle par application, comme une identité par acteur.

userpass pour la population humaine réelle. Une base de comptes parallèle à l'annuaire, sans MFA d'entreprise, avec des départs à gérer deux fois (section 10.2).

Le MFA en double, ou nulle part. Empiler un MFA Vault sur des comptes déjà protégés double les coûts sans gain ; n'en mettre nulle part laisse les comptes de secours nus (section 10.8).

Des durées de token jamais réglées. Un rôle se crée avec ses durées, pas en attendant (section 10.1).

Multiplier les méthodes pour essayer. Chaque montage oublié est une porte non gardée avec un chemin non authentifié.

Mise en pratique : cinq populations, cinq décisions¶

Sans machine ; le TP 6 exécutera. Réponses commentées en fin de partie.

Pour chacune des cinq populations suivantes, choisissez la méthode, esquissez les bornes du rôle, et nommez la confiance importée.

a) Un lot de fonctions serverless chez un fournisseur cloud, qui doivent lire trois secrets statiques. b) Les développeurs de l'entreprise, déjà dans l'annuaire fédéré, qui consultent les secrets de préproduction de leurs applications. c) Un agent de sauvegarde sur une machine physique isolée, sans orchestrateur ni cloud. d) Les workflows de déploiement d'une forge interne compatible OIDC. e) Une flotte d'équipements réseau anciens, capables seulement de TLS mutuel avec certificats clients ; l'organisation n'a pas de PKI outillée.

Deux de ces populations laissent subsister un secret zéro. Lesquelles, et quelles mesures du chapitre 12 en bornent la portée ?
Classez les cinq réponses de la plus souhaitable à la moins souhaitable du point de vue du secret zéro, et dites ce qu'il faudrait changer pour améliorer les deux dernières.

Questions de compréhension¶

Décrivez le squelette commun à toute méthode, et la répartition entre configuration de méthode et rôle.
Pourquoi les chemins de login sont-ils non authentifiés, et quelle conséquence de surface ?
Expliquez le découpage role_id et secret_id, et rattachez-le au principe de séparation du chapitre 1.
En quoi la méthode Kubernetes supprime-t-elle le secret zéro, et que devient l'API du cluster dans le modèle de menace ?
Distinguez jwt et oidc : qui détient le jeton au départ, et pour quelles populations ?
Justifiez « un jeton valide de l'émetteur n'est pas un jeton acceptable », et citez les deux familles de bornes.
Pourquoi le MFA des humains fédérés appartient-il au fournisseur, et où le Login MFA garde-t-il sa place ?
Reconstituez la grille de choix : méthode, sort du secret zéro, confiance importée.
Donnez trois raisons de préférer un rôle par application à un rôle partagé.

Synthèse¶

Toute méthode échange une preuve contre un token, selon un rôle qui borne la population et fixe policies et durées : le rôle est l'objet à concevoir. Le panorama se lit par le sort du secret zéro : supprimé quand une plateforme fournit l'identité, résiduel sinon, avec AppRole qui le réduit à un objet minuscule livrable proprement. Chaque choix importe la confiance d'un amont que le modèle de menace doit compter, chaque rôle sans bornes est une porte ouverte, chaque méthode inutilisée une surface gratuite. Ce que chaque identité a le droit de faire s'écrit ailleurs : dans les policies, au chapitre 11.