Auto-Gen 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 : kyverno.io/v1
2kind: ClusterPolicy
3metadata:
4 name: restrict-image-registries
5spec:
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: "registry.domain.com/*"
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.
1status:
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: registry.domain.com/*
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: registry.domain.com/*
This auto-generation behavior is controlled by the pod-policies.kyverno.io/autogen-controllers annotation.
You can change the annotation pod-policies.kyverno.io/autogen-controllers 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 pod-policies.kyverno.io/autogen-controllers=Deployment.
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)selectorannotations
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 pod-policies.kyverno.io/autogen-controllers 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.
1rules:
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.
1apiVersion: kyverno.io/v1
2kind: ClusterPolicy
3metadata:
4 name: require-requests-limits
5spec:
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.\"policy.test.io/require-requests-limits\" || '' }}"
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.