bf-infra/docs/handoff-20260901-tp41.md

Handoff 2026-09-01 — TP41 CF-Access-Reparatur + Zero-Trust-Konsolidierung

Branch tp41-cf-access-repair. Alle CF-Änderungen sind live via API gemacht (Schreibpfad CF_API_TOKEN + curl, cf-tunnel-mapping.md §11). Working-Tree: docs/cf-backup/tp41-20260901/ (Snapshots, secret-frei) + dieser Handoff + teilprojekte.md-Eintrag; mcp/cloudflare/.env (gitignored) wurde geändert (Token-Konsolidierung). Helper-Skripte lagen im Scratchpad//tmp (cf_session.py, cf_harden.py, cf_groups.py, cf_vwadmin.py, cf_carveout.py, t4a.py).

Auslöser

Zugriff auf CF-geschützte Apps zwang Christoph und Geli faktisch täglich zum E-Mail-OTP-Login, obwohl 30 Tage gelten sollten; föderierte Logins (GitHub/Google) „funktionieren nicht". Root-Causes: (1) Team-Domain-Rename bf4 → emsenhuber ⇒ Provider-OAuth-Apps kennen die neue Callback-URL nicht; (2) App-Session 24h; (3) diverse Ordnungs-/Sicherheitslecks. Daraus wurde eine Zero-Trust-Konsolidierungs-Runde.

✅ LIVE erledigt (verifiziert)

• Session 720h auf Wildcard (16aaec78), vw-App (1dbc45ca), Warp-Login (6c32fe23).
• login_method-Loch geschlossen: reusable Policy bf-users (4ccc9b7e) = allow mit nur email:christoph@emsenhuber.com + email:<geli>@outlook.de (kein login_method-Include mehr). Attached an Wildcard / App-Launcher (6df5c431) / Warp-Login. Reusable Policy 8e44f5d1 entkoppelt → hängt jetzt nur noch an Terpenfinder (Fremdprojekt, nicht angefasst).
• Access-Gruppen (Prefix zt-): zt-humans (6eeec7f3, christoph+geli), zt-home (c0f8ba0d, IP 90.146.33.177/32), zt-automation (1b60b608, svc-token 65f1821a). Policies bf-users / bf4 (5165d139) / claude-mcp (39fe0e9d) zeigen jetzt auf die Gruppen → Personen-/IP-/Token-Pflege künftig nur noch in der Gruppe.
• vw = voll Bypass (Passwort-Lebensader: Web-Vault + Bitwarden-App/Extension/Desktop offen, kein CF-Login davor). Ein Carve-out-Versuch (nur Client-Pfade bypass, Rest gaten) wurde verworfen: CF-Bypass kurzschließt spezifischere path-Apps, und / (Web-Vault-Root) teilt den Prefix mit /admin — nicht trennbar. Die 3 Experiment-Apps wurden wieder gelöscht.
• vw.emsenhuber.net/admin öffentlich geblockt per WAF-Custom-Rule (Zone-Ruleset 416af72d0dd54853805875bf5752afd7, Regel f26744eb…, action=block, expr http.host eq "vw.emsenhuber.net" and (path eq "/admin" or starts_with(path,"/admin/"))). Verifiziert über CF-Edge und vom User per Mobilfunk („you have been blocked"). Lokal (Heim-LAN, Split-Horizon → Caddy) und später WARP-intern bleibt /admin erreichbar.
• API-Token konsolidiert: mcp/cloudflare/.env CF_API_TOKEN = …4148 (id 493ed8bd…), Backup mcp/cloudflare/.env.bak-tp41-20260901. Der User hat …4148 anschließend vollständig gemacht (u.a. Access: Service Tokens Write + Zero Trust Write + WAF + Groups + DNS für emsenhuber.net und teilzeitladen.xyz). Altes Token …2174 (id 9984078812bc18d4ebb6a64b570144f2) kann in CF revoked werden.

🔜 OFFEN (Token reicht jetzt für alles außer T5)

• T4 — kumulatives Service-Token zt-svc (Basis: t4a.py, war nur an fehlender Perm gescheitert):
  1. claude-mcp (65f1821a) rename → zt-svc + rotate (Secret einmalig).
  2. terpene-svc-Policy (bf7d2e5e) additiv += group zt-automation (akzeptiert dann alt und neu).
  3. Secret ablegen: mcp/cloudflare/.env (CF_ACCESS_CLIENT_ID/SECRET) und ~/.secrets/credentials.env — dort auch die Terpene-Aliase TERPENE_ACCESS_CLIENT_ID/SECRET (die die Tools lesen) und TERPENE_VERIFY_CF_CLIENT_ID/SECRET (beide zeigten auf terpene-verify-v2).
  4. Verify Terpene: python3 ~/dev/blaueblueten-n8n/tools/test_whoami.py (→ 420.teilzeitladen.xyz/api/admin/whoami, muss weiter funktionieren).
  5. Erst nach grünem Verify: terpene-verify-v2 aus terpene-svc entfernen, dann terpene-verify (a6be7efa) + terpene-verify-v2 (1082bad1) löschen.
  6. ~/.secrets/README.md-Index nachziehen. opencode/exports.zsh optional (gui-env-sync). → End: ein Service-Token zt-svc über Gruppe zt-automation in allen Apps + Consumern.
• T3 — WARP löst emsenhuber.net intern auf (User-Wahl „Variante 2"): WARP-Device-Profile fallback_domains += emsenhuber.net → interner Resolver 10.40.20.1 (liefert Split-Horizon *.emsenhuber.net → Caddy 10.40.20.40). Route 10.40.0.0/16 existiert (tunnel d1da7c8a). Danach /admin + alle internen Namen über WARP via Caddy erreichbar (kein CF/WAF). ⚠️ account-/ profilweit → als Lifecycle-Change proaktiv melden. (Token hat jetzt Zero-Trust-Write.)
• T2 — 404 statt 403 (User-Wunsch): WAF-Custom-Response ist Free-Plan-gesperrt („not entitled to use a custom response"). 403-Block bleibt — außer man macht es Origin-seitig in Caddy (respond 404 wenn Header CF-Connecting-IP gesetzt = via CF gekommen; lokal/WARP-intern ohne Header → durchlassen). Das komponiert sauber mit T3 (WARP-intern trifft Caddy ohne CF-Header). Eigener Caddy-Deploy (LXC 130).
• T5 — IdP-Konsolen (USER-Hausaufgabe, DER Daily-OTP-Fix, bestätigt kaputt): User-Test lieferte GitHub „The redirect_uri is not associated with this application". Fix in den Provider-Konsolen:
  • GitHub OAuth-App Ov23li2h96hAkGRPJXYV → Authorization callback URL
  • Google OAuth-Client → Authorized redirect URIs
  • beide = https://emsenhuber.cloudflareaccess.com/cdn-cgi/access/callback. Danach Login-Test je Provider; Gegenprobe CF-Audit GET /accounts/…/access/logs/access_requests (identity_provider=github/google statt onetimepin).
• T6 (optional) — Rate-Limit: vw /identity/connect/token + gitea-Login. Kein Managed-Challenge vor vw-API//identity, git-/api-Pfaden, assetlinks.json (bricht Bitwarden-Clients / git / MCP).
• T7 — Doku: ggf. docs/tp41-cf-access-repair-runbook.md (Detail-Runbook) ergänzen.

🆕 NEU — dw/Geli an der Auth vorbei (Terpenfinder, CGNAT)

Ziel: dw erreicht 420.teilzeitladen.xyz ohne CF-Login. IP-Bypass wie bf4 scheitert an Gelis CGNAT. Eleganteste Lösung (User-Idee): Split-Horizon am dw-Standort — dw-FritzBox setzt lokalen DNS-Override 420.teilzeitladen.xyz → BF-Caddy (caddy-bf1 / 10.40.20.40), erreichbar über den bestehenden WG-Tunnel dw↔core; Caddy braucht einen Block 420.teilzeitladen.xyz → macmini-Worker (10.40.20.167:8890) mit Cert (DNS-01; Token hat jetzt DNS-Write für teilzeitladen.xyz). Vorab prüfen: (a) FritzBox-Host-Override möglich; (b) WG-Route dw→10.40.20.40; (c) Worker wirklich auf macmini:8890 von Caddy erreichbar. Cross-Projekt (teilzeitladen.xyz). Alternative: Geli-Gerät in WARP (Session statt Login, CGNAT unkritisch) + Access-Policy auf WARP-Identität.

❓ Scope-Klärung für die neue Session

Der User nannte „TP3/TP4/TP5 gleich mitnehmen" — diese sind laut teilprojekte.md abgeschlossen (TP3 WLAN-Rebuild ✅, TP4 ap1-Router/WAN-Edge ✅, TP5 deny-by-default ✅). Vermutlich Zahlendreher. Offene Kandidaten: TP6 (CAKE, Projektziel), TP16.1 (WARP-Mesh nativ), TP16.3, TP24 (DC-USV), TP25 (WLAN-Signal/Re-Walk). Vor Start klären, welche gemeint sind (je eigene Session empfohlen; Subagenten nur für parallele, abgegrenzte Teilaufgaben innerhalb einer Session).

🧭 Test-Vantage-Lehre (wichtig, hat hier Stunden gekostet)

Von der Heim-IP löst *.emsenhuber.net → 10.40.20.40 (Caddy) und umgeht CF komplett — CF-Access/ WAF-Gating ist von zuhause nicht sichtbar (alles wirkt „offen"). Edge-Verhalten erzwingen mit curl --resolve <host>:443:<CF-anycast-IP> (CF-IP via dig @1.1.1.1 +short <host>). WebFetch ist für Access/Redirects unzuverlässig (erreichte Origin trotz Gating) — nicht als Beweis verwenden; echter Remote-Test = User-Gerät im Mobilfunk.

Referenz-IDs

Apps: Wildcard 16aaec78 · vw/hass/gitea-Bundle 1dbc45ca · App-Launcher 6df5c431 · Warp-Login 6c32fe23 · Terpenfinder v3 e6a7991f. Policies: bf-users 4ccc9b7e · bf4 5165d139 · claude-mcp 39fe0e9d · terpene-svc bf7d2e5e · (Terpene-only) 8e44f5d1. Gruppen: zt-humans 6eeec7f3 · zt-home c0f8ba0d · zt-automation 1b60b608. Service-Tokens: claude-mcp→zt-svc 65f1821a · terpene-verify a6be7efa (Waise) · terpene-verify-v2 1082bad1. WAF: Ruleset 416af72d…, Regel f26744eb…. Team-Domain emsenhuber.cloudflareaccess.com (Org-name-Altlabel bf4… nicht anfassen).