> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Autogen Rules
> Explains Kyverno autogen which generates controller-specific Kubernetes validation rules from a single Pod-focused policy to reduce duplication and simplify image registry enforcement
This article expands on validation policies and introduces Kyverno's autogen feature — a powerful way to automatically generate controller-specific rules from a single Pod-focused policy. Autogen reduces repetition, minimizes errors, and keeps policies maintainable as new controllers or operators are introduced.
Let's follow Alex, a platform engineer who needs to ensure all application images come from the enterprise registry.
Alex’s requirement is simple: validate that container images are pulled only from `registry.domain.com/*`. But developers don't usually create Pods directly.
Instead, workloads are created via Deployments, StatefulSets, DaemonSets, Jobs, CronJobs, and operator-managed resources. Each controller embeds the Pod spec at a different JSON path, so a naive approach requires separate rules for each controller type.
Manual approach (repetitive and error-prone)
Alex starts with a Pod-level validation rule:
```yaml theme={null}
# Validate images when a Pod is created directly
- name: validate-pods
match:
any:
- resources:
kinds:
- Pod
validate:
pattern:
spec:
containers:
- image: "registry.domain.com/*"
```
When targeting controllers that embed Pod templates at `spec.template.spec`, he must create another rule:
```yaml theme={null}
# Validate images for controllers that embed a pod template at spec.template.spec
- name: validate-deployments-statefulsets
match:
any:
- resources:
kinds:
- Deployment
- StatefulSet
- DaemonSet
- Job
validate:
pattern:
spec:
template:
spec:
containers:
- image: "registry.domain.com/*"
```
CronJobs use a different path (`spec.jobTemplate.spec.template.spec`), requiring yet another nearly identical rule:
```yaml theme={null}
# Validate images for CronJobs
- name: validate-cronjobs
match:
any:
- resources:
kinds:
- CronJob
validate:
pattern:
spec:
jobTemplate:
spec:
template:
spec:
containers:
- image: "registry.domain.com/*"
```
Maintaining multiple variants of the same rule quickly becomes tedious. Kyverno’s autogen feature solves this by generating controller-specific rules from a Pod-focused rule.
Autogen: write once, apply everywhere
The core idea: author your policy for the lowest-level resource you care about (Pod). Kyverno will auto-generate the corresponding policies for controllers that create Pods.
Here’s the simplified policy Alex now writes — only targeting Pod objects:
```yaml theme={null}
# Single policy that targets Pods — Kyverno will autogenerate controller-specific rules
- name: validate-registries
match:
any:
- resources:
kinds:
- Pod
validate:
failureAction: Enforce
message: "Images may only come from our internal enterprise registry."
pattern:
spec:
containers:
- image: "registry.domain.com/*"
```
When applied, Kyverno activates autogen and creates equivalent rules for controllers automatically. You can inspect the policy status in-cluster and check `status.autogen.rules` to review what Kyverno generated:
```yaml theme={null}
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: restrict-image-registries
spec:
# ... original Pod-only rule ...
status:
autogen:
rules:
- name: autogen-validate-registries
# ... generated rule for Deployments, StatefulSets, Jobs, DaemonSets, etc. ...
- name: autogen-cronjob-validate-registries
# ... generated rule for CronJobs ...
```
Example generated rules
Kyverno wraps your Pod pattern inside controller-specific paths.
Most controllers (Deployment, StatefulSet, DaemonSet, Job, etc.) get rules that place the Pod pattern under `spec.template.spec`:
```yaml theme={null}
# Example generated rule for most controllers
- name: autogen-validate-registries
match:
any:
- resources:
kinds:
- Deployment
- StatefulSet
- DaemonSet
- Job
# ... other common controllers ...
validate:
message: "Images may only come from our internal enterprise registry."
pattern:
spec:
template:
spec:
containers:
- image: "registry.domain.com/*"
```
CronJobs receive a separate generated rule because their Pod template is nested at `spec.jobTemplate.spec.template.spec`:
```yaml theme={null}
# Example generated rule for CronJobs
- name: autogen-cronjob-validate-registries
match:
any:
- resources:
kinds:
- CronJob
validate:
message: "Images may only come from our internal enterprise registry."
pattern:
spec:
jobTemplate:
spec:
template:
spec:
containers:
- image: "registry.domain.com/*"
```
Controlling autogen behavior
If you need fine-grained control over which controllers receive generated rules, Kyverno exposes the `pod-policies.kyverno.io/autogen-controllers` annotation on the policy.
Examples:
```yaml theme={null}
# Generate rules only for Deployment and Job controllers
pod-policies.kyverno.io/autogen-controllers: "Deployment,Job"
```
```yaml theme={null}
# Disable autogen for this policy; only Pod objects will be validated
pod-policies.kyverno.io/autogen-controllers: "none"
```
When autogen is skipped
Autogen is conservative and will skip generation if the original rule is too specific or otherwise cannot be safely translated to parent controller objects. Scenarios that prevent autogen include:
* Matching a Pod by name (controller resource names differ).
* Using label selectors or annotation filters that apply specifically to Pods and cannot be sensibly applied to controllers.
* The rule’s `kinds` list contains resources other than `Pod` (e.g., `ConfigMap`, `Secret`).
To maximize the chances that autogen runs for your rule:
* Target only `Pod` in the `kinds` list.
* Avoid name-based matches, Pod-specific selectors, or predicates that cannot be translated to controllers.
Quick reference table
| Topic | Behavior / Example |
| ----------------------- | -------------------------------------------------------------------------------------------------------- |
| Author focus | Write the rule for `Pod` (lowest-level object). |
| Autogen default | Kyverno generates rules for common controllers (Deployment, StatefulSet, DaemonSet, Job, CronJob, etc.). |
| Check generated rules | Inspect `status.autogen.rules` in the policy object. |
| Restrict autogen | Use annotation `pod-policies.kyverno.io/autogen-controllers: "Deployment,Job"` |
| Disable autogen | Use annotation `pod-policies.kyverno.io/autogen-controllers: "none"` |
| When autogen is skipped | Name matches, Pod-only selectors/annotations, or `kinds` includes non-Pod resources. |
Autogen simplifies policy management, but always review the generated rules in `status.autogen.rules` to confirm they match your intent — especially when working with custom controllers or operator-managed resources.
Summary
* Problem: Pods are created via many controllers and live at different JSON paths, which used to require multiple, nearly identical rules.
* Solution: Write a single Pod-targeting rule and let Kyverno autogen produce controller-specific rules automatically.
* Customization: Use `pod-policies.kyverno.io/autogen-controllers` annotation to limit or disable autogen.
* Safety: Kyverno skips autogen for rules that are too specific or otherwise cannot be translated to controller resources.
Further reading and references
* Kyverno Documentation — Policies and Autogen (see Kyverno docs for the latest details).
* Kubernetes API conventions and controller patterns:
* [Kubernetes Controllers](https://kubernetes.io/docs/concepts/architecture/controller/)
* [Pod Template spec paths](https://kubernetes.io/docs/concepts/workloads/controllers/)
Using autogen will dramatically simplify your policy set and make it more robust and maintainable.