ValidatingPolicy Autogen#

The autogen system automatically generates ValidatingPolicy variants that cover Pod controllers (Deployments, DaemonSets, StatefulSets, ReplicaSets, Jobs, CronJobs) from a policy written against Pods. It works by rewriting the CEL expression paths in the policy spec from Pod-level (e.g., object.spec.containers) to controller-specific template paths (e.g., object.spec.template.spec.containers).

Key source files:

Path Replacement Mechanism#

Autogen uses two replacement groups, defined in data.go:

• AutogenDefaults (DaemonSets, Deployments, ReplicaSets, StatefulSets, Jobs):
  • object.spec → object.spec.template.spec
  • object.metadata → object.spec.template.metadata
• AutogenCronjobs (CronJobs only):
  • object.spec → object.spec.jobTemplate.spec.template.spec
  • object.metadata → object.spec.jobTemplate.spec.template.metadata

The Replacement.Apply() function rewrites every occurrence of object.<from> and oldObject.<from> in the raw JSON bytes. One protection is in place: paths immediately followed by .namespace (e.g., object.metadata.namespace) are excluded from rewriting to avoid breaking match conditions that reference the workload's own namespace 1.

The full replacement pipeline in generateRuleForControllers:

1. Deep-copy the ValidatingPolicySpec
2. Update MatchConstraints to target the controller resource group
3. Marshal the spec to JSON
4. Apply replacements with autogen.Apply(bytes, autogen.ReplacementsMap[config]...)
5. Unmarshal back into the spec

This rewrites all paths found inside spec.matchConditions, spec.validations, spec.variables, and spec.auditAnnotations — everything encoded in the policy spec.

Autogen Flow in the Reconciler#

In reconciler.go, for each policy reconcile cycle:

1. Fetch all matching PolicyException objects 2
2. Compile the original (Pod-level) policy with those exceptions 3
3. Generate autogen variants via autogen.Autogen(policy) 4
4. Compile each autogen variant by calling r.compiler.Compile(autogenPolicy, exceptions) with the same unmodified exception list 5

Known Gap: PolicyException matchConditions Are Not Transformed#

The problem: PolicyException.Spec.MatchConditions are compiled verbatim from the original exception object — they are never passed through the JSON replacement step.

Because exceptions are a separate CRD fetched at reconcile time and passed directly to Compile(), their CEL expressions bypass autogen.Apply(). The compiler compiles exception match conditions as-is 6. When an autogen variant for, say, a Deployment is evaluated, its exception match conditions still reference Pod-level paths like object.spec.containers[0].image, which do not exist on a Deployment object. The result is evaluation failure or incorrect exception matching for controller resources.

What is and isn't transformed:

Workaround: Write PolicyException matchConditions to handle both Pod-level and controller-level paths, using conditional expressions like object.kind == 'Pod' ? object.spec.containers : object.spec.template.spec.containers.

Comparison: mpol vs vpol Autogen#

PR #14208 (merged 2025-10-29) fixed an analogous gap in MutatingPolicy autogen — specifically, it added explicit iteration over spec.MatchConditions and applied convertPodToTemplateExpression to each expression 7. The same fix was also applied to metadata path translation in mpol.

The vpol autogen does not have an equivalent fix. It relies entirely on the JSON-level byte replacement, which covers spec-level fields but cannot reach PolicyException objects that are injected externally.

💡 If implementing a fix, the pattern from mpol/autogen/autogen.go (post-PR #14208) is the reference: iterate exception match conditions and apply the appropriate Replacement for the target controller type.