Daniel Allaire
4dd4d3755d
Objectif : supprimer le `curl -k` du rapporteur. Fait, et la maniere a ete
imposee par la mesure.
SERVIR UN CERTIFICAT STEP-CA SUR L'API EST IMPOSSIBLE. Icinga le dit lui-meme :
« Our certificate will expire soon, but we own the CA. Renewing. » Il renouvelle
tout certificat expirant sous 30 jours ; les notres vivent 24 h ; possedant une
AC, il re-emet avec la sienne et ecrase le notre a chaque demarrage. Collision
entre deux politiques de PKI, et la notre n'est pas negociable.
Deux decouvertes en chemin, toutes deux par le garde-fou `icinga2 daemon -C`
ajoute au role, qui a ARRETE le deploiement avant de redemarrer la supervision :
- cert_path/key_path/ca_path sont DEPRECIES depuis 2.8 ; les poser reveille un
chemin de code herite qui exige en plus un objet Endpoint ;
- l'identite de l'API est le CN du certificat. NodeName valait « mon-01 », donc
le SAN aussi, alors qu'on appelle par le FQDN : aucune verification n'aurait
pu reussir. NodeName est desormais aligne sur le FQDN.
A LA PLACE : Icinga garde son AC (domaine de confiance FERME, legitime) et
backup-01 verifie le pair contre CETTE AC, recuperee depuis mon-01 au
deploiement. Le pair est authentifie ; seule la racine differe.
Controle negatif — une verification qu'on ne teste pas est un ornement : avec la
mauvaise AC (step-ca), curl refuse (« unable to get local issuer certificate ») ;
avec la bonne, les neuf rapports passent.
Sous-AC step-ca ecartee : elle poserait sur l'hote de supervision une cle capable
d'EMETTRE pour n'importe quel nom, alors qu'on a choisi le sens du flux pour que
compromettre mon-01 ne donne rien.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| defaults | ||
| meta | ||
| tasks | ||
| templates | ||
| README.md | ||
serveur_backup
Cible des sauvegardes : héberge les dépôts restic (un sous-dossier par nœud source),
servis en SFTP/SSH à un utilisateur restreint. Le pendant de client_backup.
Rôle
- Crée l'utilisateur système
resticet la racine des dépôts/srv/restic. - Sécurise cette racine (droits stricts).
- Autorise la clé publique de sauvegarde dans son
authorized_keys.
C'est tout : le rôle est délibérément minimal. Aucun démon, aucune logique de sauvegarde — tout se passe côté client (dumps, chiffrement, rétention).
Sécurité
Le chiffrement est fait par le client (restic) : ce nœud ne détient que des blocs chiffrés et n'a jamais le mot de passe des dépôts. Compromettre la cible ne donne pas accès aux données.
La clé privée correspondante vit dans la voûte, côté client_backup
(vault_backup_ssh_privkey) ; seule la publique est déclarée ici.
Variables
| Variable | Défaut | Rôle |
|---|---|---|
serveur_backup_utilisateur |
restic |
Compte de dépôt |
serveur_backup_racine |
/srv/restic |
Racine des dépôts |
serveur_backup_pubkey |
(vide — obligatoire) | Clé publique autorisée |
Le rôle exige serveur_backup_pubkey (assertion) : sans elle, la cible serait déployée
mais inaccessible.
Flux (meta/flux.yml)
22/tcp entrant depuis client_backup (SSH, clé dédiée). Aucun autre port.
Notes / limites
- Hors-nœud, pas hors-site : la cible protège de la perte d'une VM, pas de la perte du cluster. Une copie hors-site reste à faire.
- Dimensionner le disque en conséquence (
meta/empreinte.yml: 64 Go par défaut) — c'est la ressource critique de ce nœud. - Le compte
resticn'est pas confiné à un shell restreint (rrsync/ForceCommand) : durcissement possible si la cible venait à sortir du périmètre de confiance.
Prérequis
- Couche services (avant les agents
client_backup).