violations from monitor mode is missing when the policy is moved from monitor to protect mode.

[venkateshjayagopal]

Is there an existing issue for this?

• I have searched the existing issues

Environment

- OS: Ubuntu
- Architecture: x86
- Cluster: RKE2

Issue Description

• Expected behavior: violations should be reported even if there is any transition in policy modes
• Current behavior: violations are missed when moved from monitor to protect mode
• Steps to reproduce:

1. Create a workload,
2. Promote the WPP to monitor mode
3. Patch the WP to workload (Wait for the workload pods to restart)
4. Now execute random process inside the workload.
5. Immediately move the policy to protect mode using kubectl-runtime policy protect command
6. Check the workload CR to see the violations.
7. Observed the stats are incrementing but the violations are missed.
8. In below we can observe violationsID 4,5,7, and 8 are missing. But we can see the violationCount is 9.

ubuntu@master-node-01 19:46:43:~/runtime-enforcer/charts/runtime-enforcer$ kubectl get wp deploy-ubuntu-deployment -o  yaml
apiVersion: security.rancher.io/v1alpha1
kind: WorkloadPolicy
metadata:
  creationTimestamp: "2026-07-17T19:35:38Z"
  generation: 4
  labels:
    security.rancher.io/promoted-from: deploy-ubuntu-deployment
  name: deploy-ubuntu-deployment
  namespace: default
  resourceVersion: "42344050"
  uid: 5badcd72-ebb5-4367-b023-dc895c02b885
spec:
  mode: protect
  rulesByContainer:
    ubuntu:
      executables:
        allowed:
        - /usr/bin/bash
        - /usr/lib/cargo/bin/coreutils/sleep
        - /usr/lib/cargo/bin/coreutils/ls
    ubutu-2:
      executables:
        allowed:
        - /usr/bin/bash
        - /usr/lib/cargo/bin/coreutils/sleep
        - /usr/lib/cargo/bin/coreutils/dir
status:
  activeViolationCount: 5
  observedGeneration: 4
  phase: Ready
  successfulNodes: 3
  totalNodes: 3
  violationCount: 9
  violations:
  - action: monitor
    containerName: ubuntu
    executablePath: /usr/lib/cargo/bin/coreutils/dircolors
    id: 2
    nodeName: susesecurity-worker-02
    podName: ubuntu-deployment-c46d6c6fb-jdhvr
    timestamp: "2026-07-17T19:46:20Z"
    workloadKind: Deployment
    workloadName: ubuntu-deployment
  - action: monitor
    containerName: ubuntu
    executablePath: /runc
    id: 3
    nodeName: susesecurity-worker-02
    podName: ubuntu-deployment-c46d6c6fb-jdhvr
    timestamp: "2026-07-17T19:46:20Z"
    workloadKind: Deployment
    workloadName: ubuntu-deployment
  - action: protect
    containerName: ubuntu
    executablePath: /usr/lib/cargo/bin/coreutils/cat
    id: 6
    nodeName: susesecurity-worker-02
    podName: ubuntu-deployment-c46d6c6fb-jdhvr
    timestamp: "2026-07-17T19:45:23Z"
    workloadKind: Deployment
    workloadName: ubuntu-deployment
  - action: monitor
    containerName: ubutu-2
    executablePath: /usr/lib/cargo/bin/coreutils/dircolors
    id: 0
    nodeName: susesecurity-worker-02
    podName: ubuntu-deployment-c46d6c6fb-jdhvr
    timestamp: "2026-07-17T19:36:55Z"
    workloadKind: Deployment
    workloadName: ubuntu-deployment
  - action: monitor
    containerName: ubutu-2
    executablePath: /runc
    id: 1
    nodeName: susesecurity-worker-02
    podName: ubuntu-deployment-c46d6c6fb-jdhvr
    timestamp: "2026-07-17T19:36:55Z"
    workloadKind: Deployment
    workloadName: ubuntu-deployment

NAME                         MODE      STATUS   ACTIVE VIOLATIONS   TOTAL VIOLATIONS
deploy-ubuntu-deployment     protect   Ready    5                   9

[Andreagit97]

Is this the same issue discussed here #758? It's likely that the violations are not missed but they are already present in the list and so we only change the timestamp instead of adding a new violation

[venkateshjayagopal]

@Andreagit97 When a violation happens it is a past event, changing timestamp on the old violation is bit confusing.

[Andreagit97]

what we are doing is to notify the user about the last time we have seen a violation for a specific binary, that's the reason why we are updating the timestamp. If the same violation is seen more than once we just report the last timestamp, maybe we can also store the first time we see the violation, so something like FirstSeen, LastSeen