[Bug] policies with both clone AND mutate rules (with targets set) do not clone

[thesuperzapper]

Kyverno Version

1.11.4

Description

In Kyverno 1.11.4 (and probably others too), if a ClusterPolicy contains both a clone and mutate rule (with targets set), the clone rule in the policy is never applied.

Note the clone rule WILL apply if the mutate rule does not set mutate.targets.

Steps to reproduce:

1. Create some namespaces for the clone:

apiVersion: v1
kind: Namespace
metadata:
  name: source-namespace

apiVersion: v1
kind: Namespace
metadata:
  name: target-namespace-1

2. Create the source resource:

apiVersion: v1
kind: Secret
metadata:
  name: source-secret-1
  namespace: source-namespace
data:
  key1: "dmFsdWUx"
  key2: "dmFsdWUy"

3. Create some other resource to target in the mutate rule:

apiVersion: v1
kind: ConfigMap
metadata:
  name: random-configmap
  namespace: source-namespace
data:
  key1: "value1"
  key2: "value2"

4. Create the ClusterPolicy

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: clone-secret-1-policy
spec:
  generateExisting: true
  rules:
    - name: clone-secret
      match:
        any:
          - resources:
              kinds:
                - Namespace
              names:
                - "target-namespace-1"
      generate:
        apiVersion: v1
        kind: Secret
        name: "target-secret-1"
        namespace: "{{ request.object.metadata.name }}"
        synchronize: true
        clone:
          namespace: "source-namespace"
          name: "source-secret-1"

    - name: random-mutate-trigger
      match:
        any:
          ## match can be any resource, and the issue still occurs
          - resources:
              kinds:
                - Secret
              names:
                - "source-secret-1"
              namespaces:
                - "source-namespace"
      mutate:
        ## targets can be anything (even empty), and the issue still occurs
        targets:
          - apiVersion: v1
            kind: ConfigMap
            name: "random-configmap"
            namespace: "source-namespace"

        ## patch can be anything (even empty), and the issue still occurs
        patchStrategicMerge:
          metadata:
            annotations:
              my_annotation: "{{ time_now_utc() }}"

5. Notice that Secret/target-secret-1 is NOT created in target-namespace-1
6. Trigger the mutate rule by patching its match resource:

apiVersion: v1
kind: Secret
metadata:
  name: source-secret-1
  namespace: source-namespace
data:
  key1: "dmFsdWUx"
  key2: "dmFsdWUy"
  key3: "dmFsdWUz"

7. Notice that ConfigMap/random-configmap was annotated with my_annotation: "2024-01-30T21:50:40Z"
8. Notice that Secret/target-secret-1 is still NOT created in target-namespace-1

Slack discussion

No response

Troubleshooting

• I have read and followed the documentation AND the troubleshooting guide.
• I have searched other issues in this repository and mine is not recorded.

[thesuperzapper]

@chipzoller @realshuting we should either document this as a known issue, or try and fix it in the next release.

It's very common to want a policy that both "clones" a Secret, and also triggers restarts of Deployments that use that secret (listening to updates on the source secret, to avoid the fact that Kyverno ignores its own updates).

But right now (1.11.4), these rules have to be in separate policies, or the clone wont apply.

[realshuting]

You need to set mutateExistingOnPolicyUpdate: true to trigger the second rule on policy creation. Verified with the latest main and it worked as expected.

✗ k get cpol -o yaml | grep mutateExistingOnPolicyUpdate              
    mutateExistingOnPolicyUpdate: true

✗ k get secret -n target-namespace-1
NAME              TYPE     DATA   AGE
target-secret-1   Opaque   2      3s

✗ k get cm random-configmap -n source-namespace -o yaml | grep my_annotation
    my_annotation: "2024-02-01T06:34:13Z"

[thesuperzapper]

@realshuting I am very confused by your response. I think we need to reopen this issue.

The issue is not about whether the mutate rule fires on creation of the policy, it's about the clone rule not firing at all.

Specifically, in 1.11.4 if there is a clone rule in a policy in addition to a mutate rule (with a target defined), then the clone rule does not ever trigger.

Are you saying that this issue has been resolved already?

[realshuting]

I was testing against the latest main and it has no issue cloning the secret. Let me verify on 1.11.x.

[realshuting]

I can confirm that the clone rule in the combined policy doesn't work in 1.11.4.

It looks like the issue has been fixed in main and will be available in 1.12, can you please verify the same?