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

46 lines
2.6 KiB
YAML
Raw Normal View History

---
# 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: ""
supervision : c'est le DEPOT qui dit ou en sont les sauvegardes Icinga ne surveillait rien : aucun objet Host ni Service de Set-OPS, seulement la config Debian d'origine sur localhost. Superviser setops-sauvegarde.service aurait reproduit le defaut du jour meme : l'unite etait VERTE sur onze noeuds pendant qu'elle n'emportait rien. Le noeud sait qu'il a LANCE sa sauvegarde, pas qu'elle est ARRIVEE. backup-01 evalue donc ses depots et pousse un resultat passif par noeud vers l'API Icinga. Trois criteres, parce qu'un seul suffit a mentir : l'instantane existe, il est recent (26 h / 50 h), il contient au moins un fichier. Le sens du flux est delibere : le depot parle a la supervision, jamais l'inverse — compromettre mon-01 ne donne aucun acces aux sauvegardes. Le ttl de 6 h fait la fraicheur : si le rapporteur se tait, Icinga perime les services tout seul. C'est le silence qui a laisse le defaut vivre un mois. Deux erreurs corrigees par la mesure : - --data-urlencode refuse en Bad Request (l'API veut du JSON) ; le flux, le TLS et l'auth marchaient, seule la charge etait perdue. - le seuil « vide » en octets signalait a tort idm-01 (2363 o) : un export LDIF d'un annuaire a un compte pese cela. « Vide » se mesure en FICHIERS. Et le verdict est un AVERTISSEMENT : la machine ne distingue pas « les donnees ont disparu » de « il n'y en a pas encore ». Reserve assumee : curl -k — l'API presente le cert de sa propre AC, pas step-ca. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 21:39:05 -04:00
# --- 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
icinga : le pair est verifie — mais pas avec un certificat step-ca 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>
2026-08-12 08:33:50 -04:00
# 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"
supervision : c'est le DEPOT qui dit ou en sont les sauvegardes Icinga ne surveillait rien : aucun objet Host ni Service de Set-OPS, seulement la config Debian d'origine sur localhost. Superviser setops-sauvegarde.service aurait reproduit le defaut du jour meme : l'unite etait VERTE sur onze noeuds pendant qu'elle n'emportait rien. Le noeud sait qu'il a LANCE sa sauvegarde, pas qu'elle est ARRIVEE. backup-01 evalue donc ses depots et pousse un resultat passif par noeud vers l'API Icinga. Trois criteres, parce qu'un seul suffit a mentir : l'instantane existe, il est recent (26 h / 50 h), il contient au moins un fichier. Le sens du flux est delibere : le depot parle a la supervision, jamais l'inverse — compromettre mon-01 ne donne aucun acces aux sauvegardes. Le ttl de 6 h fait la fraicheur : si le rapporteur se tait, Icinga perime les services tout seul. C'est le silence qui a laisse le defaut vivre un mois. Deux erreurs corrigees par la mesure : - --data-urlencode refuse en Bad Request (l'API veut du JSON) ; le flux, le TLS et l'auth marchaient, seule la charge etait perdue. - le seuil « vide » en octets signalait a tort idm-01 (2363 o) : un export LDIF d'un annuaire a un compte pese cela. « Vide » se mesure en FICHIERS. Et le verdict est un AVERTISSEMENT : la machine ne distingue pas « les donnees ont disparu » de « il n'y en a pas encore ». Reserve assumee : curl -k — l'API presente le cert de sa propre AC, pas step-ca. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 21:39:05 -04:00
# 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([])) }}