Chapitre 28. L'entrée unique : répartiteur, TLS de bout en bout, PKI à demeure

Objectifs pédagogiques¶

Justifier l'entrée unique. Trancher la décision qui commande tout, où se termine TLS, et défendre le passage en aveugle. Configurer un répartiteur complet, sondes comprises. Basculer les nœuds sur des certificats de la PKI interne, avec renouvellement automatisé et rechargement sans interruption. Concevoir la redondance de l'entrée et savoir pourquoi Astrea la diffère. Solder la dette du chapitre 17.

Prérequis¶

Chapitre 26 (les deux sondes, qui servent ici telles quelles), chapitre 17 (le rôle d'émission, qui va servir la maison), chapitre 7 (le TLS de laboratoire, qui prend sa retraite).

Cours¶

28.1 Pourquoi une entrée unique¶

Trois raisons, dont deux étaient écrites d'avance.

Les clients : depuis le chapitre 7, tout pointe le nom de service. L'adresse unique était une prophétie, le répartiteur la réalise : les clients ne sauront jamais qu'il y a trois nœuds, ni lequel est actif, ni qu'une bascule a eu lieu.

La PKI : les URL inscrites dans chaque certificat émis portent ce nom précisément parce qu'il devait devenir l'entrée stable. Sans elle, chaque bascule d'actif casserait la récupération des chaînes et des révocations.

L'exploitation : un point d'entrée est un point d'observation et un point de contrôle, à condition de ne pas payer ces commodités au prix des secrets eux-mêmes.

28.2 La décision qui commande tout : où finit TLS¶

Un répartiteur devant Vault a trois postures possibles, et le choix entre elles est la décision de sécurité de l'entrée.

Terminer TLS : le client chiffre jusqu'au répartiteur, qui déchiffre, lit et route. Il voit donc tout en clair, tokens, secrets lus, clairs envoyés à Transit. Il devient un enregistreur universel en cas de compromission, sans avoir ni la barrière, ni le seal, ni l'audit de Vault. Cette posture n'est défendable que si le répartiteur est traité comme un nœud Vault.

Re-chiffrer : le répartiteur termine puis rouvre une session vers le nœud. Il voit toujours tout en clair au milieu : le compromis n'en est pas un pour la confidentialité.

Passer en aveugle : le répartiteur route des octets chiffrés sans les comprendre, la session TLS allant du client au nœud. Il ne voit que des métadonnées et ne peut trahir que la disponibilité, jamais la confidentialité.

C'est la posture d'Astrea, consignée avec sa conséquence assumée : pas d'inspection de requêtes à l'entrée, les tableaux de bord se faisant avec la télémétrie de Vault lui-même.

La règle générale, à retenir telle quelle : la frontière de confidentialité doit s'arrêter sur les nœuds Vault ; tout composant qui voit le clair entre dans cette frontière et doit en payer le prix.

28.3 Les sondes, mises au travail¶

Le chapitre 26 a écrit les deux questions. Le répartiteur pose la première, qui est l'actif, en boucle sur sys/health, et n'accepte que 200. Un standby répond 429 et se marque indisponible pour le trafic : il est sain, il n'est juste pas la bonne porte.

La conséquence dynamique fait la magie de l'ensemble : à la bascule, l'ancien actif cesse de répondre positivement, le nouveau commence, et le répartiteur converge vers le nouvel actif au rythme de sa sonde. Une période de deux secondes et deux échecs de tolérance donnent une convergence en quelques secondes, cohérente avec les neuf secondes d'élection mesurées.

La seconde question, qui est sain, reste posée par la supervision, à part. Le répartiteur route, la supervision veille, et confondre les deux fabrique soit des alertes fausses, soit du trafic mal routé.

28.4 Le répartiteur, configuré¶

[Laboratoire]

# /etc/haproxy/haproxy.cfg -- extrait
frontend vault_entree
    bind 10.10.20.10:8200
    mode tcp                      # couche 4 : passage en aveugle, TLS non termine
    default_backend vault_cluster

backend vault_cluster
    mode tcp
    option httpchk GET /v1/sys/health   # la sonde de ROUTAGE du ch.26
    http-check expect status 200        # 200 = actif ; 429 (standby) = pas de trafic
    default-server inter 2s fall 2 rise 2
    server vault-core-01 10.10.20.11:8200 check check-ssl verify required ca-file /etc/haproxy/astrea-ca.pem
    server vault-core-02 10.10.20.12:8200 check check-ssl verify required ca-file /etc/haproxy/astrea-ca.pem
    server vault-core-03 10.10.20.13:8200 check check-ssl verify required ca-file /etc/haproxy/astrea-ca.pem

Quatre lignes portent tout le chapitre.

Le mode couche 4 est la décision de 28.2, écrite : le trafic traverse chiffré.

La sonde vérifiée est une vraie requête sur la session TLS du nœud, et elle vérifie le certificat contre l'autorité d'Astrea. Un répartiteur qui sonde sans vérifier accepterait de router vers un imposteur.

Le code attendu fait que seul l'actif reçoit du trafic. Le saut supplémentaire par un standby n'existe pas en régime nominal ; il reste la roue de secours si la sonde retarde sur l'élection.

Les temporisations disent la réactivité : deux secondes d'intervalle, deux échecs pour déclarer, deux succès pour rétablir. Assez vif pour suivre une élection, assez amorti pour ignorer un hoquet.

28.5 La PKI prend la maison¶

[Production]. Opération à fenêtre courte par nœud : rechargement des écouteurs

La dette du chapitre 17 arrive à échéance : les nœuds servent encore leur certificat de laboratoire. La bascule demande trois décisions et une valse.

Première décision, le contenu. Chaque nœud reçoit un certificat portant en SAN le nom de service, que les clients vérifient à travers le répartiteur aveugle, son propre nom, pour les sondes et les jonctions, et son adresse.

vault write pki-int/issue/astrea-services \
  common_name="vault.astrea.lab" \
  alt_names="vault-core-01.astrea.lab" \
  ip_sans="10.10.20.11" \
  ttl=720h

Deuxième décision, la durée, et c'est une exception documentée : 720 heures là où les services vivent à 72, parce que ce certificat sert la machinerie qui renouvelle tous les autres. On lui accorde une marge d'un mois avec renouvellement à sept jours de l'échéance. L'exception est datée, motivée, et porte sa propre fin : le chapitre 40 ramènera cette durée à 72 heures quand l'agent aura industrialisé le renouvellement.

Troisième décision, le rechargement. Vault recharge les certificats de ses écouteurs sur signal, sans redémarrage, donc sans redescellement et sans bascule.

# Sur chaque noeud, standbys d'abord (la valse du ch.25) :
#   1. emettre, deposer cert+cle+chaine dans /etc/vault.d/tls/ (0640 root:vault)
#   2. recharger sans interruption :
sudo systemctl reload vault
#   3. verifier ce que voit un client :
openssl s_client -connect 10.10.20.11:8200 -servername vault.astrea.lab \
  -CAfile /etc/ssl/certs/astrea-root-ca.crt </dev/null | grep -E "subject|issuer|Verify"

Le renouvellement s'automatise le jour même : un minuteur par nœud qui émet, dépose, recharge et vérifie, avec une alerte si l'échéance passe sous trois jours sans renouvellement réussi. C'est l'alerte qui transforme l'oubli en ticket au lieu d'un incident.

La clôture solde les comptes : la confiance de laboratoire se retire des magasins du parc, les certificats du chapitre 7 sont détruits, les jonctions Raft pointent une vraie chaîne, et le registre écrit la phrase attendue depuis onze chapitres : la dette TLS est soldée, Vault est servi par sa propre PKI.

28.6 VRRP : l'entrée sans point unique¶

Reste l'objection que le lecteur a formulée seul : le répartiteur est un, et le dessin vient de déplacer le point de défaillance unique, pas de le supprimer.

La réponse technique se nomme VRRP : deux répartiteurs, une adresse virtuelle portée par le maître et annoncée en continu ; s'il se tait, le second la reprend en une à trois secondes. La configuration surveille à la fois la présence du pair et la santé du service local, car un répartiteur vivant dont le service est mort doit céder l'adresse.

Astrea connaît cette réponse et diffère son déploiement. La décision, prise en grille au chapitre 29, s'écrit en trois lignes. La panne du répartiteur est un incident court et réparable, la machine se reconstruisant en minutes et les clients pouvant temporairement pointer un nœud. Sa probabilité est faible devant celle d'une panne de nœud, déjà couverte. Et le coût, une machine et une technologie de plus avec ses scénarios à exercer, se paie mieux plus tard.

Le risque résiduel sera signé, daté, muni de son critère de révision. Le cas 4 de la partie XIV montre une organisation qui, elle, a dû retenir VRRP dès la conception : l'engagement de disponibilité y rendait la reconstruction d'un répartiteur trop coûteuse. C'est une étude d'architecture, pas un runbook ; le mode opératoire du déploiement reste à écrire le jour où le critère tombera.

Exemple : la bascule TLS des trois nœuds¶

La séquence consignée, un seul changement à la fois : la bascule TLS d'abord, l'aiguillage DNS le lendemain.

Les deux standbys. Émission, dépôt, rechargement. Aucune interruption, aucun descellement. La vérification côté client montre la chaîne Astrea et le bon sujet.

L'actif. La seule question de la matinée : faut-il lui faire céder la main d'abord ? Non, le rechargement ne coupe pas les sessions en cours et ne touche pas au processus. Décision consignée, rechargement à chaud, quatre secondes de vérification, rien au tableau de bord applicatif.

L'automatisation. Les minuteurs de renouvellement déployés sur les trois nœuds, l'alerte à trois jours branchée sur la supervision.

La clôture. L'autorité de laboratoire retirée des magasins par la gestion de configuration, les vieux certificats détruits, lignes de registre. Test de bout en bout depuis l'hôte applicatif : login, lecture, émission de certificat, trois succès et chaîne vérifiée.

La dernière ligne prépare le chapitre suivant : reste à donner l'adresse au répartiteur, et la durée prévue de l'opération est celle du délai de propagation DNS.

Architecture : l'entrée à l'étape 5¶

        consommateurs (10.10.30.0/24, demain 10.10.40.0/24)
                 |  TLS de bout en bout (le repartiteur ne dechiffre RIEN)
                 v
        lb-vault-01  10.10.20.10:8200  (= vault.astrea.lab)
        HAProxy mode tcp -- sonde: GET /v1/sys/health, attend 200, verifie la CA
                 |
        route vers l'ACTIF uniquement
                 v
   vault-core-01 (.11) --- vault-core-02 (.12) --- vault-core-03 (.13)
        200                     429                     429
   certificats pki-int (SAN: vault.astrea.lab + nom du noeud + IP), reload SIGHUP
        \__________________ 8201 : raft, entre noeuds seulement _________________/

   evolution differee (risque residuel signe, ch.29) : lb-vault-02 + VRRP -- cf. cas 4, partie XIV

Sécurité : l'entrée dans le modèle¶

Le répartiteur aveugle trahit la disponibilité, jamais la confidentialité. Compromis, il peut couper, ralentir ou aiguiller vers un imposteur, que les clients démasquent parce qu'ils vérifient le certificat de bout en bout. La vérification côté client est le contrôle qui rend le passage en aveugle sûr.

La sonde vérifie, ou elle est un vecteur. Sans vérification d'autorité, un attaquant en position réseau ferait router le trafic vers son faux nœud. Les clients le rejetteraient, certes, mais le déni de service serait acquis.

Les métadonnées restent des données. Même aveugle, l'entrée voit qui parle, quand et combien. Ses journaux servent la corrélation du chapitre 30 et se protègent en conséquence.

Le renouvellement automatisé se surveille lui-même. Un minuteur qui échoue en silence recrée l'incident du certificat expiré avec un faux sentiment de sécurité. L'alerte à trois jours est le contrôle du contrôle.

Erreurs fréquentes¶

Terminer TLS à l'entrée pour l'observabilité. Le répartiteur devient un enregistreur universel de secrets hors de toute barrière (section 28.2).

Sonder / au lieu de sys/health, ou accepter 429 comme succès de routage. La première ne mesure rien, la seconde envoie du trafic aux standbys en régime nominal (section 28.3).

Sonder sans vérifier le certificat. Le répartiteur accepterait n'importe quel répondeur TLS comme nœud sain (section 28.4).

Redémarrer au lieu de recharger. Descellement, bascule et interruption, pour rien. Le rechargement applique les certificats à chaud (section 28.5).

Oublier le nom de service dans les SAN. À travers le répartiteur, les clients vérifient le nom de service et refusent un certificat qui ne le porte pas (section 28.5).

Déployer le renouvellement sans son alerte. Le minuteur meurt en silence, et l'incident arrive à l'échéance (section 28.5).

Traiter la panne du répartiteur comme impensable. Elle est pensée, chiffrée, signée, ou elle sera improvisée (section 28.6).

Mise en pratique : l'entrée sous contrainte¶

Sur papier ; réponses commentées en fin de partie.

Écrivez la configuration d'un cluster Enterprise de cinq nœuds dont deux performance standbys, avec deux frontends : l'un routant les écritures vers l'actif, l'autre répartissant les lectures sur l'actif et les performance standbys.
Rédigez le runbook de renouvellement du certificat d'un nœud tel que le minuteur l'exécute : étapes, vérifications, comportements d'échec, alerte.
Comparez ce qu'obtient un attaquant qui compromet le répartiteur selon la posture TLS, en trois colonnes : confidentialité, intégrité, disponibilité.

Questions de compréhension¶

Donnez les trois raisons de l'entrée unique, et ce que la PKI avait déjà décidé à ce sujet.
Décrivez les trois postures TLS et ce que voit le répartiteur dans chacune.
Énoncez la règle sur la frontière de confidentialité, et son prix pour un composant qui voit le clair.
Comment le répartiteur suit-il une bascule, et de quoi dépend sa vitesse de convergence ?
Pourquoi la sonde doit-elle vérifier le certificat des nœuds ?
Justifiez les trois SAN du certificat d'un nœud, et l'exception de durée avec sa fin programmée.
Que permet le rechargement par signal, et qu'évite-t-il lors d'un renouvellement ?
Que peut trahir un répartiteur aveugle compromis, et quel contrôle côté client rend cette posture sûre ?
Résumez la décision sur VRRP : la technique, l'arbitrage qui la diffère, et ce qui reste à produire le jour où elle sera retenue.

Synthèse¶

L'entrée unique réalise la prophétie du chapitre 7 : une adresse stable pour les clients, pour les URL de la PKI, pour l'exploitation. Sa posture TLS est la décision maîtresse, et Astrea passe en aveugle, la session chiffrée allant du client au nœud, la frontière de confidentialité s'arrêtant où elle doit. La sonde de routage fait le reste, vérification du certificat comprise, avec une convergence au rythme de la sonde. La PKI prend la maison : SAN triples, exception de durée bornée, rechargement sans interruption, renouvellement minuté et alerté, et la dette du chapitre 17 soldée. Le point unique restant est vu, chiffré et différé.