Daniel Allaire
467b05cbc0
Le site portait trois services sur les sept du modele `origine`. Sa forge servait LE
GENOME EN CLAIR et aucune de ses machines n'avait de certificat — donc aucun chiffrement
est-ouest, ce que la doctrine zero-confiance interdit. site-pki-01 (step-ca) et
site-dns-01 (PowerDNS + resolveur colocalises) rejoignent les trois autres.
Quatre defauts que le site a fait tomber, chacun invisible chez un tenant :
- DNS bloque par notre propre default-deny. Un tenant a son resolveur DANS son reseau
et ne traverse jamais la frontiere ; le site interroge la sienne. La regle est derivee
de `site.dns_amorcage`, destination declaree, jamais `any`.
- serveur_cache_site n'installe rien : il marque un cache et lit les variables de
serveur_artefacts. Les defauts d'un role ne sont en portee que dans le play qui
l'inclut — une dependance de role regle l'ordre ET la portee.
- resoudre_idp partait meme avec OIDC desactive, et exigeait un plan. La resolution
suit desormais l'usage.
- le plancher /etc/hosts etait VIDE : `hotes_actifs` n'existait pas dans l'inventaire
du site. Un role qui reussit en n'ecrivant rien est la pire forme d'echec.
Une machine du site peut desormais se configurer (`variables:`), appliquee en dernier :
ce qu'une machine declare d'elle-meme prime sur ce que le site declare pour toutes.
Verifie et non suppose : systemd disait `active` mais rien n'ecoutait sur 443 — step-ca
sert sur 8443. La zone souveraine resout et la recursion marche, mesurees sur la machine.
42 preuves vertes, ansible-lint profil production.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| defaults | ||
| meta | ||
| tasks | ||
| README.md | ||
serveur_cache_site
Le cache d'artefacts du SITE : celui que les écosystèmes voisins prennent comme amont, pour que Debian ne soit téléchargé qu'une fois pour toute la fabric.
Le chaînage
VM du tenant → cache du tenant → cache du SITE → Debian
Chaque écosystème garde le sien — il reste maître de ses paquets et s'en émancipe d'un drapeau — mais il ne va plus chercher chez Debian.
Un cache unique où toutes les VM taperaient aurait demandé un flux de chaque machine de chaque tenant vers un hôte d'un autre tenant : N×M chemins à travers le default-deny. Avec le chaînage il n'y en a qu'un par écosystème, entre deux caches.
Et l'étanchéité y gagne : le cache du site ne voit que des requêtes agrégées, jamais quelle machine installe quoi.
Pourquoi deux rôles plutôt qu'un drapeau
Les flux se déclarent dans meta/flux.yml, qui est statique. Un rôle unique aurait dû
déclarer l'ingress inter-tenant pour tous les caches — et le devis l'a montré :
+ TENANT_PATI29 -> CHEZ17_SERVEUR_ARTEFACTS un maillage complet,
+ TENANT_TECH23 -> CHEZ17_SERVEUR_ARTEFACTS chaque cache acceptant chaque autre
Avec la séparation, l'ingress n'existe qu'ici, et un seul cache est joignable.
Qui peut le déclarer
L'écosystème de l'hébergeur, celui qui exploite la fabric. Un tenant ordinaire qui le déclarerait s'offrirait à servir ses voisins sans y être invité.
C'est le même patron que serveur_ops_site : le runner de site prépare le terrain —
VNets, routes, flux — pour que les plans des tenants tiennent. Aucun écosystème n'ouvre de
porte chez un autre ; c'est le site qui autorise.
Ce qu'il vérifie
Qu'il ne se chaîne pas lui-même. Il est le bout de la chaîne : le laisser pointer sur un amont ferait tourner les paquets en rond entre deux caches, ou les ferait sortir du site sans que personne ne l'ait décidé.
Que le cache écoute vraiment. Le rôle n'installe rien : sa seule prise sur le réel est de vérifier que le service qu'il désigne existe. Sans ça, il attribuerait une responsabilité à un port que personne n'écoute.
Ce que ce rôle ne fait pas
Il n'installe ni ne configure apt-cacher-ng — c'est serveur_artefacts. Il attribue une
responsabilité et la rend lisible dans le plan.