Daniel Allaire
6a5a49f924
Some checks are pending
verifier / verifier (push) Waiting to run
`serveur_ops` et `serveur_ops_site` sont deployes sur `site-ops-01` : le moteur, les plans des trois tenants, les collections hors ligne, et la voute de l'underlay deposee CHIFFREE. Le site a son runner. DEUX FORMES DE RUNNER, ET UNE SEULE ETAIT PREVUE. `serveur_ops` exigeait un depot `role: instance` et un `serveur_ops_instance` — la forme d'un runner de TENANT, qui pilote un ecosysteme, monte son plan par le lien `instance`, detient sa voute. Un runner de SITE ne pilote rien : il MATERIALISE le terrain que d'autres occuperont, et son inventaire est dynamique. Son plan declarait donc ses depots de tenants en `role: tenant`, a dessein et avec ses raisons ecrites — et le role le refusait au nom d'une exigence qui ne le concernait pas. Il exige desormais que le runner pilote QUELQUE CHOSE, sans prescrire quoi. Et il posait le lien quand meme : `serveur_ops_instance: ""` donnait `instance -> /opt/setops/`, un repertoire qui n'est l'ecosysteme de personne. Un lien qui existe et ne designe rien est pire qu'un lien absent : tout ce qui le suit croit avoir trouve une instance. LE CERTIFICAT COUVRE LES NOMS DU SERVICE. `client_pki` ne mettait dans ses SAN que le FQDN, le nom court et l'IP. Le clonage du genome a bute dessus : « certificate subject name (site-forge-01.genese.internal) does not match target hostname 'forge.genese.internal' ». Le nom declare `expose:` etait publie partout — plancher, zone DNS — et couvert nulle part. Les expositions que cet hote SERT REELLEMENT entrent maintenant dans le certificat. Un certificat qui revendiquerait le nom d'un service rendu ailleurs serait une usurpation, pas une commodite. `make genome-pousser` — LE RUNNER POUSSE, LE POSTE NE ROUTE PAS. La forge du genome vit DANS le site, sur un reseau que le poste de l'exploitant ne route pas. On ne perce pas un chemin pour lui : on lui retire le role. Le poste emballe les commits dans un `git bundle` — un fichier, verifiable, qui ne demande aucun reseau — et le runner verifie, avance EN AVANCE RAPIDE SEULEMENT, puis pousse avec SA cle, autorisee en ecriture sur ces depots-la seulement. Ce qui est pousse se DERIVE de `serveur_ops_depots`. `DEPOT=<nom>` en cible un seul. Trois pieges rencontres, tous inscrits dans le code : l'outil ne peut pas etre supposé present sur le runner (il ne recevrait cette version qu'APRES la poussee qu'elle sert a faire — le controleur le porte) ; la branche n'est pas toujours `main` (deux depots vivent sur `master`, et le plan le declarait deja) ; le dossier des depots freres contient un espace, d'ou `argv` et non `cmd`. Le juge n'est pas le journal du playbook mais LA FORGE : on demande a son API ce qu'elle porte, et on refuse si ca differe de ce que porte le runner. Six depots verifies. Pourquoi ca comptait : la forge du site etait restee quatre commits derriere le poste, sans que rien ne le signale — dont le correctif qui desarme le pare-feu Proxmox. Un ecosysteme qui se reproduit depuis une forge en retard reproduit ses defauts. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
102 lines
5.3 KiB
YAML
102 lines
5.3 KiB
YAML
---
|
|
client_pki_paquets:
|
|
- step-cli
|
|
|
|
client_pki_steppath: "/etc/step"
|
|
|
|
# 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"
|
|
|
|
# LE CERTIFICAT DOIT COUVRIR LES NOMS SOUS LESQUELS ON APPELLE LE SERVICE (2026-08-25).
|
|
#
|
|
# Les SANs ne portaient que l'identite de la MACHINE — FQDN, nom court, IP. Or un service
|
|
# se declare `expose:` au plan, sous un nom qui lui survivra : `forge.genese.internal`
|
|
# reste le nom de la forge meme si elle demenage de `site-forge-01` a `site-forge-02`.
|
|
#
|
|
# Ce nom etait publie partout — plancher /etc/hosts, zone DNS — et couvert nulle part. Le
|
|
# clonage du genome a bute dessus : « certificate subject name (site-forge-01.genese
|
|
# .internal) does not match target hostname 'forge.genese.internal' ». Du TLS correct, sur
|
|
# un nom que personne ne peut appeler : la meme panne que le depot a deja rencontree cote
|
|
# resolution, ici cote certificat.
|
|
#
|
|
# ON N'AJOUTE QUE CE QUE CET HOTE SERT REELLEMENT : `edge` nomme le groupe qui rend le
|
|
# service, et l'hote doit en faire partie. Un certificat qui revendiquerait le nom d'un
|
|
# service rendu ailleurs serait une usurpation, pas une commodite.
|
|
client_pki_expositions: "{{ hosts_statiques_expositions | default([]) }}"
|
|
client_pki_sans: >-
|
|
{{ ([client_pki_nom_cert,
|
|
ansible_hostname | default(''),
|
|
ansible_host | default('')]
|
|
+ (client_pki_expositions
|
|
| selectattr('edge', 'defined')
|
|
| selectattr('fqdn', 'defined')
|
|
| selectattr('edge', 'in', group_names)
|
|
| map(attribute='fqdn') | list))
|
|
| select | unique | list }}
|
|
|
|
# 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"
|
|
|
|
# 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: []
|
|
|
|
# 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
|