History

Daniel Allaire f05f505b88 Reconstruction propre : orchestrateur ordonné, registre des flux + pare-feu Rend l'écosystème reconstructible en une commande (create+deploy idempotent) et ajoute la couche « accès » (nftables least-privilege) au zéro-confiance. Orchestrateur (phase 2) : - docs/couches-deploiement.yml : registre des couches (socle → pki → services → apps → agents) - scripts/orchestrer.py : tri par couche + topo intra-couche (graphe) → playbooks/site.yml ordonné - Makefile : site / deployer-tout / flotte-creer / reconstruire / myDay (+ gardes CONFIRMER) - docs/dependances-groupes.yml : graphe complété (keycloak→openldap, dovecot, postfix, icingaweb2, nextcloud) Audit codé-en-dur (phase 1b) : labels/slug OIDC dérivés de l'intrant `organisation` (serveur_forgejo/grafana/nextcloud) — le moteur ne porte plus de nom de tenant. Registre des flux réseau (phase 0) : - meta/flux.yml pour tous les rôles (29 rôles, 63 flux ; schéma + matrice validés) - scripts/resoudre_flux.py : matrice d'audit (docs/registre-flux.md) + rulesets nftables résolus par hôte - roles/nftables_baseline : déploie le ruleset résolu (moindre-privilège) quand activé, sinon repli Correctifs : détection du coffre Vault (chemin production → inventaire réellement résolu). Outillage : make wiki-publier (publication du wiki pédagogique dans Forgejo). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>		2026-07-07 03:08:09 -04:00
..
defaults	client_pki : recharger le vrai consommateur au renouvellement de cert	2026-07-04 17:18:13 -04:00
handlers	client_pki : ré-émettre le cert sur dérive de SAN (fin du rm manuel)	2026-07-05 18:43:23 -04:00
meta	Reconstruction propre : orchestrateur ordonné, registre des flux + pare-feu	2026-07-07 03:08:09 -04:00
tasks	client_pki : ré-émettre le cert sur dérive de SAN (fin du rm manuel)	2026-07-05 18:43:23 -04:00
templates	client_pki : recharger le vrai consommateur au renouvellement de cert	2026-07-04 17:18:13 -04:00
README.md	Set-OPS — moteur d'ecosystemes numeriques souverains (Alliance Boreale)	2026-06-24 20:17:46 -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_ca_fingerprint: "{{ vault_step_ca_fingerprint }}"             # empreinte racine de l'AC
client_pki_provisioner_password: "{{ vault_step_ca_provisioner_password }}"  # partage avec serveur_step_ca

L'empreinte racine s'obtient sur l'AC (step certificate fingerprint <root_ca.crt>).

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).