Hi everyone, I filed this report a while ago for what we feel is a pretty serious security flaw. In short, it seems like group rule are sometimes not applied to quick/ephemeral processes. I filed an issue here Process generates security event even though custom group should allow · Issue #2161 · neuvector/neuvector Someone else filed another here Quick processes can bypass rules · Issue #1800 · neuvector/neuvector And another one here Is there a warm up time until the enforcement starts working? · Issue #2068 · neuvector/neuvector Has this been addressed internally, is there any news you could share on this? Thanks!

cc: @quaint-candle-18606

Product Engineering reports "i put the team analysing this so we are investigating and we will have more answers monday or tuesday"

yes the team is evaluating how we can tackle this ill let you know since the team comes back to me it can take some time because of timezone differences

Thanks everyone, please let me know either here or under the issue I opened as progress happens on this. Much appreciated 😄

Hello Louis sorry for the late reply

Thanks for the feedback, much appreciated. I'll try to get in touch with Davide.

in order for us to get over that limitation it seems a lot of effort needs to be overcome , and right now i dont know if we can tackle this right away

That's understandable! Still, since this has been noted in our ITSec reviews we're kind of in a bind where we need to at least try to mitigate this. We can't just let pods run unenforced for long(ish) periods of time. And if you see my post below in the chat, we're also getting constant security events from rules we have already allowed, this all makes NeuVector difficult for us to operate. In any case, I appreciate y'alls work on this and we hope we can find a solution at some point. Thanks!

there might be a good solution in the works in version 6 but thats something that @tall-army-18868 can provide more information

Hi everyone, Sam here from the dev team. There are two technical reasons behind this: 1. No container lifecycle hook integration. NeuVector doesn't hook into container lifecycle events such as NRI or OCI hooks. 2. Policy decisions are controller-driven. By design, NeuVector relies on its controller to make policy decisions, which can take a few seconds before a policy is assigned to a workload. Much of NeuVector's existing design is built around these two points, and changing them would break existing behavior that current users depend on. For that reason, this isn't something we plan to support in the current architecture. That said, we're working on a new process and network enforcer that's designed from the ground up to address this gap.

Thanks Sam for providing some clarity, much appreciated. Do you think the behavior you are describing could also be linked to this : https://rancher-users.slack.com/archives/C036F6JDZ8C/p1786554728517919, or is that something else entirely?

If there is no ephemeral or short-lived container involved, I'd say it's probably different from what I described. Is that a EKS? By any chance you have istio in the environment?

Thanks. The cluster in which neuvector runs is RKE2 managed by Rancher (EC2 node driver). We don't use istio or any service mesh, just plain Cilium CNI.

hmm okay. Yeah I agree the behavior is weird. My recommendation right now is to create a GitHub issue and attach the information you have including logs and support bundle. It's easier this way for the right person in the team to look into it.

Will do, thanks!