Innovation in service meshes for cloud-native development got a lot more intriguing when Amazon Web Services announced its App Mesh at the end of March. And with the growing momentum with cloud-native technologies, such as Kubernetes, Istio and AWS App Mesh–and 47% of enterprises deploying to production multiple times per week, the question around the future of network security, containers and meshes is becoming a really relevant one.
This coupled with security moving toward a Zero Trust approach–where dev, sec and ops don’t trust any of the components in their software supply chain or their cloud-native stack–there are critical questions that all practitioners need to address. Such questions can get everyone closer to enabling modern DevSecOps teams with intelligent, scalable and automated approaches to Zero Trust that don’t slow agility and DevOps down.
DevSecOps teams need to be looking at is the entire software supply chain, which consists of many parts and aligns to the software development lifecycle model. Cloud-first or those embracing cloud-native technologies need to examine their own code, third party code and all of its supporting infrastructure – applying micro-segmentation at the container network level is not no longer enough to stop attacks or prevent growing vulnerabilities such as exposed access credentials.
In this eWEEK Data Points article, using industry information from Gadi Naor, CTO and co-founder of Alcide, we delve deeper into where cloud-native security is headed, what the future for network security monitoring, mesh performance and how multi-level network controls can equip DevSecOps teams to run safe and uninterrupted code and operations.
Data Point No. 1: The future of network security monitoring: eBPFs and service meshes such as Istio and AWS App Mesh
The motion around service mesh is pretty amazing. Building distributed systems and microservices is one thing – securing and monitoring them is extremely challenging. Istio tries to address these challenges with what appears to be a decouple between services and the underlying infrastructure.
Reality is that the underlying network from a security standpoint, can’t be ignored, and actually the perception as if the service mesh sidecar delivers on all your isolation/segmentation/zero-trust is misleading. SideCar are “programmed” not to route non-service traffic, which means from an isolation standpoint – something else needs to address that.
Here’s comes eBPF, embedding or forging network level policies to segment and inspect the traffic inside the mesh and outside the mesh and, in the process, covering all network grounds.
Data Point No. 2: Services meshes, their performance impacts and how to mitigate them
The benefits of a service mesh in the form of security and observability comes with a heavy resource tax. You couple each workload with a SideCar, which means network traffic needs to be steered into the side twice (on source and destination) for in-mesh communications – clearly you pay in compute, memory and network latencies.
Making the application service mesh-aware tends to introduce significant performance gains in terms of network latencies. This tax here forces a stronger need to introduce under-mesh network segmentation, which means policy management becomes much more challenging, and deep network security controls are definitely to be overlooked.
Data Point No. 3: The role of multi-network controls for node and load balancer to service traffic
Clearly, as we add abstraction layers to address certain ops and security challenges, we end up managing multiple firewall and isolation policies – if we cross cut it, we’ll see Istio Network Policies for in-mesh policy enforcement, and then, following good practices, we’d see Kubernetes Network Policies, which represents the service vehicle policy. Then we top that with the cloud-native network security controls (AWS Security Groups, Azure NSG, etc.), which represent the Infrastructure-level policies – clearly the policy isolation management becomes a real challenge that not only should not be overlooked, but requires a new intelligent and automated approach to addressing it.
Data Point No. 4: Automated ways to threat hunting and threat intelligence
If policies represent the enforcement layer of our intended services behavior, then threat hunting represents the must have “sugar coating” to cloud-native application deployments. Similar to the enforcement layer approach, threat hunting needs an intelligent and automated framework – one that integrates with CI/CD and scales with as your deployments grow. Such approach certainly needs to be rooted in the Zero Trust mentally and extend out of the network to the dev side and then the entire SDLC.