History

Daniel Allaire 5812e0c6ca depot de binaires : le site tient ce que les runners allaient chercher Le cache du site couvrait apt ; quatre artefacts arrivaient autrement, parce qu ils ne vivent dans aucun depot apt. Le controleur les tire puis les pousse par SSH. Mesure du 2026-09-12 : le cache du runner du site est ABSENT. Un second locataire monte depuis lui sortait chercher 570 Mo sur codeberg.org, github.com et download.nextcloud.com, alors que le meme ecosysteme ne demandait plus un seul paquet a Debian. Le poste du mainteneur les a depuis toujours : personne ne l avait vu. Pas de relais transparent, et la mesure tranche : github.com redirige vers une URL signee valable une heure, differente a chaque requete. Un cache qui la prend pour cle ne fait jamais mouche. Le relais marcherait pour deux amonts sur quatre. Donc un vrai depot, dans le service qui existe deja. LocalDirs d apt-cacher-ng publie un repertoire du disque sous un prefixe, eprouve AVANT d ecrire le role. Aucun service, aucun port, aucun certificat, aucun flux nouveaux : l ingress 3142 pair flotte couvre exactement ce chemin. Les versions ne sont pas recopiees : le role lit les defauts des quatre consommateurs. Les quatre roles recoivent une tache AJOUTEE, placee avant leur stat de cache — si le depot sert, le stat le voit et la tache amont se saute d elle-meme. Aucune tache existante n a change. P70 exige que tout dest ecrit sous un cache_local figure au depot. Une liste qui suit une autre prend du retard ; celle-ci est nee avec sa garde. Deux marches payees en chemin : - failed_when: false REECRIT le verdict, donc la premiere garde de signature ne gardait rien. Elles mesurent le fichier desormais. - file: state=directory cree les parents en 0750 : apt-cacher-ng, qui ne tourne pas en root, rendait 403 sur chaque fichier. Un chemin se traverse en entier. Verifie sur l infrastructure : 6/6 artefacts servis (200/206) depuis le runner du site ET depuis une machine du locataire a travers la frontiere ; les 6 empreintes SHA-256 sont identiques a celles qui ont construit Chezlepro ; second passage changed=0. make prouver : 69 OK, 0 echec, 1 saute. ansible-lint : 0 failure, profil production. Inclut aussi force: true sur cinq telechargements de cles : une reprise conditionnelle ne reprend rien (304 Not Modified, size 0, attempts 5). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q		2026-09-12 23:45:00 -04:00
..
defaults	les depots tiers passent par le cache, et le tenant n a plus le sien	2026-09-10 14:53:48 -04:00
handlers	deploiement : deux attentes de premier demarrage, et trois defauts leves	2026-08-07 09:30:48 -04:00
meta	supervision : la sonde se declare dans le role, comme le flux	2026-09-09 21:45:49 -04:00
tasks	depot de binaires : le site tient ce que les runners allaient chercher	2026-09-12 23:45:00 -04:00
templates	supervision : la sonde se declare dans le role, comme le flux	2026-09-09 21:45:49 -04:00
README.md	client_pki : l'empreinte du root CA n'est pas un secret de voûte	2026-08-01 22:37:27 -04:00

README.md

client_pki

Intégration cliente PKI / identité machine : chaque hôte fait confiance à l'AC interne (serveur_step_ca), obtient son propre certificat et le renouvelle automatiquement.

Rôle

Installe step-cli (dépôt apt Smallstep).
Confiance : step ca bootstrap --install → installe la racine de l'AC dans le magasin de confiance système (l'hôte fait confiance au TLS interne réel).
Certificat d'hôte : step ca certificate <fqdn> via le provisioner.
Renouvellement automatique : unités systemd officielles cert-renewer@.{service,timer} (vérifie/renouvelle toutes les 15 min, recharge le service consommateur s'il existe).

« Chaque hôte authentifiable »

Après ce rôle, l'hôte possède une identité machine vérifiable : un certificat émis par l'AC interne, renouvelé sans intervention. Les services peuvent l'utiliser pour du TLS / mTLS interne.

Secrets requis (Vault)

client_pki_provisioner_password: "{{ vault_step_ca_provisioner_password }}"  # partage avec serveur_step_ca

Un seul — et l'empreinte racine n'en fait pas partie.

L'empreinte du root CA n'est pas un intrant

Elle est dérivée à chaud depuis l'autorité (step certificate fingerprint exécuté sur serveur_step_ca, en delegate_to), et non lue depuis la voûte. La raison : un from-zero régénère l'AC, donc son empreinte change. Une empreinte figée en voûte serait périmée dès la première reconstruction — et une empreinte périmée fait échouer le bootstrap de chaque hôte, sans que rien n'indique pourquoi.

Si l'AC est injoignable ou pas encore déployée, un assert échoue avec un message clair plutôt que de laisser passer une empreinte vide — ce qui reviendrait à faire confiance à n'importe quelle autorité au premier contact.

Pour épingler explicitement une empreinte (AC externe, migration) : client_pki_ca_fingerprint_override.

Variables principales

Variable	Défaut	Rôle
`client_pki_ca_url`	`https://infra-pki-01.exemple.internal:8443`	URL de l'AC
`client_pki_provisioner`	`admin@exemple.internal`	Provisioner émetteur
`client_pki_nom_cert`	FQDN de l'hôte	Nom du certificat

Notes / sécurité

Émission via le provisioner JWK (mot de passe partagé) : tout hôte avec ce secret peut émettre des certificats. Acceptable en interne ; pour durcir, basculer vers ACME ou des jetons à usage unique par hôte (phase ultérieure).
Pour qu'un service (nginx, keycloak…) recharge automatiquement après renouvellement, nommer son certificat d'après le service (instance cert-renewer@<service>).

Prérequis

Dépendance client_pki requiert serveur_step_ca actif (déjà dans docs/dependances-groupes.yml).
Réseau vers l'AC (:8443).