Daniel Allaire
15cdb7d454
Some checks are pending
verifier / verifier (push) Waiting to run
Quatre machines, zero echec, la forge repond (service actif, ecoute 3000, HTTP 200). forge-01 121 taches, infra-pki-01 109, infra-edge-01 92, infra-dns-01 84. 1. UN TIERS INTERMITTENT ARRETAIT TOUT. `packages.smallstep.com` repond une fois sur deux ; `get_url` abandonne a 10 s sans reprise. Mesure AVANT d'accuser le reseau : DNS resolvait, la poignee TLS aboutissait, 138 Ko depuis deb.debian.org passaient en 0,09 s, et le chemin acceptait 1450 octets en refusant 1500 — l'attendu exact en overlay. Le reseau n'y etait pour rien. Reprises posees sur les trois telechargements du chemin critique (serveur_step_ca, client_pki, serveur_forgejo). Une dizaine d'autres restent sans reprise : liste dans le CHANGELOG. 2. UN `register` A ECRASE UN CHEMIN DE FICHIER. En posant la reprise, j'ai enregistre dans `client_pki_cle`, nom que le role utilisait deja pour la cle privee. L'ecart s'est vu 70 taches plus loin : `step ca certificate` recevait un dict serialise a la place du fichier et refusait « too many positional arguments ». Un register ecrit dans l'espace de noms de TOUT le role. 3. LE SSO SE DECLARAIT AU LIEU DE SE DERIVER. `serveur_forgejo_oidc_actif: true` en dur faisait cabler une source OAuth2 vers un Keycloak inexistant. Derive desormais de l'inventaire. Quatrieme manifestation en deux jours de la meme hypothese — le moteur supposait l'ecosysteme COMPLET — apres les intrants (P32), les bases (P35) et les dependances causales. AUCUN de ces defauts n'etait visible sur Chezlepro, qui porte tout et tournait deja. Ils ne pouvaient apparaitre qu'au premier ecosysteme DIFFERENT. make verifier 41 OK, 0 echec, 0 saute ; make test inchange. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| defaults | ||
| handlers | ||
| meta | ||
| tasks | ||
| templates | ||
| 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à dansdocs/dependances-groupes.yml). - Réseau vers l'AC (
:8443).