fix(rbac): grant kubevirt-operator pods/resize update for inplace resize

[fl64]

Description

Adds pods/resize: update to the ClusterRole d8:virtualization:kubevirt-operator in templates/kubevirt/virt-operator/rbac-for-us.yaml, next to the existing pods/finalizers: update rule.

virt-operator (SA kubevirt-operator) generates the ClusterRole kubevirt-internal-virtualization-controller and applies it. With the inplace-resize feature landed in 3p-kubevirt (PR #103, feat: impl inplace resize), that generated ClusterRole now includes a pods/resize: update rule (pkg/virt-operator/resource/generate/rbac/controller.go). The inplace-resize controller itself is feature-gated, but the RBAC is applied unconditionally.

Why do we need it, and what problem does it solve?

On any cluster running a 3p-kubevirt build that contains the inplace-resize commit, virt-operator fails to roll out the kubevirt install-strategy:

virt-operator error: unable to update ClusterRole
  kubevirt-internal-virtualization-controller:
  clusterroles.rbac.authorization.k8s.io "kubevirt-internal-virtualization-controller"
  is forbidden: user "system:serviceaccount:d8-virtualization:kubevirt-operator"
  is attempting to grant RBAC permissions not currently held:
  {APIGroups:[""], Resources:["pods/resize"], Verbs:["update"]}

Kubernetes RBAC escalation protection refuses to let kubevirt-operator grant a right it does not itself hold. virt-operator goes into a reenqueue loop; virt-handler / virt-controller stay on the old image; VMs cannot migrate to a new virt-launcher; the kubevirt update is effectively blocked.

This was observed in the virt lab cluster while testing a 3p-kubevirt dev build that included PR #103 — the RBAC gap prevented any rollout until this rule was added.

What is the expected result?

• virt-operator applies the kubevirt-internal-virtualization-controller ClusterRole (including pods/resize: update) without an RBAC escalation error.
• virt-handler DaemonSet and virt-controller Deployment roll out to the new image.
• Existing VMs receive firmware-update-* vmops (Evict) and migrate onto nodes with the new virt-launcher.
• On clusters where the InPlacePodVerticalScaling subresource is absent, the rule is inert (RBAC does not validate subresource existence).

Cross-version safety

pods/resize subresource: alpha in Kubernetes 1.27, beta in 1.29, GA in 1.33. RBAC does not validate subresource existence, so adding this rule is safe on all supported Kubernetes versions — on older clusters where the subresource does not exist the rule simply never matches, and the kubevirt InPlaceResize feature is feature-gated anyway. Verified InPlacePodVerticalScaling is BETA=enabled on the test cluster (v1.33.12).

Checklist

• The code is covered by unit tests.
• e2e tests passed.
• Documentation updated according to the changes.
• Changes were tested in the Kubernetes cluster manually.

Changelog entries

section: core
type: fix
summary: "virt-operator can now roll out kubevirt builds that include the inplace-resize feature; granted the kubevirt-operator service account the pods/resize:update right so RBAC escalation protection no longer blocks the kubevirt-internal-virtualization-controller ClusterRole."
impact_level: low