Autogen Rules - KodeKloud

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.

The image outlines a problem titled "The Pod Controller Maze," where Alex's goal is to ensure all container images come from a trusted internal registry, but the challenge is that pods aren't usually created directly and are managed by controllers.

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:

# 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:

# 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:

# 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.

The image explains Kyverno's solution to focus on pods, highlighting the principle of focusing on the lowest-level object and writing policies targeting pods. It suggests that Kyverno will handle complex rules automatically.

Here’s the simplified policy Alex now writes — only targeting Pod objects:

# 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:

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:

# 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:

# 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:

# Generate rules only for Deployment and Job controllers
pod-policies.kyverno.io/autogen-controllers: "Deployment,Job"

# 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).

The image outlines conditions under which Kyverno autogen is skipped, highlighting issues related to names, selectors, and annotations in Kubernetes.

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.

The image explains when autogen is skipped, indicating it works only if the rule's kinds list contains only "Pod" and is disabled for lists with other kinds like "ConfigMap."

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.

The image illustrates a three-step process titled "How It Works" related to creating and adapting policy rules for Kyverno. Each step is numbered and described, focusing on targeting pods, generating necessary rules, and adapting validation paths.

The image contains a summary and key takeaways, highlighting two points: customization options through annotations for controllers and limitations where autogen is skipped based on certain criteria.

Watch Video