docs(architecture): Tailscale-native fleet access + NATS hub design blueprint - #1831
Conversation
…lueprint Maps Tailscale's official AI-infrastructure access pattern (tagged infra + deny-by-default grants + per-tenant tags + service sidecars) onto PMOVES, as a staged blueprint. Keystone = tag the fleet as infrastructure, which fixes the owner-SSH-check issue idiomatically (tagged nodes leave autogroup:self), ends server re-auth churn, and is the prerequisite for real multi-tenant isolation. Captures the 2026-06-16 decision: NATS is a DEDICATED HUB (separate concern), kept on its working host-publish + tailnet-bind path; net-new services (JuiceFS, inference) use Tailscale sidecars + tags (hybrid), which sidesteps the internal-network/DNAT bug class that #1824 worked around. pmoves_bus_pub (the earlier dedicated-published-network idea) is dropped in favor of the hub + sidecars. No live changes — execution is staged (SSH stopgap #1828 → tag fleet → acls→grants → sidecar JuiceFS/inference → onboard tenants). Companion to #1828 and the NATS restoration PRs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Warning Review limit reached
More reviews will be available in 51 minutes and 49 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughAdds ChangesFleet Access & NATS Hub Architecture Blueprint
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![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: 4407f2b40b
ℹ️ 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".
…sole-only The "no gitops-apply / apply manually" caveat was wrong. PR #1832 wires tailscale/gitops-acl-action (test-on-PR diff, apply-on-merge); the policy can also be applied via the Tailscale API. Allowlist done; TS_TAILNET secret pending. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…networking for sidecars Codex P2 x2: - The rollout references tag:hub/tag:storage/tag:inference but those are not in tagOwners; Tailscale rejects an auth key advertising an undefined tag, so the staged re-enroll would block. Add a note to define them in tailscale-acl-policy.json tagOwners first. - The sidecar example left TS_USERSPACE at its Docker default (userspace), which only handles inbound port-forwards; outbound MagicDNS/100.x from the shared namespace needs kernel networking. Add TS_USERSPACE=false + /dev/net/tun. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…erge) (#1832) * ci(tailscale): gitops sync for the ACL policy (test on PR, apply on merge) Makes pmoves/configs/tailscale-acl-policy.json the source of truth for the tailnet and applies it automatically via the official tailscale/gitops-acl-action — closing the "no gitops-apply, apply manually in the console" gap (the wording in the SSH-fix PR #1828 / fleet-access doc #1831 was wrong to call it manual-only). - PR touching the policy → `test` (validate + diff vs live tailnet, no changes). - push to main → `apply` (push the policy to the tailnet). Action SHA-pinned to v1.5.2 (5a4a17f) per the repo's third-party-action convention. Operator prerequisites (until done, the job no-ops/fails — documented in-file): 1. Allowlist tailscale/gitops-acl-action in Settings → Actions (third-party actions require explicit allowlisting; its internal actions/setup-go is first-party). 2. Add TS_TAILNET secret; TAILSCALE_API_KEY already exists. OAuth client (acl:write, tag:ci) preferred over a 90-day API key for durable CI. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(ci): use correct secret name TAILSCALE_APIKEY (no underscore) The repo secret is TAILSCALE_APIKEY, not TAILSCALE_API_KEY. (deploy-gateway-agent.yml references the wrong name too — pre-existing, tracked separately.) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * ci(tailscale): split into PR-lint + apply-on-merge via Prod environment TS_TAILNET lives in the protected Prod environment (wait_timer + protected-branch policy), so the live-diff gitops `test` can't run on PR feature branches. Restructure: - validate (PR): lint the policy JSON locally, no secrets / any branch. - apply (push to main): tailscale/gitops-acl-action `apply` with environment: Prod (reads TS_TAILNET; TAILSCALE_APIKEY is repo-level). Matches the repo's environment-scoped secret convention (sync-secrets-*). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
1 participant
Maps Tailscale's official AI-infrastructure access pattern (tagged infra + deny-by-default grants + per-tenant tags + service sidecars) onto PMOVES, as a staged blueprint — no live changes.
Highlights
autogroup:self→ fixed by construction), server re-auth churn (tagged = key-expiry disabled), and no basis for tenant isolation (grants target tags).NATS_BIND=tailnet path.pmoves_bus_pub(the earlier dedicated-published-network idea) is dropped.acls→ grants, deny-by-default, with a concrete per-tenanttag:tenant-*/group:tenant-*-usersmodel that maps onto existingtag:partner/tag:guest.Staged rollout
acls→grants → 4. sidecar JuiceFS/inference → 5. onboard tenants.Companion to #1828 and the NATS restoration PRs (#1813/#1824/#1826/#1830). Execution steps (re-tagging every node, applying ACL/grants) are operator-gated and outward-facing — this doc is the reviewable plan.
🤖 Generated with Claude Code
Summary by CodeRabbit