Auto-Gen Rules for Pod Controllers

Automatically generate rules for Pod controllers.

Pods are one of the most common object types in Kubernetes and as such are the focus of most types of validation rules. But creation of Pods directly is almost never done as it is considered an anti-pattern. Instead, Kubernetes has many higher-level controllers that directly or indirectly manage Pods, namely the Deployment, DaemonSet, StatefulSet, Job, and CronJob resources. Writing policy that targets Pods but must be written for every one of these controllers would be tedious and inefficient. Kyverno solves this issue by supporting automatic generation of policy rules for higher-level controllers from a rule written for a Pod.

For example, when creating a validation policy like below which checks that all images come from an internal, trusted registry, the policy applies to all resources capable of generating Pods.

 1apiVersion :
 2kind: ClusterPolicy
 4  name: restrict-image-registries
 6  validationFailureAction: enforce
 7  rules:
 8  - name: validate-registries
 9    match:
10      any:
11      - resources:
12          kinds:
13          - Pod
14    validate:
15      message: "Images may only come from our internal enterprise registry."
16      pattern:
17        spec:
18          containers:
19          - image: "*"

Once the policy is created, these other resources can be shown in auto-generated rules which Kyverno adds to the policy under the status object.

 2  autogen:
 3    rules:
 4    - exclude:
 5        resources: {}
 6      generate:
 7        clone: {}
 8        cloneList: {}
 9      match:
10        any:
11        - resources:
12            kinds:
13            - DaemonSet
14            - Deployment
15            - Job
16            - StatefulSet
17        resources: {}
18      mutate: {}
19      name: autogen-validate-registries
20      validate:
21        message: Images may only come from our internal enterprise registry.
22        pattern:
23          spec:
24            template:
25              spec:
26                containers:
27                - image:*
28    - exclude:
29        resources: {}
30      generate:
31        clone: {}
32        cloneList: {}
33      match:
34        any:
35        - resources:
36            kinds:
37            - CronJob
38        resources: {}
39      mutate: {}
40      name: autogen-cronjob-validate-registries
41      validate:
42        message: Images may only come from our internal enterprise registry.
43        pattern:
44          spec:
45            jobTemplate:
46              spec:
47                template:
48                  spec:
49                    containers:
50                    - image:*

This auto-generation behavior is controlled by the annotation.

You can change the annotation to customize the target Pod controllers for the auto-generated rules. For example, Kyverno generates a rule for a Deployment if the annotation of policy is defined as

Kyverno skips generating Pod controller rules whenever the following resources fields/objects are specified in a match or exclude block as these filters may not be applicable to Pod controllers:

  • name (deprecated)
  • selector
  • annotations

Additionally, Kyverno only auto-generates rules when the resource kind specified in a combination of match and exclude is no more than Pod. Mutate rules which match on Pod and use a JSON patch are also excluded from rule auto-generation as noted here.

To disable auto-generating rules for Pod controllers set to the value none.

When disabling auto-generation rules for select Pod controllers, Kyverno still applies policy matching on Pods to those spawned by those controllers. To exempt these Pods, use preconditions with an expression similar to the below which may allow Pods created by a Job controller to pass.

1- key: Job
2  operator: AnyNotIn
3  value: "{{ request.object.metadata.ownerReferences[].kind }}"

Exclusion by Metadata

In some cases it may be desirable to use an exclude block applied to Pods that uses either labels or annotations. For example, the following match and exclude statement may be written, the purpose of which would be to match any Pods except those that have the annotation policy.test/require-requests-limits=skip.

 2  - name: validate-resources
 3    match:
 4      any:
 5      - resources:
 6          kinds:
 7            - Pod
 8    exclude:
 9      any:
10      - resources:
11          annotations:
12            policy.test/require-requests-limits: skip

When Kyverno sees these types of fields as mentioned above it skips auto-generation for the rule. The next choice may be to use preconditions to achieve the same effect but by writing an expression that looks at request.object.metadata.*. As part of auto-generation, Kyverno will see any variables from AdmissionReview such as that beginning with request.object and translate it for each of the applicable Pod controllers. The result may be that the auto-generated rule for, as an example, Deployments will get translated to request.object.spec.template.metadata.* which references the metadata object inside the Pod template and not the metadata object of the Deployment itself. To work around this and have preconditions which are not translated for these metadata use cases, double quote the object portion of the variable as shown below.

 2kind: ClusterPolicy
 4  name: require-requests-limits
 6  validationFailureAction: enforce
 7  background: true
 8  rules:
 9    - name: validate-resources
10      match:
11        any:
12        - resources:
13            kinds:
14              - Pod
15      preconditions:
16        all:
17        - key: "{{ request.\"object\".metadata.annotations.\"\" || '' }}"
18          operator: NotEquals
19          value: skip
20      validate:
21        message: "CPU and memory resource requests and limits are required."
22        pattern:
23          spec:
24            containers:
25              - resources:
26                  requests:
27                    memory: "?*"
28                    cpu: "?*"
29                  limits:
30                    memory: "?*"

The result will have the same effect as the first snippet which uses an exclude block and have the benefit of auto-generation coverage.

Last modified October 11, 2022 at 2:58 PM PST: More 1.8 docs (#643) (571d723)