Security: worker RBAC grants pods/exec in the control-plane namespace, and the mutation-safety gate is hardwired open

[haasonsaas]

Summary

The worker's Role is scoped to the shared namespace where the API and its secrets live, and the double-opt-in mutation gate is permanently satisfied in the only production deployment.

Evidence

• deploy/kubernetes/worker.yaml:20-27: the worker Role grants create/update/patch/delete plus pods/exec on all pods in sandboxwich — the same namespace as sandboxwich-api and the sandboxwich-secrets Secret. A compromised worker (or an exec-path bug) can kubectl exec into API pods and read SANDBOXWICH_DATABASE_URL.
• deploy/kubernetes/worker.yaml:107-108,117: sets SANDBOXWICH_K8S_ENABLE_MUTATION=1 and passes --confirm-apply, so the gate at provider.rs:857-864 is always open — it's safety theater.

Why it matters

Blast radius: a single worker bug or compromise reaches the database credential and every control-plane pod.

Suggested fix

• Run sandboxes in a dedicated namespace and scope the worker Role there; grant the worker nothing in the control-plane namespace.
• Constrain exec to sandboxwich-* pods (ValidatingAdmissionPolicy or resourceNames-style constraints).

[haasonsaas]

Partially addressed by #90 (merged):

• Sandboxes now render into a configurable dedicated namespace (sandboxwich-sandboxes), and the worker Role/RoleBinding are scoped there with no grants in the control-plane namespace — this removes the pods/exec-in-control-plane-namespace exposure that was the core of this issue.

Remaining follow-up (kept open):

• The mutation-safety gate is still hardwired open in the shipped deploy manifest (SANDBOXWICH_K8S_ENABLE_MUTATION=1 + --confirm-apply in deploy/kubernetes/worker.yaml), so the double-opt-in is always satisfied. Decoupling that (or making it a deliberate, documented production choice) is the residual work here.