Propriétaire : Clément (Zolak)
Date de mise à jour : 23 Juillet 2026
Architecture : K3s Olympus (Pi) + K3s Atlas (VPS), reliés par Tailscale
Sentinelle : Aegis (Sentinelle Souveraine)
Inchangé depuis la version précédente : UFW SSH restreint à Tailscale, /run/shm isolé, tcp_syncookies/rp_filter actifs, root verrouillé, /home/zolak en 700.
Mise à jour du 23/07 : le port 443/tcp est désormais restreint à Tailscale sur le Pi (ufw allow from 100.64.0.0/10 to any port 443), la règle 443/tcp ALLOW Anywhere a été supprimée. Le port 80 reste ouvert publiquement — il ne sert plus qu'aux challenges ACME ponctuels (voir §4), aucune donnée applicative n'y transite.
L'ancien modèle (sous-domaine sslip.io par service + Basic Auth + CA auto-signée olympus-ca) posait deux problèmes découverts ce jour-là : impossible d'obtenir un certificat public reconnu sans exposer un port, et le Basic Auth ajoutait de la friction sans réelle plus-value une fois Tailscale en place partout. Nouveau modèle :
this-is-where-all-srart.tail8b05a5.ts.net.sudo tailscale cert this-is-where-all-srart.tail8b05a5.ts.net (Let's Encrypt, valable 90 jours).ports.<nom> dans le HelmChartConfig, ex. vault: 9001), car un certificat Tailscale ne couvre qu'un seul FQDN — impossible de router par sous-domaine comme avant.IngressRoute (CRD Traefik), pas des Ingress standards — nécessaire pour forcer explicitement tls: {} sur un entrypoint custom (voir pièges ci-dessous).tailscale-cert (namespaces default et kube-system), référencé par un TLSStore par défaut.tailscale-cert-renew.timer (systemd, hebdomadaire) exécute /home/zolak/olympus-k8s/renew-tailscale-cert.sh, qui relance tailscale cert et met à jour les secrets k8s.sslip.io sur l'IP publique réelle du VPS (51.83.68.166) — fonctionne car cette IP est réellement joignable par les serveurs de validation Let's Encrypt (contrairement à une IP Tailscale 100.x.x.x, jamais validée avec succès malgré plusieurs tentatives).ip-allowlist-tailscale ajouté à tous les Ingress (avant : seuls certains l'avaient, le reste était public sans restriction).goaccess-basic-auth, olympus-basic-auth) retiré de tous les Ingress.ports.vault.tls.enabled: true dans le HelmChartConfig ne génère aucun flag --entryPoints.vault.http.tls. Il faut soit passer par une IngressRoute avec un bloc tls: explicite, soit trouver la bonne clé de schéma (non résolu pour le Helm chart bundlé par k3s).IngressRoute refuse les middlewares inter-namespace par défaut. Une ressource Middleware dans kube-system référencée depuis une IngressRoute du namespace default échoue avec "middleware is not in the IngressRoute namespace". Solution retenue : dupliquer le Middleware CrowdSec dans default.IngressRoute.spec.routes[].services[].port, il faut le port exposé par le Service k8s (ex. 8082 pour Vaultwarden), pas le port du conteneur (80) — erreur silencieuse (service port not found).ROCKET_TLS). Il faut scheme: https + un serversTransport avec insecureSkipVerify: true sur le service de l'IngressRoute, sinon 500 malgré un routage correct.Host sur un port non-standard (Host: nom:9001) — un Host() Traefik configuré sans le port ne matche jamais. Solution : ne pas filtrer par host du tout (chaque port = un seul service de toute façon), juste PathPrefix('/').SIGNUPS_ALLOWED=false sur le clone pour empêcher toute création de compte indépendante (qui casserait le miroir).vaultwarden-sync.timer (03h20 quotidien) : scale à 0 le primaire → tar des données → scale à 1 → transfert rsync/SSH vers Atlas → scale à 0 le clone → remplacement des données → scale à 1.DATABASE_URL dormante pointant vers l'ancien Postgres du VPS — jamais appliquée car le pod n'avait pas redémarré depuis sa création, donc invisible jusqu'à ce jour. Le premier redémarrage déclenché par le script de sync l'a révélée (CrashLoopBackOff, Connection refused vers 100.121.0.42:5432). Corrigé en retirant la variable. Leçon : kubectl get deploy -o yaml régulièrement pour détecter la dérive entre manifeste sur disque et état réel du cluster.trivy était systématiquement le processus tué en boucle, empêchant le nœud de rester stable. À réactiver une fois une politique de ressources plus stricte définie — ne pas simplement le relancer tel quel.⚠️ falco-zkpgr reste en CrashLoopBackOff (observé avec plus de 1700 redémarrages sur 31 jours). Non résolu à ce jour — probablement lié au module noyau DKMS mentionné dans la version précédente de ce document, potentiellement aggravé par la pression mémoire du nœud. Action requise : diagnostic dédié (hors du périmètre de cette session).
Le tailnet est configuré pour faire router tout le DNS des appareils (y compris Atlas) via 100.86.197.49 (Olympus) en priorité — visible via tailscale dns status. Conséquence : la moindre instabilité du Pi (ex. la crise mémoire du 23/07) rend le DNS du VPS « server misbehaving », bloquant pulls d'images Docker et émissions de certificats Let's Encrypt.
Correction appliquée : /etc/resolv.conf du VPS forcé sur 1.1.1.1 / 8.8.8.8 puis verrouillé avec chattr +i — Tailscale ne peut plus l'écraser. Le DNS d'Atlas est désormais indépendant de la santé du Pi. (tailscale set --accept-dns=false seul s'est révélé insuffisant — le comportement observé ne correspondait pas à la documentation standard, chattr +i a été la solution robuste retenue.)
Inchangé : topic olympus_alerts_zolak_99 sur ntfy (port 8090 en interne cluster, exposé en Tailscale sur les deux réalmes). Utilisé désormais aussi par vaultwarden-sync.sh pour confirmer chaque synchronisation réussie.
| Timer | Fréquence | Rôle |
|---|---|---|
tailscale-cert-renew.timer |
Hebdomadaire | Renouvelle le certificat Tailscale et met à jour les secrets k8s |
vaultwarden-sync.timer |
Quotidien 03h20 | Synchronise Vaultwarden vers le clone Atlas |
backup_olympus.sh (cron) |
Quotidien 03h00 | Archive chiffrée de /var/lib/olympus-data + manifests, envoyée sur Atlas |