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

83 lines
4.2 KiB
YAML
Raw Normal View History

---
client_pki_paquets:
- step-cli
client_pki_steppath: "/etc/step"
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
# L'AC INTERNE SE DÉRIVE DU GROUPE QUI LA PORTE, elle ne se nomme pas (2026-08-25).
#
# Cette URL écrivait `infra-pki-01` EN DUR. Chez un tenant ça marchait toujours : la
# nomenclature nomme sa PKI ainsi, donc le littéral et la réalité coïncidaient. Le SITE
# est le premier à l'appeler autrement — `site-pki-01` — et les cinq machines ont essayé
# de s'enrôler auprès d'un hôte qui n'existe nulle part :
#
# lookup infra-pki-01.genese.internal ... no such host
#
# Le message accusait le DNS, alors que c'était le nom qui était faux. Un littéral qui a
# raison par coïncidence est un bogue qui attend son premier cas particulier.
#
# `groups['serveur_step_ca']` dit qui porte l'autorité, dans un tenant comme sur un site.
# Pas de repli : sans autorité déclarée, s'adresser à un nom inventé produirait exactement
# la panne qu'on vient de corriger. Le rôle refuse (voir tasks/main.yml).
client_pki_ca_hote: "{{ (groups['serveur_step_ca'] | default([])) | first | default('', true) }}"
client_pki_ca_url: "https://{{ client_pki_ca_hote }}.{{ domaine_interne }}:8443"
client_pki_provisioner: "admin@{{ domaine_interne }}"
# Identite de l'hote.
client_pki_nom_cert: "{{ ansible_fqdn | default(ansible_hostname) }}"
client_pki_cert: "{{ client_pki_steppath }}/certs/{{ client_pki_nom_cert }}.crt"
client_pki_cle: "{{ client_pki_steppath }}/certs/{{ client_pki_nom_cert }}.key"
# SANs du certificat (FQDN + nom court + IP). Requis pour un mTLS moderne :
# les clients TLS valident par le SAN, pas par le CN.
client_pki_sans:
- "{{ client_pki_nom_cert }}"
- "{{ ansible_hostname | default('') }}"
- "{{ ansible_host | default('') }}"
# L'empreinte du root CA n'est PAS un intrant : elle est DERIVEE a chaud depuis l'AC
# (tasks/main.yml), parce qu'un from-zero regenere l'autorite avec une empreinte neuve.
# La stocker en voute donnerait une valeur perimee des la premiere reconstruction.
# Pour epingler explicitement une empreinte : `client_pki_ca_fingerprint_override`.
client_pki_ca_fingerprint: ""
# Secret OBLIGATOIRE (Ansible Vault).
client_pki_provisioner_password: "{{ vault_step_ca_provisioner_password | default('') }}" # rempli depuis la voute (vault_step_ca_provisioner_password)
# Depot apt officiel Smallstep (partage avec serveur_step_ca).
client_pki_depot_cle_url: "https://packages.smallstep.com/keys/apt/repo-signing-key.gpg"
client_pki_depot_cle_fichier: "/etc/apt/keyrings/smallstep.asc"
client_pki_depot_uri: "https://packages.smallstep.com/stable/debian"
client_pki_depot_suite: "debs"
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
# QUI PEUT LIRE LA CLE PRIVEE (2026-08-25).
#
# Elle est en `0600 root:root`, et c'est le bon defaut. Les consommateurs TLS habituels —
# nginx, Postfix, Dovecot — demarrent en root, lisent la cle, puis deprivilegient : ils
# n'ont jamais eu besoin d'autre chose.
#
# Forgejo tourne en `git` DES LE DEPART. Sur la forge du site, qui sert le genome sans
# edge devant elle, la cle etait donc illisible par le seul processus qui en a besoin.
#
# Un GROUPE lecteur et `0640` reglent ca sans ouvrir la cle a tout le monde. On declare le
# groupe explicitement, service par service : elargir par defaut serait exactement le
# genre de commodite qui finit par rendre une cle privee lisible par `nogroup`.
client_pki_cle_groupe: "root"
client_pki_cle_mode: "0600"
# LE CERTIFICAT, LUI, EST PUBLIC — et l'etait deja avant d'etre sur ce disque : il est
# presente a chaque poignee de main, a quiconque se connecte. Le garder en `0600` ne
# protegeait rien et empechait tout service non-root de le lire. Le certificat racine est
# d'ailleurs deja en `0644` juste a cote, pour la meme raison.
client_pki_cert_mode: "0644"
# Services a recharger apres un renouvellement de cert : les VRAIS consommateurs
# (nginx sur l'edge, postfix/dovecot sur le mail, slapd sur l'annuaire). Sans ca,
# le cert est renouvele sur disque mais le service sert l'ancien jusqu'a un reload.
client_pki_reload_services: []
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
# Marge avant echeance (secondes) sous laquelle le role RE-EMET le certificat plutot que
# d'attendre le renouvellement automatique. 3600 = une heure : large devant le minuteur
# (~14 min), serre devant la duree de vie (24 h).
client_pki_marge_renouvellement: 3600