Decouple exposure transport from caller authentication for reverse-proxy and tunnel deployments

[Aaronontheweb]

Summary

Netclaw currently mixes transport topology intent (tailscale-serve, tailscale-funnel, cloudflare-tunnel, reverse-proxy) with caller authentication expectations. That makes the deployment model too prescriptive and pushes us toward weak heuristics like local process detection for tailscaled / cloudflared.

Problem

A transport path and an authentication path are not the same thing:

• A request reaching Netclaw through Tailscale Funnel or Cloudflare Tunnel does not inherently prove who the caller is
• Third-party webhook senders like GitHub or Freshdesk will not arrive through Cloudflare Access
• Tailscale Serve headers can identify a tailnet user for some requests, but they do not apply to Funnel traffic
• Cloudflare Access JWTs are useful for interactive human access, but they are not the general answer for public webhook ingress
• Local tunnel process visibility is only an operational heuristic, not a trustworthy security boundary

This leaves us with an unclear model for what ExposureMode should actually mean:

• transport only
• transport plus authentication expectations
• or transport plus optional provider-specific auth schemes

Questions to answer

1. Should tailscale-serve, tailscale-funnel, and cloudflare-tunnel remain distinct exposure modes, or collapse into reverse-proxy plus optional auth features?
2. Which auth paths are first-class for non-local traffic?
3. Should provider-specific headers ever grant identity directly, and if so under what trusted-proxy constraints?
4. Should tunnel process detection be removed entirely as a startup gate and downgraded to doctor/ops guidance?
5. How should webhook ingress, interactive CLI/API access, and daemon-host local operator flows fit into one consistent model?

Likely direction

• Treat transport topology separately from authentication
• Keep TrustedProxies / forwarded headers for transport metadata and client-IP restoration only
• Keep request authentication route-specific:
  • bearer tokens for interactive/API clients
  • HMAC or shared-secret verification for third-party webhooks
  • optional provider-specific auth only where it adds real authenticated identity
• Avoid using local tunnel process detection as a hard security prerequisite

Related work

• Follow-up from PR feat: relax exposure mode strictness for container/proxy deployments (#862) #864
• Related to Design local CLI/operator access for secure reverse-proxy daemon binds #866
• Original context from ExposureModeValidationService crashes daemon instead of logging gracefully + tailscale-funnel check too strict for sidecar deployments #862

[Aaronontheweb]

Cross-links:\n- PR: #864\n- Related daemon-host local CLI/operator access issue: #866\n- Original exposure-hardening issue: #862