Repository navigation
Description
🤖 Generated by the Agentic Engineer
Evidence and problem
Two static guards refuse any MutatingPolicy in the production render, by design, because neither can evaluate CEL mutations:
- the Crossplane egress-policy contract rule
reject-cel-policy-producers(scripts/tests/crossplane-egress-policy-rules.yaml) rejects everypolicies.kyverno.ioMutatingPolicy/GeneratingPolicy(only a policy-reportDeletingPolicyis excepted, Prune stale Kyverno results after policies stop matching #2573); scripts/guard-consumer-discovery-conservation.shrefuses a render that holds anyMutatingPolicy,MutatingAdmissionPolicyorGeneratingPolicy, because it cannot prove such a mutation preserves consumer identity.
Measured on #5095 (2026-10-19), the first mutation migration for #4997: the policy itself is correct (its CLI test passes unchanged before and after), but 🧪 Validate Manifests and 🛡️ Validate Repository Guards fail on these two refusals. So none of the eleven mutation policies in #4997 can move to MutatingPolicy before Kyverno 1.20 removes ClusterPolicy (#4984) until the guards can tell a safe mutation from an unsafe one.
Audience and outcome
The platform operator: the mutation defaults keep working across the Kyverno 1.20 upgrade, and the guards keep refusing any mutation that could strip egress policy or change a consumer's identity.
Smallest useful change
Replace each blanket refusal with an allow-list of reviewed shapes, not a list of exceptions: a MutatingPolicy passes only when its matchConstraints.resourceRules name exactly the reviewed kinds (for #5095: helm.toolkit.fluxcd.io helmreleases) and none of the carrier kinds the guards protect, and its mutations are a JSON patch limited to reviewed paths. Everything else stays refused. Each guard keeps its negative controls, plus a new one proving a MutatingPolicy on a protected kind or path is still refused.
Acceptance criteria
- Both guards admit the reviewed HelmRelease CRD-strategy
MutatingPolicyfrom feat(kyverno): migrate helm-release-install-crds to MutatingPolicy #5095 and still refuse aMutatingPolicyon NetworkPolicy/CiliumNetworkPolicy or any other protected carrier kind. - Negative controls for each guard prove the refusal still fires for an unreviewed shape.
- feat(kyverno): migrate helm-release-install-crds to MutatingPolicy #5095 passes CI on top of the change.
Size: medium. Blocks #4997.
Metadata
Metadata
Assignees
Labels
Type
Fields
Projects
- StatusShow more project fields✅ Done
Activity
devantler commentedon Oct 19, 2026
Scope note, 19 October: this also blocks a second started item, and it needs the
GeneratingPolicycase too.Both refusals named above cover
GeneratingPolicyas well asMutatingPolicy, read at platformmain5ed390f:reject-cel-policy-producersinscripts/tests/crossplane-egress-policy-rules.yamlrejectsGeneratingPolicy,MutatingPolicyand everyDeletingPolicyexcept the policy-report one.scripts/guard-consumer-discovery-conservation.shcounts everyMutatingPolicy,MutatingAdmissionPolicyandGeneratingPolicyin a production render and refuses any non-zero count.The next step on devantler-tech/kyverno-policies#1 (item 3) registers the catalog's
auto-vpain the platform. The catalog's registered form ispolicies/best-practices/auto-vpa-generating-policy.yaml: threepolicies.kyverno.io/v1GeneratingPolicyobjects, one each for Deployment, DaemonSet and StatefulSet, that generate aVerticalPodAutoscaler. Once it is in the platform's production render, both guards refuse it for the same reason they refuse #5095 today.Suggested scope addition: the allow-list should name a reviewed
GeneratingPolicyshape as well. That shape matches onlyappsdeployments/daemonsets/statefulsetsand generates onlyautoscaling.k8s.ioVerticalPodAutoscaler, never a carrier kind. Add a negative control that aGeneratingPolicygenerating any protected carrier kind is still refused. If one change is too big, split it into a sibling issue so each guard change is reviewed alone. Either way, one guard change now unblocks two started items: #4997 (through #5095) and kyverno-policies#1.Not picked up in this run: the board is above its WIP ceiling and this is Backlog work that is not a critical obligation.