Migrate require-baseline-workers-for-hcloud-volumes to ValidatingPolicy #5150

🤖 Generated by the Agentic Engineer

Evidence and problem

Part of the Kyverno 1.20 migration (#4996): require-baseline-workers-for-hcloud-volumes is still a ClusterPolicy, which Kyverno 1.20 removes. It is one of the last three policies in the epic still on the old kind, and nobody has picked it up yet.

The policy refuses a Pod that mounts an hcloud volume unless the Pod is pinned to the fixed baseline workers. An hcloud volume is not released when its node goes away, so a volume on an autoscaled node gets stuck when that node is reclaimed (this froze the production merge queue for about nine hours on 1 July). It runs in Enforce, with an Audit companion that reports any claim whose storage class could not be read.

It is the only policy in the epic that looks something up in the cluster at admission time (the storage class of each mounted claim). The epic asks to confirm the new kind can express every rule before rewriting it. Checked on 21 October with the Kyverno 1.19.1 CLI: a ValidatingPolicy can read claims through resource.List, and the CLI test can supply those claims from a Context file, so the existing test can keep pinning the same cases.

Smallest useful change

1. Rewrite the Enforce rule as one ValidatingPolicy with the Deny action, failurePolicy: Ignore, Pods on create only, no controller autogen, and with background evaluation on (as the ClusterPolicy has today). It reads the namespace's claims once and keeps the same pinning rules: a prod-worker-* node name, the baseline-worker node selector, or every required node-selector term carrying the baseline-worker label or prod-worker-* hostnames only.
2. Keep the Audit companion as its own ValidatingPolicy with the Audit action: it reports a mounted claim that does not exist in the namespace, so a missing lookup stays visible instead of passing silently.
3. Move the existing CLI tests (hcloud claims and the Longhorn claim fixture) from mocked values to a claim Context file, with the same allow/deny outcome for every pinned case, and add a missing-claim case for the Audit policy.
4. Delete the ClusterPolicy in the same change and record both policies by name in the failure-action baseline (Enforce and Audit).

Acceptance criteria

• The CLI tests pass against the new kind with the same outcome for every pinned case, including the Longhorn-claim and no-claim cases.
• The failure-action baseline records the Enforce policy and the Audit companion with their current actions.
• kyverno test ./tests and the fixture-evaluation check pass in CI.
• A read-only evaluation against the Pods running in production shows no Pod newly denied.
• After deploy, both new policies report ready and no ClusterPolicy of the old name remains.

Priority High, Effort Low (one policy, its tests, one deploy). Service class Risk reduction, inherited from #4996.