fix(auth): reject spoofed Tailscale identity on management ingress - #413
fix(auth): reject spoofed Tailscale identity on management ingress#413luvs01 wants to merge 20 commits into
Conversation
release: promote dev into main for v2.32.1
# Conflicts: # package.json
[WRONG BRANCH] merge dev into main for the v2.33.0 release
Promotes the dev integration line onto main. The resulting tree is byte-identical to origin/dev, including package.json at 2.34.0. The package.json conflict is resolved to dev's side, NOT to main's stale 2.33.0. Earlier promotions (lidge-jun#2553, lidge-jun#2507) kept the target's version so the release bump would land on its own "release: vX.Y.Z" commit. That is no longer legal: this very delta adds tests/release-version-line.test.ts, which fails when the in-tree version sits behind the highest release tag. With v2.34.0-preview.20260827 now published, 2.33.0 orders behind it, so a promotion carrying the stale line turns CI red on every shard that runs the suite. The consequence for the release step is that scripts/release.ts skips the bump (release.ts:568, currentVersion === version), so v2.34.0 gets tagged on this merge commit rather than on a separate release commit. The workflow creates the tag itself after publishing and validates expected-sha against the checked-out commit, so the tag still names exactly the audited tree.
[WRONG BRANCH] promote dev onto main for v2.34.0
[WRONG BRANCH] promote dev onto main for v2.35.0
[WRONG BRANCH] promote dev onto main for v2.36.0
[WRONG BRANCH] promote dev to main for the v2.37.0 release
[WRONG BRANCH] promote dev onto main for v2.38.0
[WRONG BRANCH] promote dev onto main for v2.39.0
release: promote dev to main for v2.40.0
…rkflow call (lidge-jun#3262) Both v2.40.0 release dispatches (33615174183 preview, 33615177849 main) died at startup_failure: a workflow_call cannot grant its callee more than the calling job holds, and dev-version-bump.yml's job declares contents+pull- requests write. lidge-jun#3129 wired the call but never dispatched a release, so this is its first live run. The caller job now declares exactly the callee's two permissions; no other job in release.yml gains anything. Co-authored-by: jun <jun@lidge.dev> (cherry picked from commit 7ce0ba5)
…400-relfix release: carry the release.yml permissions fix onto main for v2.40.0
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Team Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
✅ Deterministic PR hygiene checks passed. |
github-actions
Bot
changed the title
✅ READY
Hygiene✅ Deterministic PR hygiene checks passed. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 332061470f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Set `hub.managementPublicOrigin` to the exact HTTPS origin shown by Serve. The loopback backend does | ||
| not accept Tailscale identity headers as authentication; establish the browser session with the | ||
| single-use pairing flow. Verify both directions: |
There was a problem hiding this comment.
With automatic Tailscale session issuance removed, operators following this deployment guide can reach the dashboard but are never told how to obtain the pairing code it requests. Add the actionable flow—run ocx gui pair --origin https://hub-name.tailnet-name.ts.net on the hub and paste the resulting one-use code into the remote dashboard—to the English guide and its updated translations.
AGENTS.md reference: docs-site/AGENTS.md:L15-L16
Useful? React with 👍 / 👎.
| | `hub.managementPublicOrigin` | string | unset | The canonical browser-reachable management origin a hub advertises, for example the HTTPS origin Tailscale Serve prints. It is what `/readyz` reports as `managementUrl` while `runtimeRole` is `hub`; with it unset the hub falls back to whatever origin each request arrived on, so a client behind a different frontend can be handed an address it cannot reach. | | ||
| | `hub.managementIngress` | `{enabled:false}` or `{enabled:true, port}` | `{enabled:false}` | An extra management-only listener for a local HTTPS frontend. The hostname is not configurable: when enabled the socket always binds `127.0.0.1`, and only GUI, session-bootstrap, and management API routes are admitted. Data-plane routes are rejected before dispatch. | | ||
| | `remoteGui.allowedTailscaleUsers` | string[] | `[]` (empty — nobody) | Exact Tailscale login identities allowed to be issued an automatic remote GUI session. The `Tailscale-User-Login` header is trusted **only** on the separate management ingress; an empty list means no remote identity can mint a session, which is the safe default rather than an oversight. Identities are compared exactly, so a typo silently denies access. | | ||
| | `remoteGui.allowedTailscaleUsers` | string[] | `[]` | Retained for configuration compatibility. The loopback TCP management ingress does not trust `Tailscale-User-Login`, because local callers can forge proxy headers; remote browser sessions use one-use pairing instead. | |
There was a problem hiding this comment.
This row now correctly declares remoteGui.allowedTailscaleUsers compatibility-only, but the immediately preceding English summary still says a hub uses the exact allowlist, and the translated configuration references repeat that stale claim (for example fr/reference/configuration/server.md:258 and ja/reference/configuration/server.md:167). Users of those pages will continue configuring a value that no longer affects authentication, so update the summary and all translated references to match the new behavior.
AGENTS.md reference: docs-site/AGENTS.md:L7-L10
Useful? React with 👍 / 👎.
luvs01
changed the title
2 participants
Motivation
Tailscale-User-Loginand mint privileged GUI sessions.Description
trustedTailscaleIngress: falseat GUI-session issuance call sites insrc/server/index.ts.Tailscale-User-Loginrequests are refused and do not create sessions by updatingtests/server-management-auth.test.ts.structure/05_gui-and-management-api.mdanddocs-site/src/content/docs/guides/remote-hub.md(and translations).Testing
NO_PROXY=localhost,127.0.0.1,::1 ./node_modules/bun/bin/bun.exe test tests/server-management-auth.test.ts tests/loopback-listener-integration.test.tsand the changed coverage passed (68 tests across those files passed)../node_modules/bun/bin/bun.exe run typecheckand./node_modules/bun/bin/bun.exe run privacy:scanwhich succeeded.(cd docs-site && ../node_modules/bun/bin/bun.exe install --frozen-lockfile && ../node_modules/bun/bin/bun.exe run build)and the site built successfully.tests/lab-automation-final-coderabbit-regressions.test.ts(existing, environment-sensitive test) which is outside the scope of this security fix.Codex Task