Set-OPS-Public/roles/client_pki/tasks/main.yml

278 lines
12 KiB
YAML
Raw Normal View History

---
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
# SANS AUTORITÉ DÉCLARÉE, ON NE DEVINE PAS SON NOM.
#
# L'URL de l'AC se dérivait d'un littéral (`infra-pki-01`), vrai chez tout tenant par
# coïncidence de nomenclature. Le premier écosystème à nommer sa PKI autrement a vu ses
# cinq machines s'enrôler auprès d'un hôte inexistant, et le message accusait le DNS.
#
# Elle se dérive maintenant de `groups['serveur_step_ca']`. Si ce groupe est vide, il n'y
# a pas d'autorité du tout : le dire ici vaut mieux que de laisser `step ca bootstrap`
# échouer sur un nom tronqué, trois tâches plus loin, en parlant de résolution.
- name: Une autorité de certification est-elle déclarée ?
ansible.builtin.assert:
that:
- client_pki_ca_hote | length > 0
fail_msg: >-
Aucun hôte ne porte `serveur_step_ca` dans cet inventaire : il n'y a pas d'autorité
interne à qui demander un certificat. Déclarer une PKI, ou exempter cet écosystème
de `client_pki` — mais avec une raison, jamais en silence.
# L'empreinte du root CA est la SOURCE DE VÉRITÉ de l'autorité elle-même : on la
# dérive à chaud (robuste au from-zero — une AC régénérée a une empreinte neuve).
# `client_pki_ca_fingerprint_override` permet d'épingler explicitement si besoin.
- name: Dériver l'empreinte du root CA depuis l'autorité
ansible.builtin.command:
cmd: "step certificate fingerprint {{ serveur_step_ca_steppath | default('/etc/step-ca') }}/certs/root_ca.crt"
delegate_to: "{{ groups['serveur_step_ca'][0] }}"
changed_when: false
check_mode: false
register: client_pki_fingerprint_ac
- name: Retenir l'empreinte (dérivée de l'AC, sauf override explicite)
ansible.builtin.set_fact:
client_pki_ca_fingerprint: "{{ client_pki_ca_fingerprint_override | default(client_pki_fingerprint_ac.stdout | trim, true) }}"
- name: Exiger l'empreinte AC et le mot de passe provisioner (Vault)
ansible.builtin.assert:
that:
- client_pki_ca_fingerprint | length > 0
- client_pki_provisioner_password | length > 0
fail_msg: >-
Empreinte du root CA indisponible (step-ca joignable et déployé ?) ;
client_pki_provisioner_password requis (via Ansible Vault).
- name: Assurer le repertoire des trousseaux apt
ansible.builtin.file:
path: /etc/apt/keyrings
state: directory
owner: root
group: root
mode: "0755"
# Recuperee UNE FOIS. Sans garde, chaque deploiement recontactait le serveur du
# fournisseur : cinq cles x quatorze hotes = soixante-dix allers-retours externes pour
# des cles deja installees, et autant d'occasions qu'un tiers lent fasse tomber le
# deploiement. Arbitrage rendu le 2026-08-09 : une plateforme souveraine ne depend pas
# de six serveurs etrangers pour redeployer ce qu'elle possede deja.
#
# CONSEQUENCE ASSUMEE : une rotation de cle amont n'est plus recuperee toute seule. Elle
# ne passe pas inapercue pour autant — `apt` refuse alors le depot, bruyamment. Pour
# forcer le rafraichissement : supprimer le fichier et rejouer le role.
- name: Cette ressource est-elle deja recuperee ? (Telecharger la cle de signature Sm)
ansible.builtin.stat:
path: "{{ client_pki_depot_cle_fichier }}"
register: telecharger_la_cle_de_signature_smallste_present
patient 0 debout — et quatre defauts que seul un ecosysteme DIFFERENT pouvait montrer 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>
2026-08-23 02:53:44 -04:00
# Un serveur tiers intermittent ne doit pas arreter un deploiement de quarante
# minutes (mesure du 2026-08-23 : la meme URL pend, puis rend 200 en 0,48 s au
# second essai). Defaut de `get_url` : 10 s et aucune reprise.
- name: Telecharger la cle de signature Smallstep
when: not telecharger_la_cle_de_signature_smallste_present.stat.exists
ansible.builtin.get_url:
url: "{{ client_pki_depot_cle_url }}"
dest: "{{ client_pki_depot_cle_fichier }}"
owner: root
group: root
mode: "0644"
patient 0 debout — et quatre defauts que seul un ecosysteme DIFFERENT pouvait montrer 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>
2026-08-23 02:53:44 -04:00
timeout: 30
register: client_pki_cle_depot_telechargee
retries: 5
delay: 6
until: client_pki_cle_depot_telechargee is succeeded
- name: Ajouter le depot apt Smallstep
ansible.builtin.template:
src: smallstep.sources.j2
dest: /etc/apt/sources.list.d/smallstep.sources
owner: root
group: root
mode: "0644"
paquets tiers : passer par le cache du controleur, plus par Internet Trois depots tiers etaient en HTTPS, et client_artefacts pose Acquire::https::Proxy DIRECT — sans quoi le cache du site refuse les tunnels et aucun depot tiers n est joignable. La ligne est juste ; sa consequence ne l avait pas ete vue : ces trois depots CONTOURNENT le cache, et chaque VM neuve allait les chercher sur Internet a sa naissance. step-cli et alloy sont poses par des integrations UNIVERSELLES. Sans lien, une machine neuve n obtenait ni son client d autorite ni ses metriques — elle n entrait dans aucun flux chiffre. Dernier obstacle a une reconstruction hors ligne, et il tenait dans un mot. make cacher-paquets tire les 21 deb aux versions epinglees, empreinte SHA256 verifiee depuis l index du depot. Le role partage paquets_tiers les depose et les installe EN UN SEUL appel a apt — il sait resoudre un ensemble de fichiers locaux qui se dependent, la ou paquet par paquet echouerait sur l ordre (Icinga en apporte dix-sept). Six roles branches ; chacun retombe sur le depot distant pour ce que le cache n a PAS fourni, et rien d autre. Eprouve pour de vrai : packages.smallstep.com renvoye vers 127.0.0.1, step-cli desinstalle, cache local efface. Le role rejoue installe 0.30.6-1 depuis le cache et la machine obtient ses certificats. Zero echec. Deux defauts de mon propre outil, trouves en le construisant : Smallstep sert son index NON COMPRESSE (404 sur .gz) donc step-cli n etait jamais mis en cache ; et un depot injoignable faisait continue AVANT d incrementer le total, si bien que le script rapportait 20 sur 20 alors qu il en manquait un. Une garde qui ne peut pas echouer ne garde rien — troisieme fois cette semaine. Corrige puis eprouve en le faisant echouer. Reste hors ligne : NTP externe, et l expedition des alertes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on
2026-09-05 08:22:14 -04:00
# LE CACHE DU CONTROLEUR D'ABORD, LE DEPOT DISTANT ENSUITE (2026-09-03).
#
# `client_pki` est une integration UNIVERSELLE : chaque machine de chaque ecosysteme
# installe `step-cli` ici, a sa naissance. Le depot Smallstep est en HTTPS, et
# `client_artefacts` pose `Acquire::https::Proxy "DIRECT"` — il CONTOURNE donc le cache
# du site et sort sur Internet. Sans lien, une VM neuve n'obtenait pas son client
# d'autorite, donc pas de certificat, donc n'entrait dans aucun flux chiffre.
#
# C'etait le dernier obstacle a une reconstruction hors ligne, et il tenait dans un mot :
# `DIRECT`, pose a juste titre pour une autre raison.
- name: Poser step-cli depuis le cache du controleur, s'il y est
ansible.builtin.include_role:
name: paquets_tiers
vars:
paquets_tiers_noms: "{{ client_pki_paquets }}"
# FILET, ET SEULEMENT SI LE CACHE N'A RIEN DONNE.
#
# `update_cache: true` interroge TOUS les depots configures, Smallstep compris. Hors
# ligne, cette tache echouerait donc APRES que le cache ait deja pose le paquet — le
# deploiement tomberait sur un travail deja fait. Le repli ne doit exister que quand il
# y a quelque chose a rattraper.
#
# Cache vide — poste jamais connecte, paquet retire de la declaration — on retombe sur le
# depot distant comme avant. Degrader, jamais deviner.
- name: Installer depuis le depot distant ce que le cache n'a pas fourni
ansible.builtin.apt:
paquets tiers : passer par le cache du controleur, plus par Internet Trois depots tiers etaient en HTTPS, et client_artefacts pose Acquire::https::Proxy DIRECT — sans quoi le cache du site refuse les tunnels et aucun depot tiers n est joignable. La ligne est juste ; sa consequence ne l avait pas ete vue : ces trois depots CONTOURNENT le cache, et chaque VM neuve allait les chercher sur Internet a sa naissance. step-cli et alloy sont poses par des integrations UNIVERSELLES. Sans lien, une machine neuve n obtenait ni son client d autorite ni ses metriques — elle n entrait dans aucun flux chiffre. Dernier obstacle a une reconstruction hors ligne, et il tenait dans un mot. make cacher-paquets tire les 21 deb aux versions epinglees, empreinte SHA256 verifiee depuis l index du depot. Le role partage paquets_tiers les depose et les installe EN UN SEUL appel a apt — il sait resoudre un ensemble de fichiers locaux qui se dependent, la ou paquet par paquet echouerait sur l ordre (Icinga en apporte dix-sept). Six roles branches ; chacun retombe sur le depot distant pour ce que le cache n a PAS fourni, et rien d autre. Eprouve pour de vrai : packages.smallstep.com renvoye vers 127.0.0.1, step-cli desinstalle, cache local efface. Le role rejoue installe 0.30.6-1 depuis le cache et la machine obtient ses certificats. Zero echec. Deux defauts de mon propre outil, trouves en le construisant : Smallstep sert son index NON COMPRESSE (404 sur .gz) donc step-cli n etait jamais mis en cache ; et un depot injoignable faisait continue AVANT d incrementer le total, si bien que le script rapportait 20 sur 20 alors qu il en manquait un. Une garde qui ne peut pas echouer ne garde rien — troisieme fois cette semaine. Corrige puis eprouve en le faisant echouer. Reste hors ligne : NTP externe, et l expedition des alertes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on
2026-09-05 08:22:14 -04:00
name: "{{ client_pki_paquets
| difference((paquets_tiers_disponibles | default({})).keys() | list) }}"
state: present
update_cache: true
paquets tiers : passer par le cache du controleur, plus par Internet Trois depots tiers etaient en HTTPS, et client_artefacts pose Acquire::https::Proxy DIRECT — sans quoi le cache du site refuse les tunnels et aucun depot tiers n est joignable. La ligne est juste ; sa consequence ne l avait pas ete vue : ces trois depots CONTOURNENT le cache, et chaque VM neuve allait les chercher sur Internet a sa naissance. step-cli et alloy sont poses par des integrations UNIVERSELLES. Sans lien, une machine neuve n obtenait ni son client d autorite ni ses metriques — elle n entrait dans aucun flux chiffre. Dernier obstacle a une reconstruction hors ligne, et il tenait dans un mot. make cacher-paquets tire les 21 deb aux versions epinglees, empreinte SHA256 verifiee depuis l index du depot. Le role partage paquets_tiers les depose et les installe EN UN SEUL appel a apt — il sait resoudre un ensemble de fichiers locaux qui se dependent, la ou paquet par paquet echouerait sur l ordre (Icinga en apporte dix-sept). Six roles branches ; chacun retombe sur le depot distant pour ce que le cache n a PAS fourni, et rien d autre. Eprouve pour de vrai : packages.smallstep.com renvoye vers 127.0.0.1, step-cli desinstalle, cache local efface. Le role rejoue installe 0.30.6-1 depuis le cache et la machine obtient ses certificats. Zero echec. Deux defauts de mon propre outil, trouves en le construisant : Smallstep sert son index NON COMPRESSE (404 sur .gz) donc step-cli n etait jamais mis en cache ; et un depot injoignable faisait continue AVANT d incrementer le total, si bien que le script rapportait 20 sur 20 alors qu il en manquait un. Une garde qui ne peut pas echouer ne garde rien — troisieme fois cette semaine. Corrige puis eprouve en le faisant echouer. Reste hors ligne : NTP externe, et l expedition des alertes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on
2026-09-05 08:22:14 -04:00
when: (client_pki_paquets
| difference((paquets_tiers_disponibles | default({})).keys() | list)) | length > 0
- name: Creer le repertoire STEPPATH des certificats
ansible.builtin.file:
path: "{{ client_pki_steppath }}/certs"
state: directory
owner: root
group: root
mode: "0755"
- name: Deployer le mot de passe du provisioner
ansible.builtin.copy:
content: "{{ client_pki_provisioner_password }}"
dest: "{{ client_pki_steppath }}/provisioner.pass"
owner: root
group: root
mode: "0600"
no_log: true
# L'AUTORITE EST UN CAS A PART, mais pas une exception. Elle n'a pas a « s'enroler »
# aupres d'elle-meme : sa racine est deja sur son disque, et un bootstrap la ferait
# aller la chercher par le reseau, chez elle, en verifiant une empreinte qu'elle vient
# de produire. Elle a en revanche besoin de CERTIFICATS comme tout le monde — sans quoi
# ses propres services (node_exporter) restent en clair, et `client_metrique` echoue.
#
# La distinction est donc : pas d'enrolement, mais emission locale. C'est ce qui permet
# de retirer l'exemption de `client_pki` sans contredire « l'AC est la source de la
# confiance » — elle l'est, et c'est precisement pourquoi elle peut se signer elle-meme.
- name: Reconnaitre l'hote qui PORTE l'autorite
ansible.builtin.set_fact:
client_pki_est_autorite: "{{ inventory_hostname in (groups['serveur_step_ca'] | default([])) }}"
- name: Etablir la confiance dans l'AC interne (bootstrap + installation racine)
ansible.builtin.command:
cmd: >-
step ca bootstrap
--ca-url {{ client_pki_ca_url }}
--fingerprint {{ client_pki_ca_fingerprint }}
--install --force
creates: "{{ client_pki_steppath }}/certs/root_ca.crt"
environment:
STEPPATH: "{{ client_pki_steppath }}"
when: not client_pki_est_autorite | bool
- name: Poser la racine depuis le disque local (l'autorite ne s'enrole pas aupres d'elle-meme)
ansible.builtin.copy:
src: "{{ serveur_step_ca_steppath | default('/etc/step-ca') }}/certs/root_ca.crt"
dest: "{{ client_pki_steppath }}/certs/root_ca.crt"
remote_src: true
owner: root
group: root
mode: "0644"
when: client_pki_est_autorite | bool
- name: Rendre le certificat racine lisible par tous (cert public, requis par les clients TLS)
ansible.builtin.file:
path: "{{ client_pki_steppath }}/certs/root_ca.crt"
mode: "0644"
devis des certificats : disque contre memoire, et l'AC etait expiree Deuxieme application du patron devis/applicateur aux services. Trouve a la premiere execution : sur infra-pki-01 — l'autorite elle-meme — le certificat etait expire depuis plus de 8 h et le renouvellement echouait toutes les 14 minutes sur « 'step ca renew' requires the '--ca-url' flag ». Rien ne le signalait. Cause : sur l'hote de l'AC, /etc/step est le STEPPATH du SERVEUR, pas un amorcage client — pas de defaults.json, et l'unite de renouvellement en dependait. La lecon etait deja ecrite dans le commentaire de la tache d'emission (« l'autorite ne bootstrape pas »), jamais reportee sur l'unite. Le role ne pouvait pas non plus se soigner : la re-emission ne regardait que la FORME (cert absent ou SAN manquant), jamais la validite. client_pki verifie desormais l'echeance (client_pki_marge_renouvellement). Ce qu'il a fallu desapprendre : les certificats vivent 24 h et se renouvellent toutes les ~14 min ; « empreinte servie != empreinte disque » est l'etat NORMAL. Comparer les empreintes aurait donne un verificateur qui crie en permanence. Le signal est l'echeance de ce qui est SERVI, plus l'absence de client_pki_reload_services. Le devis a d'abord menti, du defaut meme qu'il traque : include_vars au niveau du play prime sur les group_vars. Et le premier correctif a PARU marcher — set_fact accepte un dictionnaire entier en argument libre sans erreur et n'en fait rien. Il faut reimposer cle par cle. Les deux devis sont corriges et le piege est consigne dans docs/devis-services.md avant d'ecrire le prochain. Verifie dans les deux sens : CONFORME sur 14 hotes ; sur un releve ou l'on rejoue une copie perimee en memoire, 2 ecarts et code de sortie 1. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 07:20:56 -04:00
# La validite, pas seulement la forme. Sans ce controle, un certificat expire mais
# portant les bons SAN ne declenchait AUCUNE re-emission : le role ne savait pas se
# soigner, et sur l'hote de l'autorite — ou le renouvellement automatique etait casse —
# rien ne pouvait plus le rattraper. Constate le 2026-08-08.
- name: Verifier que le certificat d hote est encore valide
ansible.builtin.command:
cmd: "openssl x509 -in {{ client_pki_cert }} -noout -checkend {{ client_pki_marge_renouvellement }}"
register: client_pki_validite
changed_when: false
failed_when: false
- name: Lire les SAN du certificat d'hote existant (detection de derive)
ansible.builtin.command:
cmd: "openssl x509 -in {{ client_pki_cert }} -noout -ext subjectAltName"
register: client_pki_san_actuels
changed_when: false
failed_when: false
# Re-emet si le cert est absent OU si un SAN voulu manque (ex: nouvelle exposition
# ajoutee au plan -> client_pki_sans mis a jour). Plus de garde 'creates' aveugle.
devis des certificats : disque contre memoire, et l'AC etait expiree Deuxieme application du patron devis/applicateur aux services. Trouve a la premiere execution : sur infra-pki-01 — l'autorite elle-meme — le certificat etait expire depuis plus de 8 h et le renouvellement echouait toutes les 14 minutes sur « 'step ca renew' requires the '--ca-url' flag ». Rien ne le signalait. Cause : sur l'hote de l'AC, /etc/step est le STEPPATH du SERVEUR, pas un amorcage client — pas de defaults.json, et l'unite de renouvellement en dependait. La lecon etait deja ecrite dans le commentaire de la tache d'emission (« l'autorite ne bootstrape pas »), jamais reportee sur l'unite. Le role ne pouvait pas non plus se soigner : la re-emission ne regardait que la FORME (cert absent ou SAN manquant), jamais la validite. client_pki verifie desormais l'echeance (client_pki_marge_renouvellement). Ce qu'il a fallu desapprendre : les certificats vivent 24 h et se renouvellent toutes les ~14 min ; « empreinte servie != empreinte disque » est l'etat NORMAL. Comparer les empreintes aurait donne un verificateur qui crie en permanence. Le signal est l'echeance de ce qui est SERVI, plus l'absence de client_pki_reload_services. Le devis a d'abord menti, du defaut meme qu'il traque : include_vars au niveau du play prime sur les group_vars. Et le premier correctif a PARU marcher — set_fact accepte un dictionnaire entier en argument libre sans erreur et n'en fait rien. Il faut reimposer cle par cle. Les deux devis sont corriges et le piege est consigne dans docs/devis-services.md avant d'ecrire le prochain. Verifie dans les deux sens : CONFORME sur 14 hotes ; sur un releve ou l'on rejoue une copie perimee en memoire, 2 ecarts et code de sortie 1. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 07:20:56 -04:00
- name: Obtenir / re-emettre le certificat d'hote (absent, perime ou SAN derives)
ansible.builtin.command:
# `--ca-url` et `--root` EXPLICITES : sur un hote ordinaire ils sont redondants avec
# le `defaults.json` qu'ecrit `step ca bootstrap`, mais l'autorite ne bootstrape pas
# — elle n'aurait donc aucune de ces deux valeurs. Les nommer ici vaut mieux que de
# dependre d'un fichier ecrit par une etape qu'on saute volontairement.
cmd: >-
step ca certificate {{ client_pki_nom_cert }}
{{ client_pki_cert }} {{ client_pki_cle }}
--ca-url {{ client_pki_ca_url }}
--root {{ client_pki_steppath }}/certs/root_ca.crt
--provisioner {{ client_pki_provisioner }}
--provisioner-password-file {{ client_pki_steppath }}/provisioner.pass
{% for s in client_pki_sans | select | unique %}--san {{ s }} {% endfor %}
--force
environment:
STEPPATH: "{{ client_pki_steppath }}"
when: >-
client_pki_san_actuels.rc != 0
devis des certificats : disque contre memoire, et l'AC etait expiree Deuxieme application du patron devis/applicateur aux services. Trouve a la premiere execution : sur infra-pki-01 — l'autorite elle-meme — le certificat etait expire depuis plus de 8 h et le renouvellement echouait toutes les 14 minutes sur « 'step ca renew' requires the '--ca-url' flag ». Rien ne le signalait. Cause : sur l'hote de l'AC, /etc/step est le STEPPATH du SERVEUR, pas un amorcage client — pas de defaults.json, et l'unite de renouvellement en dependait. La lecon etait deja ecrite dans le commentaire de la tache d'emission (« l'autorite ne bootstrape pas »), jamais reportee sur l'unite. Le role ne pouvait pas non plus se soigner : la re-emission ne regardait que la FORME (cert absent ou SAN manquant), jamais la validite. client_pki verifie desormais l'echeance (client_pki_marge_renouvellement). Ce qu'il a fallu desapprendre : les certificats vivent 24 h et se renouvellent toutes les ~14 min ; « empreinte servie != empreinte disque » est l'etat NORMAL. Comparer les empreintes aurait donne un verificateur qui crie en permanence. Le signal est l'echeance de ce qui est SERVI, plus l'absence de client_pki_reload_services. Le devis a d'abord menti, du defaut meme qu'il traque : include_vars au niveau du play prime sur les group_vars. Et le premier correctif a PARU marcher — set_fact accepte un dictionnaire entier en argument libre sans erreur et n'en fait rien. Il faut reimposer cle par cle. Les deux devis sont corriges et le piege est consigne dans docs/devis-services.md avant d'ecrire le prochain. Verifie dans les deux sens : CONFORME sur 14 hotes ; sur un releve ou l'on rejoue une copie perimee en memoire, 2 ecarts et code de sortie 1. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 07:20:56 -04:00
or client_pki_validite.rc != 0
or (client_pki_sans | select | unique | reject('equalto', '')
| reject('in', client_pki_san_actuels.stdout | default(''))
| list | length > 0)
changed_when: true
notify: Recharger les consommateurs du cert
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
# POSÉ À CHAQUE PASSAGE, PAS SEULEMENT À L'ÉMISSION.
#
# `step ca certificate` réécrit la clé avec ses propres droits, et le renouvellement
# automatique aussi. Ne régler les droits qu'au moment où le certificat change les
# perdrait au premier renouvellement — une panne qui surviendrait des semaines plus tard,
# sans rapport visible avec cette tâche.
- name: Donner accès à la clé privée au service qui doit la lire
ansible.builtin.file:
path: "{{ client_pki_cle }}"
owner: root
group: "{{ client_pki_cle_groupe }}"
mode: "{{ client_pki_cle_mode }}"
when: client_pki_cle_groupe != 'root' or client_pki_cle_mode != '0600'
notify: Recharger les consommateurs du cert
# Le certificat est public. `step` l'ecrit en 0600 comme la cle ; on le rend lisible, sans
# quoi un service non-root echoue sur le CERT apres avoir obtenu la CLE — et le message
# parle de permission sur un fichier que rien ne justifie de proteger.
- name: Rendre le certificat d'hôte lisible (il est public par nature)
ansible.builtin.file:
path: "{{ client_pki_cert }}"
owner: root
group: root
mode: "{{ client_pki_cert_mode }}"
notify: Recharger les consommateurs du cert
- name: Deployer l'unite systemd de renouvellement
ansible.builtin.template:
src: cert-renewer@.service.j2
dest: /etc/systemd/system/cert-renewer@.service
owner: root
group: root
mode: "0644"
notify: Recharger systemd
- name: Deployer le minuteur de renouvellement
ansible.builtin.template:
src: cert-renewer@.timer.j2
dest: /etc/systemd/system/cert-renewer@.timer
owner: root
group: root
mode: "0644"
notify: Recharger systemd
- name: Activer le renouvellement automatique du certificat d'hote
ansible.builtin.systemd:
name: "cert-renewer@{{ client_pki_nom_cert }}.timer"
enabled: true
state: started
daemon_reload: true