Migrate the namespace-default generation ClusterPolicies to GeneratingPolicy without a gap #4999

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

Evidence and problem

Kyverno 1.20 is planned to remove ClusterPolicy (#4984). These 4 generation policies in k8s/bases/infrastructure/cluster-policies/best-practices/ create per-namespace defaults; each must exist as a GeneratingPolicy (policies.kyverno.io) before 1.20 is installed:

add-default-deny, add-default-limitrange, add-ns-quota, auto-vpa.

All four use synchronize: true, so Kyverno owns the objects they created in every namespace and keeps them in step. add-default-deny, add-default-limitrange and add-ns-quota have no Kyverno CLI test.

What has to be decided before this is Ready

How the objects the old policies generated pass to the new ones without being deleted and recreated. A synchronised downstream object is tied to the policy that generated it; deleting that ClusterPolicy could remove the default-deny network policy, limit range or quota from every namespace before the new policy recreates it, which is a gap in isolation and in resource limits. Read Kyverno 1.19's documented behaviour for deleting a synchronising generate policy and for a GeneratingPolicy adopting existing objects, and record the safe sequence here (for example, turning off synchronisation on the old policy first, in its own deploy). Then list the PRs that sequence needs.

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

• The handover sequence above is recorded, with its source in the Kyverno documentation.
• Every policy has a CLI test that passed against the ClusterPolicy before the rewrite.
• Each is a GeneratingPolicy with the same scope and generated objects, and the old ClusterPolicy is gone after deploy.
• After every deploy in the sequence, each namespace still has its default-deny network policy, limit range and quota, read from the live cluster; none was deleted and recreated.

Priority High, Effort Medium, Service class Risk reduction. Losing the default-deny policy in every namespace at once is the worst single outcome of the migration; kept in Backlog until the handover is decided. Part of #4984.