Pod Controller Autogen

## What is happening Kyverno rules are written against a resource *shape*. A validate rule that says `no container may take a Secret through env.valueFrom.secretKeyRef or envFrom.secretRef - mount it as a projected volume instead` naturally reads `spec.containers[*]`, because that is where containers live **in a Pod**. But almost nobody applies bare Pods. They apply a Deployment, a StatefulSet, a Job, a CronJob. In those objects the same container list is buried one or two levels deeper, under a Pod *template*. A rule written literally against `spec.containers` would simply not match those objects. Kyverno solves that with **Pod controller auto-generation** ("autogen"). When a rule matches kind `Pod`, Kyverno derives additional rules for the workload kinds that carry a Pod template, and rewrites the paths inside them so the same logic lands on the template. ## The generated rules For a rule you named `no-secret-env`, Kyverno derives: - `autogen-no-secret-env` - matching the controller kinds that nest the template once, with paths rewritten to `spec.template.spec.…` - `autogen-cronjob-no-secret-env` - matching CronJob, whose template is nested twice, with paths rewritten to `spec.jobTemplate.spec.template.spec.…` The CronJob variant is separate precisely because its nesting depth is different; one rewrite could not serve both. These generated rules are not written back into the spec you applied. They appear when you read the policy back from the cluster, recorded on the policy alongside the rule you authored. That read-back is the single most useful debugging habit on this feature: **what the cluster enforces is the generated set, not the YAML in your repository**. ## Why it matters for the person who was blocked A developer submits a Deployment at 5pm and the API server refuses it, quoting a rule name they have never seen - something prefixed `autogen-`. They search the policy repository for that name and find nothing, because the name exists only in the derived copy. Knowing that the prefix means "derived from a Pod rule, look for the un-prefixed name" turns a confusing rejection into a two-minute fix. The message they read is the message the policy author wrote once, against the Pod shape. If that text names a Pod field path, it will look wrong to someone holding a Deployment. Kind-agnostic wording - "mount the Secret as a volume; do not inject it into a container's environment" - survives the copy; "fix spec.containers[0].env" does not. ## What autogen does not do - It does not stop the original rule from applying to bare Pods. The rule you wrote still matches `Pod` directly; the generated rules only add the controller kinds. - It does not merge your rule with anything. If you *also* keep a hand-written rule that matches Deployment for the same control, both will match a Deployment and both will report - that is where duplicate denial messages come from. - It is not unconditional. The annotation `pod-policies.kyverno.io/autogen-controllers` on the policy narrows the set of controller kinds, and the value `none` switches generation off entirely, leaving only bare Pods covered. A narrowed value is a silent coverage gap: nothing fails, a whole workload kind is simply outside the rule. ## Writing with autogen in mind The practical consequences for an author are small but real: 1. **Write the rule once, against Pod.** Do not pre-empt autogen by adding controller kinds to the match block and hand-writing template paths; you end up maintaining the copies autogen would have derived. 2. **Write messages that make sense for any workload kind**, because one message string is what every refused author reads. 3. **Read the policy back after applying it**, and confirm the generated rules you expected exist - especially the CronJob variant, which is the one most often missing. 4. **Treat the annotation as part of the policy's meaning.** Someone narrowing it later removes coverage without changing a single line of rule logic. ## The short version One rule, written at the Pod level, becomes several rules at enforcement time so it can follow the Pod template into every object that carries one. The refusal your Deployment hit came from one of those derived copies.