Software Environment

• Kubernetes version: 1.19.9
• Kubernetes platform: kOps in AWS EC2
• Kyverno version: 1.5.0

Description

For a ClusterPolicy that lacks a “pod-policies.kyverno.io/autogen-controllers” annotation with value “none”—meaning that the annotation isn’t present in my Kubernetes manifest at all—Kyverno repeatedly updates the ClusterPolicy object, incrementing the generation and changing the resource version, presumably due to writing to the “spec.rules” field.

Reproduction

Steps to reproduce the behavior:

1. Create a ClusterPolicy that never mentions any of the following API kinds: Pod, DaemonSet, Deployment, Job, StatefulSet, or CronJob. In my case, it only matches a custom resource.
2. Omit the “pod-policies.kyverno.io/autogen-controllers” annotation from the Kubernetes manifest used to create the object.
3. Apply the manifest and confirm that the ClusterPolicy object exists.
   Use a reconciling agent like Flux that will fight back in an “edit war.”
4. Watch the object for changes.
5. Observe that each time Flux detects that the object has changed, Flux patches the object, then Kyverno updates the object again immediately afterward, such that the generation increases by two.
6. Inspect the managed fields on the object.
   Note that Kyverno “owns” the “spec.rules” field.

  managedFields:
  - apiVersion: kyverno.io/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:labels:
          f:bisontrails.co/owner: {}
          f:kustomize.toolkit.fluxcd.io/name: {}
          f:kustomize.toolkit.fluxcd.io/namespace: {}
      f:spec:
        f:background: {}
    manager: kustomize-controller
    operation: Apply
    time: "2021-11-10T16:00:06Z"
  - apiVersion: kyverno.io/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:spec:
        f:rules: {}
      f:status:
        .: {}
        f:ready: {}
    manager: kyverno
    operation: Update
    time: "2021-11-10T16:00:06Z"

1. Add the “pod-policies.kyverno.io/autogen-controllers” annotation to the object with value “none.”
   Include this annotation in the manifest that Flux applies.
2. Observe that Kyverno stops updating the object, and therefore so does Flux.

Expected Behavior

Kyverno should not write to the “spec.rules” field of a ClusterPolicy that doesn’t involve any of the API kinds covered by automatic rule generation. Even with that feature enabled for this object, Kyverno should not write any changes to the “spec.rules” field, as there’s nothing there that needs to change.

The user should not need to disable the automatic rule generation feature just to get Kyverno to stop updating the object needlessly.

Despite trying many times, I have not been able to catch the ClusterPolicy in the state written by Flux for comparison against the state written by Kyverno, so I can’t tell how they differ, if they even do differ. Flux uses SSA for its patching, so it may be that it notices that the managed fields no longer claim that it’s the owner of the “spec.rules” field, and it’s reacting to that loss.

Additional Context

I brought up this problem in two Slack discussions:

• “kyverno” channel of the “Kubernetes” Slack workspace
• “flux” channel of the CNCF Slack workspace