kubevirt-csi controller has no RBAC for the VMI-level removevolume it falls back to #4452

The kubevirt-csi controller looks like it cannot make the VMI-level hot-unplug call at all, because its role does not allow it. The driver falls back to that call when a volume is no longer in the VM spec, mostly when the VM is deleted before its VMI during a tenant teardown. The call goes to subresources.kubevirt.io virtualmachineinstances/removevolume.

The controller's role covers the VM subresources and nothing on the VMI. The -kcsi Role in packages/apps/kubernetes/templates/csi/infra-cluster-service-account.yaml grants update only on virtualmachines/addvolume and virtualmachines/removevolume. I found no other binding that gives this service account the VMI subresource. KubeVirt's kubevirt.io:default role, bound to system:authenticated, covers only kubevirts, version and guestfs (checked at v1.9.0), and nothing in this repo grants to the system:serviceaccounts group of a tenant namespace. Upstream deploy/infra-cluster-service-account.yaml has the same rule set, so this is not a local omission.

If that holds, every VMI-level fallback today ends in 403 Forbidden. That applies to upstream removeVolumeFromVm and to our wrapper's own call in unpublishHotplugVolume (tracked in #4450). The unpublish then retries and fails, instead of releasing the hot-plug pod the fallback exists for. It also changes the premise of #4032: the VMI-level detach may never have worked here, with or without the HotplugVolumes gate.

This is from reading the code. I have not reproduced it on a cluster. A quick check on a running tenant:

kubectl auth can-i update virtualmachineinstances.subresources.kubevirt.io --subresource=removevolume \
  --namespace <tenant-ns> --as system:serviceaccount:<tenant-ns>:<release>-kcsi

A forbidden line in the controller log during a teardown would confirm it too. If it is confirmed, either add the rule (and report it to kubevirt/csi-driver) or, once #4032 lands and the fallback is off, leave it out on purpose.