Deux mouvements d une seule doctrine : le site fournit tout ce dont un
tenant a besoin pour venir au monde.
1. LES DEPOTS TIERS. Grafana, Icinga, Smallstep et Collabora ne publient
qu en HTTPS ; apt-cacher-ng ne relaie pas un tunnel, et le socle pose donc
Acquire::https::Proxy DIRECT. Chaque machine sortait elle-meme sur
Internet. Le cache declare desormais un Remap par fournisseur, et chaque
role demande en {{ ..._depot_schema }}:// - http des qu un cache est
declare, https sinon. Le TLS n est rompu nulle part : il est TERMINE au
cache, qui est notre machine, et l integrite vient des signatures.
avant : 4 fournisseurs en HTTPS direct, 14 machines sortant seules
apres : 0 source en HTTPS direct, 0 erreur apt sur 14 machines
Trois lecons. Le remap appartient au cache qui SORT : pose sur un cache
chaine, il tente le HTTPS a travers son amont et rend 503. apt_repository
AJOUTE au lieu de remplacer, donc l ancienne ligne https sortait toujours.
Et la liste des fournisseurs ne se devine pas - j en avais trois, l audit
en a revele un quatrieme.
2. LE CACHE DU TENANT. Sa ligne portait son propre retrait depuis toujours
- service MUTUALISABLE, un ecosysteme au premier age peut pointer sur celui
de son hote. Retiree. Ce qu on perd, dit franchement : plus de trafic
inter-zone et plus de charge sur site-cache-01, contre un service de moins
a poser, superviser et reproduire.
3. UN ROLE QU ON RETIRE DOIT DEFAIRE CE QU IL A FAIT. Le retrait a montre
que rien ne nettoie derriere. Le fichier apt visait un cache eteint en
ecrasant le plancher qui fonctionnait - le defaut deja paye a quinze
machines. Et les sondes du cache restaient, le porteur poussant pour des
services qu Icinga ne definit plus (404). Le socle retire le premier,
client_sante derive les sondes attendues et retire les orphelines.
P65 refuse tout role visant un depot relaye en https ecrit en dur. Sa
limite est dite : elle empeche une regression sur ce qui est connu, elle ne
decouvre pas l inconnu.
Mesure : Icinga 87 OK sur 96, prouver 65 OK, lint 0 defaut.
Reste, et c est dit : apt-cacher-ng tourne toujours sur forge-01 que plus
aucun plan ne declare.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
|
||
|---|---|---|
| .. | ||
| defaults | ||
| handlers | ||
| meta | ||
| tasks | ||
| templates | ||
| 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à dansdocs/dependances-groupes.yml). - Réseau vers l'AC (
:8443).