fix: separate ServiceAccount for router workloads

[ambient-code]

Summary

• Creates a dedicated router-sa ServiceAccount with zero RBAC bindings and automountServiceAccountToken: false for router workloads
• The controller keeps its existing controller-manager SA with full RBAC (secrets CRUD, CRD access, leader election)
• Updates both Helm chart templates and operator Go code to ensure consistency across deployment methods

Fixes #351

Changes

Helm chart

• rbac/service_account.yaml: Split into controller-manager (controller) and router-sa (router)
• rbac/role_binding.yaml, leader_election_role.yaml, leader_election_role_binding.yaml: Updated labels from jumpstarter-router to jumpstarter-controller
• router-deployment.yaml, additional-router-deployment.yaml: Use router-sa with automountServiceAccountToken: false

Operator

• rbac.go: Added createRouterServiceAccount() and reconciliation logic for the router SA
• jumpstarter_controller.go: Updated createRouterDeployment() to use {name}-router-sa with automountServiceAccountToken: false

Test plan

• Verify go build ./... passes for the operator (confirmed locally)
• Deploy with Helm and verify router pods use router-sa with no token mounted
• Verify controller pods still use controller-manager SA with full RBAC
• Verify the secrets-job still runs correctly with controller-manager SA
• Run e2e tests to confirm no regressions

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 3ae7064c-021c-40ea-842a-33dcbcf63ca4

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/351-separate-service-accounts

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[netlify]

✅ Deploy Preview for jumpstarter-docs ready!

Name	Link
🔨 Latest commit	8de3816
🔍 Latest deploy log	https://app.netlify.com/projects/jumpstarter-docs/deploys/69d68fb36efdb500083de8f7
😎 Deploy Preview	https://deploy-preview-433--jumpstarter-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[mangelajo]

do not modify any helm, it has been deprecated.

[ambient-code]

Status Update

Review feedback addressed

• @mangelajo's comment (Helm charts are deprecated): Reverted all 6 Helm chart template changes in commit 8bc4c6d. Only the operator deployment path (rbac.go, jumpstarter_controller.go, config/rbac/role.yaml) retains the separate router-sa ServiceAccount logic.

CI failures analysis

The following CI jobs failed:

• deploy-kind (helm): Router pod failed to connect on port 8083 (timed out after 120s). This was likely caused by the Helm chart referencing the new router-sa ServiceAccount which may not have been created correctly. The revert of Helm changes should fix this.
• deploy-kind (operator): Operator e2e test timed out at 600s waiting for a condition — needs re-run to confirm whether the operator-side changes work correctly after the Helm revert.
• e2e-tests (ubuntu-24.04, ubuntu-24.04-arm): Router pod jumpstarter-router-0 timed out waiting for ready condition — same root cause as the Helm deploy failure.
• e2e-compat-old-client: Likely cascading from the same router startup issue.

The Helm chart revert should resolve the helm-path failures. The operator-path changes (separate router-sa with automountServiceAccountToken: false) remain intact and should be validated on the next CI run.

[ambient-code]

Root cause of CI failure

The router pod (jumpstarter-router-0) was timing out because it could not access the Kubernetes API at startup.

The router's main.go calls ctrl.GetConfigOrDie() and then LoadRouterConfiguration(), which reads the jumpstarter-controller ConfigMap from the K8s API. With AutomountServiceAccountToken: false set on both the ServiceAccount and pod spec, no service account token was mounted into the pod, so the in-cluster config had no credentials and the router crashed immediately on startup.

Fix

1. Removed AutomountServiceAccountToken: false from both the router ServiceAccount definition and the router pod spec, so the SA token is mounted and the router can authenticate to the K8s API.

2. Added a minimal RBAC Role ({name}-router-role) granting read-only access to configmaps and secrets — the only resources the router needs to read its configuration and secret keys.

3. Added a RoleBinding ({name}-router-rolebinding) binding the router Role to the {name}-router-sa ServiceAccount.

This maintains the security goal of separating the router SA from the controller SA (the router SA has far fewer permissions than the controller SA) while providing the minimum permissions the router actually needs.

[ambient-code]

CI Fix: Router ServiceAccount needs K8s API access

Root cause: The router process calls ctrl.GetConfigOrDie() and LoadRouterConfiguration() at startup, which reads the jumpstarter-controller ConfigMap from the Kubernetes API. Setting AutomountServiceAccountToken: false on both the ServiceAccount and pod spec prevented the router from authenticating to the K8s API, causing it to crash immediately (180s ready timeout in CI).

Fix (commit 93ce272):

• Removed AutomountServiceAccountToken: false from both the router ServiceAccount and pod spec
• Added a minimal Role granting read-only access to configmaps and secrets (the resources the router actually needs)
• Added a RoleBinding to bind the new Role to the router ServiceAccount
• Added reconciliation logic for the new Role and RoleBinding

This maintains the security separation goal — the router SA has far fewer permissions than the controller SA — while granting the minimum permissions the router actually needs to function.

[mangelajo]

does the router really need to get/list/watch secrets? why?

[ambient-code]

Good catch — you're right, it doesn't. Looking at LoadRouterConfiguration in controller/internal/config/config.go, the router only calls client.Get() on a ConfigMap (jumpstarter-controller), and LoadGrpcConfiguration just parses the in-memory config struct without any K8s API calls. The router never reads secrets.

I'll remove the secrets permission from the router Role so it only has get/list/watch on configmaps.