network-mapper VS kubeshark

Yep! When you deploy Otterize, you get a map of your cluster’s traffic, with zero-configuration, through the open-source network-mapper.

After multiple iterations, research sessions and some trial & error, we could produce an exportable list of network connections in any Kubernetes cluster. You might recall that our larger goal was to get to a logical (functional) map of pod-to-pod traffic, and that will be covered in a future posting. After adding that capability, here’s an example output from our project, now called network-mapper, when pointed at one of the clusters in our “lab” environment:

It'll require some changes but you can go for it if that's something up your alley, as after all, it's all open source - https://github.com/otterize/network-mapper

We received some great feedback from the community regarding our tool, and one of the most commonly requested features was visualization. So we embedded this functionality into the tool, and now you can easily map and visualize your cluster with a single CLI command.

As you've mentioned, it is not possible to define deny rules using the native NetworkPolicy resource. Instead, you could use your CNI’s implementation for network policies. If you use Calico as your CNI you can use Calico's network policies to create deny rules. You can also take a look at Otterize OSS, an open-source solution my team and I are working on recently. It simplifies network policies by defining them from the client’s perspective in a ClientIntents resource. You can use the network mapper to auto-generate those ClientIntents from the traffic in your cluster, and then deploy them and let the intents-operator manage the network policies for you.

The one similar product I had come across is Kubeshark (https://github.com/kubeshark/kubeshark). But admittedly the eBPF way seems more performant theoretically (given you can afford to have a modern-enough kernel). I'm really excited to see how this project develops out.

The eBPF-mode of innovation is pretty exciting, truly a fresh lens to building software. I'm also following Akita Software - the company building an eBPF paradigm of monitoring.

GitHub: https://github.com/kubeshark/kubeshark Website: https://kubeshark.co/

Can you send us the logs using: `kubeshark logs` (you can also use the issues page or slack)

Yes there are, but Cloud NAT alone won't be able to help you with that. You can either use a standalone proxy or a 3rd party firewall appliance through which you can route your traffic, or use more modern approaches with tools such as Kubeshark or Cillium.

https://github.com/kubeshark/kubeshark - somewhat like Wireshark for Kubernetes. LMK if you have any questions

For example, this open-source project gives instant visibility into API traffic in kubernetes environments: https://github.com/kubeshark/kubeshark

Check out the GitHub repository: https://github.com/kubeshark/kubeshark