A Kyverno Pod rule blocks Deployments, but the same violation in a CronJob is admitted. Why?

## The shape of the failure This is the most instructive failure mode in Kyverno's autogen, because **nothing goes wrong**. No error, no warning, no failed request. A control that everyone believes is universal is quietly absent for one workload kind, and the only evidence is the absence of a rejection that should have happened. Take the control: `no container may receive a Secret through env.valueFrom.secretKeyRef or envFrom.secretRef; mount it as a projected volume instead`. Deployments carrying `secretKeyRef` are refused all day. A nightly CronJob doing exactly the same thing is admitted, has been for months, and nobody noticed because admitted requests produce no artefact to notice. ## The usual cause The policy carries an annotation: ``` pod-policies.kyverno.io/autogen-controllers: Deployment,StatefulSet ``` That annotation narrows which controller kinds Kyverno derives rules for. With that value, `autogen-<rule>` covers Deployment and StatefulSet, and no `autogen-cronjob-<rule>` is derived at all. Set the annotation to `none` and no derived rules exist at all - only directly submitted Pods are covered, which in most clusters is close to nothing. These narrowings are rarely malicious and rarely recent. They get added when a policy is first written - copied from an example, or added to keep the derived set small - and then survive every later review because the rule *logic* looks complete and correct. The annotation is metadata; reviewers read the rule. ## Diagnosis, in order 1. **Read the policy back from the cluster, not from the repository.** The repository holds what you authored; the cluster holds the derived set that is actually enforced. List which derived rules exist. If there is no rule prefixed `autogen-cronjob-`, you have your answer immediately. 2. **Read the annotation on the policy.** A narrowed list or `none` explains a missing variant outright. 3. **If the CronJob variant does exist**, the gap is not coverage but logic: the rule body does not survive relocation to the deeper `spec.jobTemplate.spec.template.spec` path - usually because a path prefix was hand-written into a rule that also matches Pod. 4. **Check the match and exclude blocks** for a namespace or label restriction that happens to exclude where the CronJobs run. That is a different gap with the same symptom, and it is worth eliminating before you blame autogen. ## Fixing it properly The tempting fix is to hand-write a CronJob rule. Resist it. It closes exactly one hole, leaves Job and DaemonSet open if they were also excluded, and adds a second rule to keep in sync with the first - so the next person changing the control changes one of them. The correct fix is to widen or delete the annotation, apply, and then **verify by reading the derived set back**. Verification is not optional here: the whole point of this failure is that the authored YAML looked right the entire time. ## The part that is not technical Once the gap is closed, two questions follow, and a senior engineer is expected to raise them without being asked. **What went through while it was open?** The rule was not enforcing for that kind, so no record of a decision exists for those workloads. You have to establish current state directly - which CronJobs are injecting Secrets as environment variables today - and treat that as the remediation backlog. "The policy was in place" is not an answer, because for that kind it was not. **How does the same gap get caught next time?** The durable answer is that the derived rule set, not the authored rule, is what gets reviewed - and that any narrowing annotation has to be argued for in the change that introduces it, with the excluded kinds named. A narrowing that exists for a reason and says so is fine. A narrowing nobody can explain is a hole with an explanation attached. ## Why this generalises Every gate has a configuration surface separate from its logic - what it matches, where it applies, which kinds it was derived for. Reviewing the logic while ignoring the surface is how controls end up covering less than everybody believes. Autogen just makes the lesson unusually crisp, because the missing coverage is a single word in an annotation and the symptom is nothing at all.