SECURITY: cloud-api (platform-api) ServiceAccounts are cluster-admin equivalent; dev can act on prod #170

Found by T10a during Agent Automations Phase 2 (2026-10-11), verified read-only by the lead.

Both nan-system/platform-api (prod) and nan-system-dev/platform-api (dev) are bound to ClusterRole nan-platform-admin (bindings nan-platform-admin and nan-platform-admin-dev). The role grants cluster-wide: namespaces CRUD, secrets/serviceaccounts CRUD, pods incl. exec, roles/rolebindings/clusterroles/clusterrolebindings incl. bind and escalate, deployments, jobs, ingresses, CNPG clusters, etc. That is effectively cluster-admin.

kubectl auth can-i --as system:serviceaccount:nan-system-dev:platform-api: get/list secrets in nan-system and security = yes; create pods and serviceaccounts/token in nan-system = yes; delete namespaces = yes; create clusterrolebindings = yes.

Impact today: any compromise of dev platform-api (or the migrate Job / opendata cron sharing the SA) gives full control of prod; an RCE in prod platform-api gives the whole cluster. Phase 2 adds: dev could mint a prod platform-api audience=vault token and decrypt prod member secrets.

Blocks: prod SECRETS_ENABLED=true (AGENT-AUTOMATIONS-PHASE2.md §15 step 4 gate).

Plan:

• Map every Kubernetes API call cloud-api makes (client-go, Helm SDK for member apps, namespaces per member, Spaces, workspaces/agents, CNPG, ingress/middlewares, netpols, quotas) and the namespaces it touches, prod and dev
• Dedicated SAs: separate the API server, the migrate Job and the opendata cron
• Least-privilege RBAC: no bind/escalate on cluster roles; secrets only where needed; dev confined to nan-system-dev and dev member namespaces (naming/label convention)
• Tests pinning the RBAC; staged rollout with dev first and a prod window with the owner's OK