Demande : « ne pas avoir le basic auth Traefik quand on est sur le Wi-Fi partagé
avec le homelab ». La réponse intuitive — une règle `ClientIP(192.168.1.0/24)` —
ne peut pas marcher, et la variante « je regarde CF-Connecting-IP » est un
contournement d'authentification. Ce commit écrit la mesure pour qu'on ne
re-découvre ni l'une ni l'autre.
Mesuré (2026-07-28, homelab) :
- `kadans.arcodange.fr` résout vers Cloudflare MÊME depuis le LAN, et redescend
par le tunnel cloudflared. L'adresse de socket vue par Traefik est donc
toujours celle d'un pod, en 10.42.x.x.
- Traefik SAIT qui est le vrai client (journal d'accès : l'IPv6 de la maison,
`2a01:cb04:dff:cf00::/64` — pas l'IPv4 qu'`ipify` injecte dans `localIp`), car
l'entrypoint `web` fait confiance aux en-têtes venant de 10.42.0.0/16.
- Mais le matcher de routeur `ClientIP()`, lui, juge la SOCKET. Prouvé par trois
routeurs temporaires vers un Service sans endpoint (503 = règle matchée,
401 = repli sur le routeur normal) : témoin 503, `ClientIP(<IPv6 maison>)` 401,
`ClientIP(10.42.0.0/16)` 503. Sondes retirées après mesure.
D'où deux pièges, écrits là où on les rencontrerait :
- `localIp@file` sur un routeur `.fr` laisserait entrer Internet entier, parce
que `10.42.0.0/16` est dans son `sourceRange` et qu'`ipAllowList` juge lui
aussi la socket. Vérifié : aucun routeur `.fr` ne le porte aujourd'hui — le
piège est latent, et les cinq endroits d'où on pourrait le recopier
(2 gabarits `.fr`, 3 values `.lab`) portent désormais l'avertissement.
- Un en-tête posé par le client ne peut pas piloter une exemption d'auth :
Cloudflare ne retire pas les en-têtes inconnus, et Traefik reste joignable en
direct sur 192.168.1.201.
Voie retenue, et pourquoi celle-là : la décision « suis-je à la maison ? » doit
être prise là où la vraie IP est native et non falsifiable, donc au bord, chez
Cloudflare. Une règle de transformation y pré-remplit l'en-tête `Authorization`
pour les IP du foyer. Traefik ne bouge pas, aucun certificat public à produire,
aucun changement DNS. Surface d'attaque ajoutée : AUCUNE — `kadans:kkadans` est
déjà en clair dans le chart de kadans, Cloudflare ne fait que le taper à notre
place. Et quand l'IP du foyer dérive, la règle cesse de matcher : le navigateur
redemande le mot de passe. Dégradation douce, pas de panne.
Le doc écrit l'action Cloudflare mot pour mot (expression, en-tête, valeur, et
l'équivalent Terraform pour `cms/cloudflare`) plutôt que de la supposer faite,
avec les deux commandes qui la vérifient — et nomme le repli si Cloudflare
refuse de modifier `Authorization` : Cloudflare Access avec une politique de
bypass, PAS un en-tête secret.
Enfin, un contre-exemple utile : le bouncer CrowdSec, lui, juge la VRAIE IP
(journal à l'appui). Son `clientTrustedIPs` contient `10.42.0.0/16` sans que ce
soit un trou — noté pour que personne ne « corrige » cette ligne en croyant y
reproduire le piège.
⚠ Aucun des réglages en cause ne vit dans ce dépôt : les valeurs Helm de
Traefik, `dynamic.yaml`/`localIp` et le Middleware crowdsec sont dans `factory`
(ansible), le tunnel et le DNS dans `cms`. Ce dépôt reçoit la mesure et les
garde-fous parce que c'est lui qui héberge les gabarits `.fr` et les
consommateurs de `localIp@file`.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01GdUCA5Uz8QyMwa2P4Pg2hK
Second Ingress (grafana-public) en PLUS du .lab, comme kadans :
- entrypoint `web` — TLS terminé en amont par le tunnel Cloudflare
(wildcard *.arcodange.fr → traefik:80, rien à changer côté cms/cloudflare) ;
- middleware crowdsec (convention .fr) ;
- pas de basic-auth : Grafana a sa propre authentification (aucun accès
anonyme dans grafana.ini), contrairement à kadans qui est ouvert.
Le .lab garde son localIp@file ; rendu par le wrapper SubChart et appliqué
par ArgoCD (précédent : prometheus/templates/vault-telegram.yaml).
Co-Authored-By: Claude Fable 5 <[email protected]>
- prometheus : cible statique kadans-worker-mac (192.168.1.103:9105, tier
laptop). Un scrape raté n'est PAS un incident : le Mac dort, up==0 raconte
la latence — ne pas alerter dessus. ⚠ réserver l'IP au routeur (DHCP).
- grafana : provider + dashboard « Kadans — jobs d'analyse » (uid
kadans-jobs-analyse) : worker en écoute / dernier poll / file pending + âge
du plus ancien (seuils 1 h / 24 h = le SLO), file par statut et publications
par issue (couleurs de STATUT sémantiques), lanes exécutées et durée moyenne
par lane. La façade, elle, arrive par les annotations de son pod
(kadans-jobs#3) — zéro config ici.
Co-Authored-By: Claude Fable 5 <[email protected]>
Aligne le dashboard « Prospection — pipeline BI missions » sur le cahier
des charges de supervision :
- jauge 0–100 pour le meilleur score d'opportunité (au lieu d'une stat)
- nouvelle stat « Offres du brief » (prospection_brief_offres)
- bar charts « Durée par étape » et « Items par étape » sur le dernier run
(prospection_step_duration_seconds / prospection_step_items)
- cadence quotidienne : refresh 30m et plage par défaut now-7d
Provisionné via le provider Grafana « prospection » (JSON inline dans
grafana/values.yaml), datasource Prometheus (${DS_PROMETHEUS}).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Grafana tourne en SQLite sur emptyDir → migration complète du schéma à chaque
démarrage de pod, > 160 s sur Raspberry Pi. La liveson (initialDelay 60 + 10×10s)
tuait Grafana en pleine migration → CrashLoop du nouveau pod à chaque rollout
(révélé par le rollout du dashboard prospection). Ajoute une startupProbe (~10 min)
et relève failureThreshold de la liveness (filet si le chart n'expose pas startupProbe).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Consomme les métriques poussées par le pipeline prospection au Pushgateway
(job=prospection, déjà scrapé). Additif — n'affecte aucun dashboard existant.
- grafana : provider + dashboard « Prospection — pipeline BI missions » inliné
(grafana.dashboards.prospection, json) — vue d'ensemble (fraîcheur/statut/durée/
erreurs/missions/score), collecte par étape (table + historique), modèle de
données (opportunités A/B, offres/entités), livraison (brief/Telegram) + panneau
Alertes actives. Inline plutôt que ConfigMap externe : grafana est déployé via un
HelmChart CRD (tool lib), l'inline évite toute hypothèse de namespace.
- prometheus : groupe d'alertes `prospection` (serverFiles.alerting_rules.yml) —
RunStale (>25h), RunFailed, StepError, NoOffers, BriefNotSent.
NB : la livraison des alertes (Alertmanager → Telegram) n'est pas câblée dans le
cluster (server.alertmanagers vide, aucun receiver) ; les règles restent visibles
dans Prometheus /alerts + le dashboard. Câblage delivery = décision séparée.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
arcodangeandClaude Opus 5