Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity
Set-OPS-Public/roles/client_pki
History
Daniel Allaire 43666cff6e site : un SITE a bien un plan — et huit defauts que lui seul pouvait reveler 
J'ai repete toute la journee qu'un SITE n'est pas un plan. C'etait faux : j'en
reconstruisais un morceau par morceau dans underlay.yml sans le nommer. Ce qui est vrai,
c'est qu'un site ne DERIVE pas — il declare ses adresses parce qu'il EST le terrain — et
ne passe donc pas par `instancier`. Mais ne pas deriver n'est pas ne pas avoir de plan.

SITE-Chezlepro/plan/{10-intrants,serveurs,applications}.yml ; underlay.yml ne garde que
la fabric. Ce qui est MESURE d'un cote, ce qui est VOULU de l'autre. Les groupes viennent
du registre des applications, les gardes ont suivi le plan (4 controles negatifs).

Huit defauts, tous invisibles chez un tenant parce qu'il a toujours tout :
  - client_pki codait `infra-pki-01` EN DUR — vrai par coincidence de nomenclature ;
  - aucun moyen pour un service non-root de lire la cle (Forgejo tourne en `git`) ;
  - le certificat, PUBLIC par nature, restait en 0600 ;
  - l'unite Forgejo n'avait pas d'ExecReload : un cert renouvele aurait ete servi perime ;
  - le role ne savait pas servir TLS lui-meme (il y avait toujours un edge) ;
  - le cert ne couvrait pas le nom de SERVICE, faute d'`expose:` ;
  - les registres se chargeaient en tout-ou-rien : sans domaines.yml, plancher vide ;
  - le flux declarait 3000 en dur.

Le message accusait presque toujours autre chose : le DNS quand c'etait un nom faux, une
permission de fichier quand c'etait un port privilegie, rien du tout quand le plancher
s'ecrivait vide.

ROOT_URL est gravee dans les URL de clonage : la forge sert desormais sur 443, avec
CAP_NET_BIND_SERVICE, et son URL n'a plus de port.

Verifie depuis le reseau : Verify return code 0, https://forge.genese.internal/ -> 200.

42 preuves vertes, flux coherents (34 roles, 92 flux).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 13:15:34 -04:00
..
defaults site : un SITE a bien un plan — et huit defauts que lui seul pouvait reveler 2026-08-25 13:15:34 -04:00
handlers deploiement : deux attentes de premier demarrage, et trois defauts leves 2026-08-07 09:30:48 -04:00
meta deployer : l'ordre des couches, et l'autorite qui se signe elle-meme 2026-08-06 23:57:01 -04:00
tasks site : un SITE a bien un plan — et huit defauts que lui seul pouvait reveler 2026-08-25 13:15:34 -04:00
templates devis des certificats : disque contre memoire, et l'AC etait expiree 2026-08-08 07:20:56 -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).