Tenant console RBAC reaches ComputePlane worker VMs the tenant has no admin on #4172

Tenant use RBAC reaches the console of ComputePlane worker VMs, which is a cluster the tenant is deliberately given no admin access to.

packages/apps/tenant/values.yaml:25 describes ComputePlane as "a single-tenant, Cozystack-managed cluster for untrusted-code applications. The tenant receives no admin kubeconfig for it." The no-admin-kubeconfig part is the boundary. It does not hold at the console.

ComputePlane deploys the kubernetes app with operator-fixed values into the tenant namespace (packages/apps/tenant/templates/computeplane.yaml:35). Worker VMs come from packages/apps/kubernetes-nodes/templates/nodegroup.yaml:481-484, where the KubevirtMachineTemplate is created in $.Release.Namespace, so CAPK creates the VirtualMachine objects in the tenant namespace too.

cozy:tenant:use:base (packages/system/cozystack-basics/templates/clusterroles.yaml:161-190) grants virtualmachineinstances/console, virtualmachineinstances/vnc and virtualmachines/start|stop|restart with no resourceNames, and packages/apps/tenant/templates/tenant.yaml:51-61 binds it in every tenant namespace. Tenants can reach the API directly: packages/extra/info/templates/kubeconfig.yaml renders a kubeconfig Secret and dashboard-resourcemap.yaml exposes it to view and above, so virtctl console against those nodes needs nothing unusual.

What I have not verified is whether console access converts to root on these nodes. They run Talos, which has no getty and no shell, and whose initramfs is a single Go binary, so the GRUB path that works on a Debian-based guest is not obviously available. That check is the first thing this issue needs.

If it does convert, the prize is not a shell. CAPK injects the Talos machine config through cloudInitConfigDrive, so root on a worker means the ComputePlane cluster's own secrets, on a cluster whose whole premise is that the tenant does not administer it.

What is already true without any of that: virtualmachines/stop and restart let a tenant power-cycle ComputePlane nodes at will. That is a denial of service against their own workloads rather than a boundary crossing, so on its own it is minor.

This predates site-router and is not specific to it. The same blanket grant covers every platform-owned VM that lands in a tenant namespace, which is the general problem tracked separately.

What to do

1. Determine whether GRUB or any other console-reachable path yields root or the machine config on a Talos ComputePlane worker.
2. If it does, decide whether ComputePlane nodes should move out of the tenant namespace, or whether the console grant should be scoped.
3. Either way, state the actual boundary in the ComputePlane design notes, since the current wording implies the tenant cannot reach these nodes at all.