Architectural rule (confirmed 2026-04-14)

The console running on a cluster is not supposed to give anyone elevated access to the cluster via the pod ServiceAccount. It is supposed to work just like localhost: each user brings their own kc-agent + kubeconfig for their own use — not shared. As long as GPU reservation continues to work, it is fine to break in-cluster functionality for users who don't have a local kc-agent.

Pod SA may only be used for:

1. Bootstrapping the console as a Deployment (frontend + internal console state).
2. GPU reservation exception — namespace create + ResourceQuota create/update/delete (namespaces.go GPU path, mcp_resources.go ResourceQuota handlers).
3. Self-upgrade exception — self_upgrade.go patching its own Deployment.

Every other k8s operation against a managed cluster MUST go through kc-agent at LOCAL_AGENT_HTTP_URL / LOCAL_AGENT_WS_URL (ws://127.0.0.1:8585), which loads the user's kubeconfig and respects per-cluster RBAC automatically via the apiserver.

This was originally filed (from #7979) as a narrow CheckCanI SSAR identity bug. The audit revealed it's an architectural migration gap — some handlers already route through kc-agent, many don't. CheckCanI is a symptom, not the disease.

Phase 0 audit — violation inventory

pkg/api/handlers/ call sites (mutating or dynamic)

Frontend call sites to migrate

• `hooks/useWorkloads.ts` (deploy, scale, delete)
• `hooks/useUsers.ts` (service accounts, bindings)
• `hooks/useMCS.ts` (service exports)
• `hooks/useArgoCD.ts` (sync, applicationsets, detect-drift)
• `components/gitops/SyncDialog.tsx` (sync, detect-drift)
• `components/namespaces/{CreateNamespaceModal,NamespaceManager,GrantAccessModal}.tsx`
• `hooks/mcp/storage.ts` — ResourceQuota paths KEEP (GPU)
• `hooks/useCachedData.ts` — GPU health cronjob → MIGRATE
• `components/drilldown/RemediationConsole.tsx` — MCP ops tools (per-tool review)

kc-agent coverage gaps (new routes needed in `pkg/agent/server.go`)

kc-agent currently has only one mutating k8s route: `POST /scale`. All below need to be added:

• `POST /workloads/deploy` (bundle create — replaces `DeployWorkload`, ~400 LOC port)
• `POST /workloads/delete`
• `POST/DELETE /namespaces` (general create/delete)
• `POST/DELETE /rolebindings` (namespace access grant/revoke + rbac.CreateRoleBinding)
• `POST /serviceaccounts`
• `POST/DELETE /serviceexports` (mcs)
• `POST /gitops/helm-{rollback,uninstall,upgrade}` (new shell-out handlers)
• `POST /gitops/detect-drift` + `POST /gitops/sync`
• `POST /argocd/sync`
• `POST /gpu-health-cronjob` (install/uninstall — MIGRATE classification)
• `POST/PUT/DELETE /console-cr/*` (ManagedWorkload, ClusterGroup, WorkloadDeployment)
• Optional: `POST /node-label` for `kubestellar.io/group` patches

Phase plan (refined against real scope)

Closes on merge

This issue + #5406 (exec backend handler documented limitation — deleted in Phase 3d).

Expected user-visible effect

In-cluster users without a local kc-agent lose destructive operations as each phase lands. This is the stated architectural intent. GPU reservation continues to work throughout (the only pod-SA path for user-initiated action). Local-mode users are unaffected because the backend falls through to `~/.kube/config` which is what kc-agent uses anyway.

Status

• Phase 0 audit: complete (this issue body)
• Phase 1: awaiting user green-light to launch