This message was deleted.
# neuvector-security
a
This message was deleted.
q
I believe that there's a taint that excludes the Enforcers from the CP nodes, yes.
In my opinion, you should go protect those, as well. Maybe even especially. πŸ˜‰
n
Any particular reason why they are not protected by default?
@quaint-candle-18606 just to clarify, I installed the neuvector app from the Rancher app repository with all default settings. I'm just wondering why control plane nodes are not protected by default, and, if that makes sense, how to protect them (in particular so they can be analyzed by the compliance scans).
q
The why is generally driven by a best-practice/policy about leaving master nodes alone, especially in Rancher.
But you and I agree an exception should be made here.
So, you'll probably need a toleration along the lines of
Copy code
enforcer:
  tolerations:
    - key: "<http://node-role.kubernetes.io/master|node-role.kubernetes.io/master>"
      operator: "Equal"
      value: ""
      effect: "NoSchedule"
Looking at my little lab, i see it's already in there:
And the Enforcer is indeed running on the master node(s)
a la (no lauging at my single CP node; it's a lab. πŸ˜„ )
n
Great! Thanks Jorn, I appreciate your help πŸ™‚ Since this is a relatively critical cluster, I might need to do some more research and/or validate with the RKE2 people, but this looks promising.
q
🀜 πŸ€›
Perhaps even more important than scanning might indeed be the network protections of critical functions like etcd, yeah?
πŸ‘ 1
n
Hmm I can see in the chart values that this is already set by default:
Copy code
tolerations:
    - effect: NoSchedule
      key: <http://node-role.kubernetes.io/master|node-role.kubernetes.io/master>
    - effect: NoSchedule
      key: <http://node-role.kubernetes.io/control-plane|node-role.kubernetes.io/control-plane>
Yet I don't see my control plane nodes in the ui
And the enforcers are not running on the control plane nodes, as far as I can tell
@quaint-candle-18606 This seems to be related to https://github.com/neuvector/neuvector-helm/issues/399
q
ahhhhh, yeah. Per that issue, have you tried the
Copy code
effect: NoSchedule
 key: <http://node-role.kubernetes.io/etcd|node-role.kubernetes.io/etcd>
suggestion?
n
I haven't (although I'm fairly certain this would solve it), but at this point I'm moreso wondering if I'm straying too far from the beaten path so to speak. It is quite surprising to me that this issue would go unresolved for so many months. Do most people simply not have this etcd taint, or is running neuvector on control-plane nodes just not that common?
q
looks around
I think not enough people have thought hard enough about it as you have. πŸ˜‰
πŸ˜‚ 1
I escalated the request, as I agree with you here.
πŸ™Œ 1
n
Alright, thanks again!
I added the toleration, and so far so good everything works fine, and I see the control plane nodes in my assets. But, my original problem still persists. The CIS rule K.1.1.3 should fail (according to my manual verification, and the rancher CIS benchmark app). In Neuvector, I see that rule in the compliance profile, but it does not appear at all in the node compliance section, or anywhere else.
(to be clear, K.1.1.3 is not the only one, I'm just taking it as an example. There are others, such as K.1.1.1, K.1.1.5, etc)
@quaint-candle-18606 Sorry to ping, I was just wondering if you could shed some light on this. First image shows that according to the Rancher CIS benchmark (and my own manual verification), our cluster fails the K.1.1.3 check. Second image shows that NeuVector is aware of K.1.1.3 Third image shows that K.1.1.3 does not appear in the compliance report.
q
I'm researching.
❀️ 1