After acknowledging a violation for "cat" process, no new violations showed up under the policy but violations stats were incrementing

[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: After acknowledging violation id 2, future violation should show up for same process
• Current behavior: id 3 showed up for cat, but remaining 15+ violations records are not updated.
• Steps to reproduce:

1. After acknowledging ViolationID 2, I tried executing "cat" once and observed ViolationID "3" showing up.
2. Then I tried multiple "cat" process execution(within few seconds back to back), no violations showed up on the policy, but the "Violation Count" stats were incrementing.
3. Then tried a different process "whoami", the violation showed up again.

Below the policy CR with violations and stats.

ubuntu@master-node-01 16:46:47:~/runtime-enforcer/charts/runtime-enforcer$ kubectl get wp deploy-ubuntu-deployment-1 -o yaml
apiVersion: security.rancher.io/v1alpha1
kind: WorkloadPolicy
metadata:
  creationTimestamp: "2026-07-16T21:38:52Z"
  generation: 2
  labels:
    security.rancher.io/promoted-from: deploy-ubuntu-deployment-1
  name: deploy-ubuntu-deployment-1
  namespace: default
  resourceVersion: "42299592"
  uid: 5f79911a-2a87-4cfe-a00f-2724642db2b5
spec:
  mode: protect
  rulesByContainer:
    ubuntu:
      executables:
        allowed:
        - /usr/bin/bash
        - /usr/lib/cargo/bin/coreutils/sleep
        - /usr/lib/cargo/bin/coreutils/ls
status:
  acknowledgedViolations:
  - acknowledgedAt: "2026-07-17T16:11:31Z"
    reason: Using cat is accepted
    violation:
      action: protect
      containerName: ubuntu
      executablePath: /usr/lib/cargo/bin/coreutils/cat
      id: 2
      nodeName: susesecurity-worker-02
      podName: ubuntu-deployment-1-67c858dbcb-mj8kh
      timestamp: "2026-07-17T16:09:24Z"
      workloadKind: Deployment
      workloadName: ubuntu-deployment-1
  activeViolationCount: 4
  observedGeneration: 2
  phase: Ready
  successfulNodes: 3
  totalNodes: 3
  violationCount: 24
  violations:
  - action: protect
    containerName: ubuntu
    executablePath: /usr/lib/cargo/bin/coreutils/whoami
    id: 23
    nodeName: susesecurity-worker-02
    podName: ubuntu-deployment-1-67c858dbcb-mj8kh
    timestamp: "2026-07-17T16:40:07Z"
    workloadKind: Deployment
    workloadName: ubuntu-deployment-1
  - action: protect
    containerName: ubuntu
    executablePath: /usr/lib/cargo/bin/coreutils/cat
    id: 3
    nodeName: susesecurity-worker-02
    podName: ubuntu-deployment-1-67c858dbcb-mj8kh
    timestamp: "2026-07-17T16:29:17Z"
    workloadKind: Deployment
    workloadName: ubuntu-deployment-1
  - action: protect
    containerName: ubuntu
    executablePath: /usr/lib/cargo/bin/coreutils/dircolors
    id: 0
    nodeName: susesecurity-worker-02
    podName: ubuntu-deployment-1-67c858dbcb-mj8kh
    timestamp: "2026-07-17T16:07:35Z"
    workloadKind: Deployment
    workloadName: ubuntu-deployment-1
  - action: protect
    containerName: ubuntu
    executablePath: /runc
    id: 1
    nodeName: susesecurity-worker-02
    podName: ubuntu-deployment-1-67c858dbcb-mj8kh
    timestamp: "2026-07-17T16:07:35Z"
    workloadKind: Deployment
    workloadName: ubuntu-deployment-1

[venkateshjayagopal]

One more suggestion:
Would it be good if we start the violationID record stats from "1" instead if "0"?, we can match the "violationCount" and "violationID" with no confusion. Just a cosmetic issue.

[holyspectral]

I'm sure the confusion comes from how we calculate the violationCount .  In the current behavior, new violations could get folded into the existing violation silently when a few conditions are the same (namespace, pod name, executable nam and etc.) In this case, the violation count will keep increasing without any new violations, which is confusing.  A better alternative could be what I described here, where we have count field in each individual violation.

[holyspectral]

Would it be good if we start the violationID record stats from "1" instead if "0"?, we can match the "violationCount" and "violationID" with no confusion. Just a cosmetic issue.

I don't have strong opinion, but maybe we could make it more consistent with golang convention which starts with zero.

[andreaterzolo]

I'm sure the confusion comes from how we calculate the violationCount . In the current behavior, new violations could get folded into the existing violation silently when a few conditions are the same (namespace, pod name, executable nam and etc.) In this case, the violation count will keep increasing without any new violations, which is confusing. A better alternative could be what I described #751, where we have count field in each individual violation.

Having a counter for each violation makes sense. The only thing that is not obvious to me is how we should treat the violationCount. Today it keeps track of all the violations even if they are duplicated, with your approach, if i understand well it is only incremented in case of not-duplicated violations. So instead of having a global counter of violations we will have a counter of distinct violations.

To be honest i like the new approach it seems more user friendly!

Moreover i believe we can also do this

Would it be good if we start the violationID record stats from "1" instead if "0"?

In the end i don't see issues in doing that and for the user it would be clearer