Migrate the tenant and organisation validation ClusterPolicies to ValidatingPolicy #4995

🤖 Generated by the Agentic Engineer (interactive Claude Code session)

Evidence and problem

Kyverno 1.20 is planned to remove ClusterPolicy (#4984). These 12 validation policies in k8s/bases/infrastructure/cluster-policies/best-practices/ guard tenants, GitHub organisation management and retirements; each must exist as a ValidatingPolicy (policies.kyverno.io) before 1.20 is installed:

audit-privileged-rbac, restrict-arc-openbao-listener, restrict-arc-retirement, restrict-explicit-dns-records, restrict-github-team-external-identity, restrict-github-team-management, restrict-homepage-service-groups, restrict-tenant-issuer-refs, restrict-tenant-network-policies, restrict-tenant-route-hostnames, restrict-tenant-secret-stores, restrict-unifi-management-policies.

Ten of the twelve already have Kyverno CLI tests; restrict-arc-openbao-listener and restrict-arc-retirement have none.

How every migration batch works

• Test first. Of the 49 ClusterPolicy manifests, 28 are named in no tests/**/kyverno-test.yaml (counted 2026-10-17 by policy name). Before rewriting a policy, add a Kyverno CLI test that pins its current behaviour — at least one resource it must act on and one it must leave alone — and see it pass against the ClusterPolicy. The same test, pointed at the new kind, must pass unchanged in its expected results.
• Keep the action. Each rewritten policy keeps its failure action as recorded in tests/policy-failure-actions.json (Enforce stays Enforce, Audit stays Audit), its match scope and its exclusions.
• No gap in enforcement. Add the new policy and delete the ClusterPolicy in the same PR, so Flux applies the replacement before it prunes the old one. Kinds whose two versions could both act on the same request (mutation or generation) say how double application is avoided.
• Confirm the capability first. For each rule, confirm the replacement kind can express it at Kyverno 1.19.1 (the running version). A rule it cannot express is recorded on Migrate Kyverno ClusterPolicy and Policy before Kyverno 1.20 removes them #4984 and blocks only that policy, not the batch.
• Validate with kyverno test ./tests and scripts/validate-kyverno-fixture-evaluation.sh (CI's ⚖️ Validate cluster policies step), the layer builds in platform/AGENTS.md, and after deploy a read-only check that each new policy reports ready and the old one is gone.

Acceptance criteria

• Every policy listed above has a CLI test that passed against the ClusterPolicy before the rewrite.
• Each is a ValidatingPolicy with the same failure action, scope and exclusions, and the old ClusterPolicy is deleted in the same PR.
• kyverno test ./tests and the fixture-evaluation check pass in CI.
• After deploy, each new policy reports ready and no ClusterPolicy of these names remains.

Priority High, Effort High, Service class Risk reduction. These rules keep tenants inside their boundaries; losing them in a 1.20 upgrade would be silent. Effort includes adding the missing tests, the CEL rewrite, review and one production deploy. No prerequisite; #4994 removes the time pressure but is not required first. Part of #4984.