If it were me, I’d have New Services Mode on my prod cluster(s) set to Protect.

Building CRD rules would just be part of the Dev/test --> QA process. So, if Carl gnashed his teeth over “_I deployed a new app to Prod and things are getting denied why or why?!”_ we could say “Carl, did you not test this app first? C’mon Carl.” 😉

BTW, among so many other curious things, this is something strange that I noticed while analyzing the network graphs of running workloads.

Screenshot 2023-02-25 at 00.14.56.png

Those empty circles seem weird 🤔

if you double-click on the nodes one, does it expand?

Yes, that does expand.

My actual concern is that I could see a network connection from the underlying nodes to each workload most of the time. Not sure what exactly is that connection ?

you’d have to click on each line

or, go to Policy --> Groups and see what got learned there (I prefer this method, personally)

Did all that 🙂 The issue is it's not something that I expected.

For most of the workloads, these type of HTTP connections from the nodes are visible in the network graph with unexpected port numbers, shown out of no where.

Just wondering if this could be some platform connection.

I know that in some instances, there could be connections to the meta data endpoint of the nodes as we are running in a cloud, but that is other way around and not this frequent.

Following is another example of the same mystery.

Screenshot 2023-02-25 at 00.42.52.png

Screenshot 2023-02-25 at 00.42.52.png

Yes, as it appears to be 🙂 Nice catch! and the mystery got resolved.

Since it's HTTP, I just took a packet capture of a suspected workload and following is what I found.

Screenshot 2023-02-25 at 13.54.23.png

@silly-airline-38945 Thanks for the hint! 🙂

Hello Team, what does this connection to nv.ip.kubernetes.default represent?

Screenshot 2023-02-28 at 14.35.08.png

I doubt it to be a connection to K8s api server. Is that correct?

Folks, how do each mode (discover, monitor, protect) differ in behavior when in basic state and zero drift state?

For example, how do discover mode behave when in basic state Vs. in zero drift state?

Just trying to understand the difference 🙂

and could not find a proper explanation in the docs

zero drift is only related to process enforcement. the difference is that it will allow any binary present in the deployed container, which is invoked by pid1 to be run. Otherwise in basic , any process that will run needs to be learned or manually added. So zero drift works well for hardened images where there are few if any shell outs, potentially infrequently that might be missed in discover mode (i.e. a monthly trigger). In our experience, most users are not hardening to this extent, or using distroless, so basic is likely better coverage.

Awesome! That makes sense and yes, I could not really see a difference in between both basic and zero drift for network enforcement.