Phase 1 : socle & sécurité (WireGuard, Ansible, OpenTofu)

- Reconnaissance : le serveur héberge déjà 6 autres projets derrière un
  Caddy partagé (80/443) ; tripoli-edge sera un service interne (décision
  prise avec l'utilisateur), pas un second frontal.
- WireGuard : canal admin Mac <-> serveur (10.100.0.0/24, port 58212/udp
  après avoir découvert que 51820 était filtré par le pare-feu Hetzner
  Cloud, distinct de ufw).
- Ansible : rôle base (confirme fail2ban/unattended-upgrades/ufw déjà en
  place, sans toucher aux règles des autres projets) + rôle wireguard
  (clé privée générée sur la cible, jamais stockée dans ce dépôt).
- OpenTofu : serveur Hetzner référencé en data source lecture seule
  (jamais recréé/détruit - serveur partagé et déjà en prod) ; DNS
  tripoli.cloud géré via le provider OVH.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

ansible/README.md

@@ -0,0 +1,39 @@
+# Ansible — socle Tripoli Cloud
+
+Un seul hôte (`tripoli_cloud`), pas d'inventaire dynamique : ce serait
+simuler une flotte qui n'existe pas. Le serveur héberge aussi cinq autres
+projets ; ce dépôt ne gère que ce qui concerne Tripoli Cloud (voir les
+commentaires dans `roles/base/tasks/main.yml`).
+
+## Lancer
+
+```bash
+ansible-galaxy collection install -r requirements.yml   # une fois
+ansible-playbook site.yml --diff
+```
+
+`ansible_host` pointe pour l'instant sur l'IP publique (`inventory/hosts.yml`)
+car le SSH public reste ouvert par choix explicite. Une fois le SSH public
+fermé (`ssh_restrict_to_wireguard: true` dans `group_vars/all.yml`), changer
+`ansible_host` pour `10.100.0.1` et lancer les playbooks depuis une machine
+dont le tunnel WireGuard est monté — sinon Ansible ne pourra plus joindre le
+serveur.
+
+## Secrets
+
+Aucun secret dans ce dépôt, volontairement :
+
+- La clé privée WireGuard du serveur est générée **sur le serveur** par le
+  rôle `wireguard` (`wg genkey`, `creates:` la rend idempotente) et n'en sort
+  jamais. Pas de vault, pas de fichier chiffré à gérer.
+- Les clés publiques des pairs (Mac admin, etc.) ne sont pas sensibles :
+  elles vivent en clair dans `group_vars/all.yml`.
+
+## `ssh_restrict_to_wireguard`
+
+À `false` (valeur actuelle) : le rôle ne touche pas à la règle `22/tcp`
+existante (ouverte à "Anywhere", posée manuellement avant Ansible).
+À `true` : le rôle retire cette règle et n'autorise plus le 22/tcp que
+depuis `10.100.0.0/24`. Vérifier que le tunnel fonctionne avant de basculer
+ce flag — sinon risque de perdre l'accès root normal (recours : console de
+secours Hetzner, indépendante du réseau).