https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# neuvector-security
a
This message was deleted.
q
Hi Javier. I believe you could add a 
does NOT contain any of
boolean to the Operator for the 
Namespace is one of
Criterion.
a la
woops, I mean:
a
Yes, but I was asking for an exclusion for all the rules. I am already using your approach but it is easy to forget a namespace in a rule or even have to update all the rules at once whenever a new system application is deployed... I am looking for an exclusion for all the rules at once (we were able to use an exclusion for the admission control in Kyverno for example)
q
oh… alll the rules. hmmmm
a
For example, if you want to exclude cattle-monitoring-system...
q
like this one?
a
Yes but this rule allows the creation of a resource... and then the rest of the rules apply. Therefore, the only way to avoid a namespace in all the rules is adding this exclusion on each rule, which may be complex.
As far as I know, all the rules apply. There is no order that can prevent the execution of certain rules if the previous ones match.
q
yeahhh. lemme noodle on this
a
Many thanks for your help Jorn.
The easiest way would be an exclusion for the admission on certain namespaces (that's the approach in Kyverno for example).
q
and ordered rules. 😉
a
Well, that would be awesome!!
q
I expect some enhancements coming this summer 😉
a
Many thanks, we will be looking forwarded. It will really be a great improvement.
f
Hi Javier! Try to add an allow rule to exclude a namespace you want
a
Do you mean a rule avoiding the rest of rules for some special namespaces?
f
Yea, in my example I allow anything in a demo ns
q
a
Well, I will try and let you know. Sometimes the solution is simpler that we thought and we didn't see it in front of us.
q
from the above 1. Default allow rules (e.g. system namespaces) 2. Federated allow rules (if these exist) 3. Federated deny rules (if these exist) 4. CRD applied allow rules (if these exist) 5. CRD applied deny rules (if these exist) 6. User-defined allow rules 7. User-defined deny rules 8. Allow the request if the request doesn’t match any rule’s criteria above
a
ok, that's a good point I was missing. "Allows win".
Great, many thanks. This is definitely better than avoiding completely the admission control.
q
Yeah, admission control rules sometimes look inverted vs things like traditional firewall rules. That’s by design, and for good reason. But it can also make our human brains go brrrzzp. 😉
a
Many thanks both for your help!!
q
• zero-trust (like a firewall or the rules in Groups in NeuVector): deny by default • admission control: allow by default
d
hello @quaint-candle-18606 Would you be able to create a rule to allow ssh and kubectl in neuvector? Where would this rule be created? And if you have any examples you can send me to create and test here.
q
Hi Thiago. You’re reusing an existing thread about a different topic. I suggest you re-post this question in the main channel so that it gets visibility. 😊 (I’m boarding a plane rn so may be delayed in my response )
4 Views
Open in Slack
PreviousNext
Powered by