kyverno: [BUG] A policy is being applied on pods created by Jobs even it is not defined in the policy
Software version numbers
- Kubernetes version: v1.21.5
- Kyverno version: v1.5.8
Describe the bug
When we create a policy to be applied on Pods and Pods created by DaemonSet, Deployment and StatefulSet controllers, e.g. require-pod-probes policy, the policy is still being applied on Pods created by Jobs or CronJobs. We expect that these Pods created by Jobs and Cronjobs are skipped.
To Reproduce Steps to reproduce the behavior:
- Create the require-pod-probes policy
- Create the following example job which starts a pod without livenessProbe and readinessProbe defined
apiVersion: batch/v1
kind: Job
metadata:
name: test-probes-job
spec:
template:
spec:
containers:
- name: test-probes
image: k8s.gcr.io/liveness
args:
- /server
restartPolicy: Never
- Check the events with
kubectl get events --sort-by='{.lastTimestamp}' -w | grep validate-livenessProbe-readinessProbe
- You will see
5s Warning PolicyViolation clusterpolicy/require-pod-probes Rule(s) 'validate-livenessProbe-readinessProbe' failed to apply on resource Pod/default/test-probes-job-6q2p9
5s Warning PolicyViolation pod/test-probes-job-6q2p9 Rule(s) 'validate-livenessProbe-readinessProbe' of policy 'require-pod-probes' failed to apply on the resource
Expected behavior
The policy is not applied on pods created by Jobs and Cronjobs and it should skip them.
Additional context
Sorry if this is not a bug and just our lack of understanding of how kyverno policy works.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 31 (26 by maintainers)
I like this idea!
@prateekpandey14 - can you collaborate with @abhi-kapoor to add this warning in https://github.com/kyverno/kyverno/pull/3272 ?
Right, agreed, but the actual behavior is a nuance here. When a user modifies the autogen behavior to exclude one or more Pod controllers that would otherwise be covered, their expectation is going to be that Pods created by those excluded controllers are allowed but this is false. This is where confusion will arise because their Pod controller will be allowed but the Pods themselves will be blocked. This behavior is not otherwise present. Getting the behavior they want and think they’re getting requires additional modification. This is the point I’m trying to make.
Created https://github.com/kyverno/website/issues/480 for doc updates.