fix(tunnel): detect cloudflared zone-mismatch routing and fail loudly#473
Open
bussyjd wants to merge 1 commit into
Open
fix(tunnel): detect cloudflared zone-mismatch routing and fail loudly#473bussyjd wants to merge 1 commit into
bussyjd wants to merge 1 commit into
Conversation
`obol tunnel login --hostname X.example.com` shells out to `cloudflared tunnel route dns <tunnel> X.example.com`. If ~/.cloudflared/cert.pem is scoped to a Cloudflare account that does not own the zone for the requested hostname, cloudflared silently falls back to the cert account's default zone and routes DNS to `X.example.com.<default-zone>` instead — but exits 0. Obol only checked the exit code, so it reported success and the rest of the helm/manifest apply ran against a hostname that will never resolve publicly. Add `verifyRoutedHostname`, a pure parser of cloudflared's combined stdout/stderr matching the two known success log shapes: Added CNAME <hostname> which will route to this tunnel ... <hostname> is already configured to route to your tunnel ... If the extracted hostname does not match the requested one (case-insensitive, trimmed), `Login` returns an actionable error pointing the user at their cert.pem. Unknown log shapes are treated as "no signal" so an upstream log-format change cannot break the happy path. Hit today on spark2 asking for `inference.v1337.org` against a cert.pem scoped to the `humanresearch.ai` account; cloudflared quietly routed `inference.v1337.org.humanresearch.ai` and obol reported success, costing ~30 min debugging the wrong layer.
e788f34 to
1b0388d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
obol tunnel loginnow parses cloudflared'stunnel route dnsoutput and fails loudly if the routed hostname does not match the requested one (case-insensitive). Catches the silent zone-fallback failure mode where~/.cloudflared/cert.pemis scoped to a Cloudflare account that does not own the zone for the requested hostname — cloudflared appends its default zone (e.g.inference.v1337.org→inference.v1337.org.example.com) and exits 0.verifyRoutedHostnameis a pure function on the cloudflared output string; no Cloudflare API calls (locally-managed mode has no API token). Unknown log shapes are treated as "no signal" so an upstream log-format change cannot break the happy path.TestVerifyRoutedHostnamecovers both success log shapes, both mismatch shapes, empty output, mixed-case tolerance, and unknown-shape pass-through.Test plan
go test ./internal/tunnel -count=1 -run 'TestVerifyRoutedHostname|TestRouteDNSArgs'(7 subtests pass)go build ./...obol tunnel login --hostname inference.v1337.orgon a host whose~/.cloudflared/cert.pemis scoped to a different zone — expect a clear error pointing at cert.pem, no helm/manifest applyobol tunnel loginagainst a correctly-scoped cert.pem still succeeds end-to-end