NeuVector Adds Enhanced Security to Service Meshes
Last year Kubernetes was the shiny new toy that companies were deploying. Now service mesh is that shiny new toy, according to Gary Duan, chief technology officer and co-founder of container network security vendor NeuVector.
“People are saying, ‘Wow, I can get great routing features, encryption, some level of authentication.’ That’s all good stuff. But they still don’t know how to monitor that traffic as well as do any type of traditional security like threat detection or inspecting the pods to look for suspicious processes,” he said.
To remedy that, NeuVector has developed integration with the Istio and Linkerd2 service meshes that expands its security capabilities for production Kubernetes deployments.
Service meshes form the basis in the early stages of projects, giving identity to microservices and understanding the interactions between them, facilitating attaching policy, security and other controls to them, Pere Monclus told an audience at KubeCon + CloudNativeCon North America 2018.
“Everyone wants to ignore security but can’t ignore security,” added IBM’s Jason McGee during The New Stack Pancake Podcast during the event.
NeuVector calls the integrations a “security mesh,” in which it can visualize, monitor and protect service mesh system connections and containers plus application workloads managed by a service mesh.
It can provide deep packet inspection, the ability to segment services at the application layer and to define authorization between services. Layer 7 segmentation rules are generated automatically based on a baseline of network traffic and processes generated from behavioral learning.
It creates whitelist rules based on that network baseline of each service and also will monitor for threats outside the service mesh, such as attacks based on ICMP (Internet Control Message Protocol) or UDP (User Datagram Protocol) traffic.
It can see both the unencrypted traffic between each application container within a pod as well as the encrypted TLS traffic between the proxy containers.
Duan explained it this way:
“The core service mesh technology is a container. When you put it on any Kubernetes worker node or Docker host, we can inspect all the traffic on that host. Istio and Linkerd insert a sidecar container into the pod. Istio uses the Envoy proxy. The container sends its connections through the proxy, where it is encrypted before sending it out to other pods or externally. Our technology intercepts those connections before it’s encrypted in Envoy. Then on the other end, the receiving Envoy sidecar decrypts it, then we look at it before it hits the receiving application container. We have to put those two together: ‘Oh, A and B are part of point connection. Does it contain any attacks, like DDOS? Should this connection be allowed?’ We’re looking at the application, at embedded threats, and doing some segmentation there as well.”
When you deploy service mesh, you’re deploying these proxies as well as a whole new control plane. Those are potential vulnerability sources as well, he said
“We monitor not just your application traffic and workload, but we will also help you visualize and monitor Istio and control plane traffic,” he said.
Any new control infrastructure introduced into a system, while adding a new layer of security, also presents new attack surfaces and new opportunities for backdoor attacks, Michael Churchman recently wrote in a guest post for The New Stack.
Because these platforms manage traffic and access and are trusted by the application and other infrastructure elements, that makes them tempting targets for exploits.
Duan expects service mesh security to evolve much like that for Kubernetes. At first, there was a lack of visibility in pod-to-pod traffic, but one that was provided, it became a question of how to protect it.
“Service mesh not a technology for the faint of heart. There’s a lot going on,” he said. “There’s a management headache as well as infrastructure management to run a service mesh.
“There’s confusion with customers. These service meshes have security features. So do I need to add more security if I have the built-in security features of Kubernetes if I have a service mesh on top of that? What we have to gently point out to customers is that a service mesh is not a security product.”
They should look at it as a more of an advanced routing type of product with great service discovery and routing capabilities, he said.
“An analogy might be a load balancer… you would never go into production without a next-generation firewall because a load balancer serves a different purpose.
“You really should think of them as complementary. If you have a financial or business-critical application, a service mesh is great. It’s going to help you scale and do application performance management, but you should have great network visibility. Then you still need to do all the vulnerability scanning and monitor the containers for exploits. Those are things that something like a service mesh isn’t designed to do.”
Feature Image: “Afternoon landing # 10 at Port Lockroy on Wiencke Island,” by Murray Foubister. Licensed under CC BY-SA 2.0.
