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>
45 lines
2.6 KiB
YAML
45 lines
2.6 KiB
YAML
---
|
|
# Cible des sauvegardes : héberge les dépôts restic (un sous-dossier par nœud source).
|
|
# Les clients y accèdent en SFTP/SSH avec la clé de sauvegarde. Chiffrement côté client (restic).
|
|
serveur_backup_utilisateur: "restic"
|
|
serveur_backup_racine: "/srv/restic"
|
|
# Clé PUBLIQUE de sauvegarde autorisée (la privée est dans la voûte, côté client_backup).
|
|
serveur_backup_pubkey: ""
|
|
|
|
# --- Vérification des dépôts et rapport passif vers Icinga ---
|
|
# Le dépôt est le SEUL à voir ce qui est réellement arrivé. Un nœud sait qu'il a lancé sa
|
|
# sauvegarde ; il ne sait pas qu'elle a abouti. D'où la vérification ici, et pas là-bas.
|
|
# Toutes les 4 h, pas une fois par jour : la vérification doit renouveler le `ttl` bien
|
|
# avant qu'il n'expire, sinon un simple retard du timer se lirait comme une sauvegarde
|
|
# perdue. Elle est peu coûteuse (lecture des métadonnées restic).
|
|
serveur_backup_verification_horaire: "*-*-* 00/4:00:00"
|
|
|
|
# Seuils d'âge. Le critère « n'emporte rien » ne se règle pas ici : il se mesure en
|
|
# NOMBRE DE FICHIERS dans l'instantané (zéro = rien emporté), ce qui est exact, alors
|
|
# qu'un seuil en octets signalait à tort un export LDIF de 2,3 Ko.
|
|
serveur_backup_age_warn_h: 26
|
|
serveur_backup_age_crit_h: 50
|
|
|
|
# `ttl` du résultat passif : au-delà, Icinga périme le service de lui-même — c'est ce qui
|
|
# fait que le SILENCE alerte. 6 h pour une vérification toutes les 4 h : une exécution peut
|
|
# être manquée sans fausse alerte, deux ne le peuvent pas.
|
|
serveur_backup_ttl_icinga: 21600
|
|
|
|
# AC à opposer au pair en appelant l'API Icinga. C'est celle d'ICINGA, pas step-ca :
|
|
# Icinga refuse de servir un certificat qu'il n'a pas émis (il renouvelle tout ce qui
|
|
# expire sous 30 jours, nos certificats vivent 24 h). Domaine de confiance fermé, pair
|
|
# authentifié malgré tout — ce qui était le vrai enjeu.
|
|
serveur_backup_icinga_ca_source: "/var/lib/icinga2/ca/ca.crt"
|
|
serveur_backup_ca_verification: "/etc/setops/icinga-ca.crt"
|
|
|
|
# Compte d'API Icinga (portée : uniquement process-check-result sur « sauvegarde: * »).
|
|
serveur_backup_icinga_utilisateur: "setops-depot"
|
|
serveur_backup_icinga_motdepasse: "{{ vault_icinga_api_depot | default('') }}"
|
|
serveur_backup_icinga_hote: "{{ (groups['serveur_icinga'] | default([]) | first) | default('') }}"
|
|
|
|
# Nœuds dont un instantané est ATTENDU : ceux qui portent client_backup ET détiennent
|
|
# réellement de l'état. Même règle que `client_backup_jobs`, même source que P36.
|
|
serveur_backup_noeuds_attendus: >-
|
|
{{ (client_backup_groupes_etat | default([]) | map('extract', groups)
|
|
| select('defined') | flatten | unique | list)
|
|
| intersect(groups['client_backup'] | default([])) }}
|