Daniel Allaire
22ef279464
Une règle qu'aucune garde ne vérifie finit par ne plus être vraie — c'est ce qui était arrivé aux 28 lignes d'intégration recopiées. Chaque rôle serveur_* porte un meta/authentification.yml, confronté à son code par P29. web-sso 5, socle-identite 2 (keycloak/openldap : ils SONT la chaîne d'identité), ldap-direct 2, interne-sans-auth 2, sans-auth-humaine 12. La preuve refuse l'oubli ET le mensonge. Éprouvée par sabotage sur sept cas : déclaration supprimée, portée inventée, secours retiré, posture de formulaire retirée, raison retirée, ldap-direct mensonger, réglage retiré des defaults. Les deux derniers passaient dans la première version : - le mensonge passait à cause d'un commentaire. Je cherchais le mot « ldap » dans le rôle, et serveur_grafana/defaults/main.yml contient « désactiver quelqu'un dans LDAP » : de la prose validait une déclaration fausse. La preuve exige maintenant un indice nommé — variable <rôle>_oidc / <rôle>_ldap, ou URI ldap:// - le réglage retiré passait parce que le gabarit citait encore la variable alors que plus rien ne lui donnait de valeur. La preuve lit defaults/main.yml en YAML et exige que la clé y soit définie, pas mentionnée. Elle a aussi forcé une valeur : oauth2-proxy était déclaré « formulaire local fermé » alors qu'il n'a aucun compte local. D'où formulaire_local: aucun, qui distingue « il n'y en a jamais eu » de « il y en a un, il est fermé ». Correction d'une note de la veille : Prometheus et Loki ne sont PAS exposés publiquement (aucun expose au plan). Seuls six groupes le sont. Le risque est intra-tenant, pas frontalier. Les deux lacunes sont comptées à chaque exécution, pas masquées. AFF-111, D-42. 29 preuves OK, ansible-lint (production) sur 375 fichiers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| defaults | ||
| meta | ||
| tasks | ||
| 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).