Set-OPS-Public/roles/client_pki
Daniel Allaire 41413c7f04 deploiement : deux attentes de premier demarrage, et trois defauts leves
`idm-01` a prouve le routage inter-zone dans le VRF (10.27.19.21 -> 10.27.17.11,
deux passerelles anycast) et leve trois defauts qu'aucun devis ne pouvait
montrer :

1. Le handler de `client_pki` rechargeait `slapd` avant son installation —
   consequence directe de l'ordre retabli. Un consommateur absent n'est pas une
   erreur ; un vrai echec de rechargement reste fatal.

2. `resoudre_base` ne trouvait aucune base de portee `application` : Keycloak
   declare `consommateur: keycloak`, le role cherchait `serveur_keycloak`. Le
   lien est declare dans applications.yml — on le suit au lieu de retirer un
   prefixe a la main.

3. Keycloak attend PostgreSQL, pas encore deploye. Pas un defaut : `deployer`
   ne connait que l'ordre intra-hote, l'ordre inter-hotes est celui de `site`.

Et deux attentes, sans lesquelles on ne peut pas enchainer creation et
deploiement — donc sans lesquelles `myDay` ne reconstruit pas seul : SSH, puis
cloud-init et les maj automatiques. `creer-vm` rend desormais une VM PRETE.
`lock_timeout: 300` sur chaque tache apt complete l'attente : le verrou peut
etre repris ENTRE deux taches, ce qu'une verification en amont ne previent pas.

Defaut dans l'attente elle-meme : `unattended-upgrades` est un demon, toujours
actif — l'inclure rendait la condition impossible a satisfaire.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 09:30:48 -04:00
..
defaults client_pki : l'empreinte du root CA n'est pas un secret de voûte 2026-08-01 22:37:27 -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 deployer : l'ordre des couches, et l'autorite qui se signe elle-meme 2026-08-06 23:57:01 -04:00
templates client_pki : recharger le vrai consommateur au renouvellement de cert 2026-07-04 17:18:13 -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

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