Privileged initContainers bypass a containers-only validate rule
Kyverno 1.12 runs with autogen enabled. A ClusterPolicy named disallow-privileged matches Pods and denies a Pod when any entry in spec.containers has securityContext.privileged: true. The rule uses a single JMESPath filter over spec.containers and an operator GreaterThan 0 on its length. During a review, a Deployment with a privileged initContainer is admitted, and a Pod created with kubectl debug using an ephemeral container also bypasses the check. The policy is set to Enforce. A developer argues that Kyverno autogen should have covered the Deployment. Existing Pods report pass in PolicyReport. You need to close both bypasses without duplicating the whole policy for every controller kind and without breaking the existing deny message.
1. Why did the Deployment with a privileged initContainer pass even though autogen is enabled?
Read the worked answer
Autogen is working, but it only copies the logic that is in the Pod rule. The rule filters spec.containers; the autogen rule for a Deployment filters spec.template.spec.containers. It does not add a check for initContainers or ephemeralContainers. The Deployment therefore passes because none of its regular containers is privileged. The generated rule is present; the report shows pass because the condition is false. To confirm, inspect kubectl get clusterpolicy disallow-privileged -o yaml and look for the autogen-* rules. This is a policy-writing gap, not an autogen failure.
2. Rewrite the validate block to cover containers, initContainers, and ephemeralContainers using foreach, and explain how autogen handles it.
Read the worked answer
Use foreach over each container list and deny when element.securityContext.privileged is true. The fallback to false handles containers with no securityContext.
validate:
failureAction: Enforce
message: 'Privileged containers are not allowed.'
foreach:
- list: 'request.object.spec.containers'
deny:
conditions:
any:
- key: '{{ element.securityContext.privileged || `false` }}'
operator: Equals
value: true
- list: 'request.object.spec.initContainers'
deny:
conditions:
any:
- key: '{{ element.securityContext.privileged || `false` }}'
operator: Equals
value: true
- list: 'request.object.spec.ephemeralContainers'
deny:
conditions:
any:
- key: '{{ element.securityContext.privileged || `false` }}'
operator: Equals
value: true
Autogen rewrites Pod spec paths for controllers, so a Deployment rule evaluates spec.template.spec.containers, spec.template.spec.initContainers, and the other lists in the generated rule. For ephemeral containers, remember that they are added through the pods/ephemeralcontainers subresource, not at Pod CREATE. A CREATE-only rule will not see that request. Include UPDATE operations and confirm that the Kyverno webhook configuration matches the subresource in your installed version; without that, the rule logic is correct but never receives the admission request.
3. What test cases would you add to kyverno test to prevent regression?
Read the worked answer
Add at least five cases: a Pod with a privileged regular container must fail; a Pod with a privileged initContainer must fail; a Pod with a privileged ephemeralContainer sent as an UPDATE must fail if the CLI and webhook cover that subresource; a Deployment with a privileged initContainer must fail through the autogen rule; and a Pod with no securityContext or with privileged: false must pass. Reference the exact policy and rule names in expected results, including the autogen- rule name where appropriate. Run the pure Pod cases in the fast CLI gate and run the controller and subresource cases in an ephemeral cluster with Kyverno 1.12 so autogen and the webhook configuration are exercised, not just the rule text.