In a Kyverno autogen rule, what replaces spec.containers for a Deployment and for a CronJob?

## The two depths Every Kubernetes workload controller that produces Pods carries a **Pod template**: a copy of a Pod spec that the controller stamps out. The templates sit at two different depths. **One level down** - Deployment, StatefulSet, DaemonSet, Job (and the ReplicaSet layer beneath a Deployment): ``` spec.template.spec.containers[*] ``` **Two levels down** - CronJob, which holds a *Job* template that in turn holds the Pod template: ``` spec.jobTemplate.spec.template.spec.containers[*] ``` That single structural fact explains the whole shape of Kyverno's autogen output. A rule authored against a Pod addresses `spec.containers[*]`. To make the same logic apply to a controller, Kyverno prefixes the paths inside the rule body. Because there are two prefixes, there are two derived rules: - `autogen-<rule>` - match rewritten to the controllers that nest once, paths prefixed with `spec.template.spec` - `autogen-cronjob-<rule>` - match rewritten to CronJob, paths prefixed with `spec.jobTemplate.spec.template.spec` ## What is rewritten and what is carried over Rewritten: - the **match kinds**, from `Pod` to the controller kinds - the **field paths inside the rule body**, so a pattern or a condition that traversed `spec.containers` now traverses the template's container list Carried over unchanged: - the **decision logic** itself - the same containers are examined, the same field is judged, the same verdict is produced - the **message** - one string, authored once, shown to whoever was refused, whatever kind they submitted That asymmetry is worth internalising. Take the control `no container may receive a Secret through env.valueFrom.secretKeyRef or envFrom.secretRef; mount it as a projected volume instead`. The logic travels perfectly. The message does not adapt: if you wrote "remove secretKeyRef from spec.containers", the author of a CronJob reads a path that does not exist anywhere in their manifest, and goes looking for it. Write the message about the *thing* - "mount the Secret as a volume rather than injecting it into a container's environment" - and it reads correctly at every depth. ## Why this is the first thing to check when coverage looks uneven The symptom is specific and common: the rule refuses Deployments exactly as intended, and lets an identical violation through in a CronJob. Two candidate causes, and they are distinguished by reading the policy back from the cluster: 1. **The CronJob variant does not exist.** The controller list was narrowed, so no rule with the `autogen-cronjob-` prefix was derived. Nothing failed; a whole kind is simply outside the rule. 2. **The CronJob variant exists but does not fire.** Then the rule's own logic does not survive relocation to a deeper path - typically because the author hard-coded a path prefix rather than writing against the Pod shape, so autogen prefixed an already-prefixed path. That second failure mode is the argument for the discipline of writing rules **only** at the Pod level and letting autogen do the prefixing. The moment you hand-write `spec.template.spec.containers` into a rule that also matches Pod, you are fighting the rewrite. ## Reading a generated rule When you read the policy back, the derived rules look like ordinary rules: a match block naming controller kinds, and a body whose paths start with the template prefix. There is nothing magical to decode. The two useful checks are: - Does the `autogen-cronjob-` variant exist at all? - In each variant, does the path in the body actually match the shape of that kind - one `template` for the controller variant, `jobTemplate` then `template` for the CronJob one? If both are true, the control covers every workload kind that can produce a Pod, from one authored rule. ## Summary table | Kind | Where the Pod spec lives | | --- | --- | | Pod | `spec` | | Deployment, StatefulSet, DaemonSet, Job | `spec.template.spec` | | CronJob | `spec.jobTemplate.spec.template.spec` | One authored rule, two rewrites, three depths covered.