Why You Need a Network IDS for Kubernetes

By Julien Sobrier, Head of Product, Octarine

Network visibility is a key element of securing your applications and enabling incidence response. The network layer is where you can detect exploits when they come in, lateral movement and data exfiltration. It is also mandated for compliance such as PCI-DSS, Soc2, etc.

Most companies have deployed a network Intrusion Detection System (IDS), sometimes as part of the Next-Gen Firewall, to maintain control of their ingress traffic, restrict egress access and monitor internal traffic. But these devices don’t work with Kubernetes.

An IDS designed for Kubernetes

Kubernetes offers a number of challenges to network visibility and control. First, IPs and ports, often used to identify servers and services, are dynamic in Kubernetes. The IDS has to be aware of the Kubernetes definition of the workload and able to map network activities to workloads as they go up and down, and move from nodes to nodes. The IDS needs also to be able to differentiate between traffic initiated by Kubernetes and traffic coming from the nodes themselves.

A lot of the Kubernetes traffic is internal traffic (east-west), which may happen between workloads within a host. An IDS that sits on the network between nodes won’t see any of this traffic. This gets worse if you use a service mesh, such as Istio, that encrypts traffic between workload: the IDS won’t be able to inspect the encrypted content.

You need an IDS that integrates seamlessly with Kubernetes and can support service meshes such as Istio: awareness of the workload identity, visibility into all east-west and north-south traffic, across all the Kubernetes clusters, with Layer 7 content inspection.

What to look for in a Kubernetes IDS

The IDS has evolved over the years. Modern IDS must be able to detect known and unknown threats by combining signature-based inspection with behavior analysis powered by machine learning. It also needs to be able to detect and prevent access to malicious external IPs and domains: Bitcoin miners, Botnet Command & Control servers, etc.

The IDS should be able to detect the different stages of an attack:

  • Reconnaissance or probing on your ingress access points: detect web scanners, attempts to exploit known vulnerabilities, denial-of-services, etc.
  • Exploitation of a vulnerability: detect the latest vulnerabilities, malicious shellcode, exploitation stools such as metasploit, etc.
  • Probing of the internal network and lateral movement after a successful breach: unusual traffic patterns, high error rates, scanning tools, etc.
  • Exfiltration of data: protocol tunneling, p2p protocols, etc.

On the operational side, a Kubernetes IDS needs to scale with your cluster. It must be distributed to avoid latency. An IDS that is truly integrated with Kubernetes will be able to work as you change your Kubernetes network provider or add a service mesh to encrypt all your internal traffic.

Finally, the IDS needs to provide all the information you need to respond to security incidents:

  • The identity of the sender and receiver
  • Layer 7 context such as the domain name (egress traffic), original source IP (ingress traffic), protocol, etc.
  • A capture of the actual malicious traffic
  • A baseline of the normal traffic compared to anomalous behaviors

Octarine provides details about the threat and the matching packet capture

Octarine’s IDS for Kubernetes and Istio

Octarine offers a distributed IDS for Kubernetes and Istio (patent pending) with no impact on latency. It detects known threats with a signature-based Layer 7 content inspection with over 4,000 signatures. You can take a look at our coverage on our Threat Portal.

Octarine constantly builds and updates a model of all workload traffic. It is able to detect Layer 3 and Layer 7 anomalies such as higher rates of HTTP errors, access to new IPs and domains, new protocols, etc. Octarine reports both the baseline and the anomalous rate.

Octarine includes a list of 30 millions IPs and domains that you can block to prevent connections to botnet servers, cryptominers, compromised servers, etc. This list is computed from over 100 threat intelligence feeds.

Get in touch with us: info@octarinesec.com

Want security tips from the pros?
Get the DevSecOps simplified newsletter.

* indicates required

Please select all the ways you would like to hear from Octarine:

You can unsubscribe at any time by clicking the link in the footer of our emails. For information about our privacy practices, please visit our website.

We use Mailchimp as our marketing platform. By clicking below to subscribe, you acknowledge that your information will be transferred to Mailchimp for processing. Learn more about Mailchimp's privacy practices here.