Network segmentation is almost as old as computer networking. The evolution of network segmentation went through switches to routers and firewalls, and as modern networks evolved, the ability to better control traffic by operating system native functionality evolved as well. Native controls like IP Tables became lingua franca, alongside access control lists, process isolations, and more.
Native controls are not a new concept. In fact, they have existed for years in operating systems, cloud providers, and lately, Kubernetes. However, most security products do not leverage them.
As security started shifting left, the paradigm change forced organizations to reevaluate their security processes.
Let’s dive into what Kubernetes network segmentation is, what it looks like in a Kubernetes era, and what can we expect from security tools in the near future.
The great abstraction
Before containers and Kubernetes, applications were mostly static and coupled with hosts and IP addresses. Communication between applications required networking teams involvement to open ports and modify security configuration in network devices. and
The process of segmenting the network included multiple stakeholders. From application owners to networking and security teams, they worked together to create the right set of rules that provide the necessary isolation while still allowing the business to function. After initial successful segmentation, there was still a need to update rules based on changes in the environment. Modifying them required a slow approval process and did not happen very often since applications changed infrequently.
Enter Kubernetes.
No more filing tickets to configure routing rules and opening firewall ports for internal application communication. Service-to-service access is baked into the platform, while complex routing is handled by the underline network plugins. All you need to do is to define the corresponding service name and deploy the changes, the rest will be taken care of.
On top of routing, Kubernetes is shipped with built-in network policies that enable users to apply access control rules using the same declarative language they use to define resources in the environment. Users can write policies to allow or deny inbound and outbound connections, and modify them with every application change.
The ability to embed policies in the development cycle and CI/CD dramatically improved application development speed. When applying security controls can be handled by a single team using a single platform, introducing changes into the environment becomes simpler.
The old world vs. the new world
The heavy weight process of defining and maintaining network segmentation rules was simplified in Kubernetes. App developers can now express exactly what services are required by the app while the underline platform takes care of enforcing it.
The question then becomes why would one use an external foreign to the platform mechanism to achieve what a native functionality provides out-of-the-box?
Some would argue that using external enforcement is more secure, others would say that networking teams own network segmentation so using existing proprietary products is easier for them, but at what cost?
Solutions not using the native controls have the potential to interfere with the platform operation, and when such interference happens, finding and debugging issues becomes even more difficult.
On top of that, configuring and maintaining policies separately from the application complicates the day-to-day development. How can you streamline the development process when developers need to rely on other teams to allow service-to-service access?
Lastly, there is the infamous vendor lock-in, caused by the use of proprietary segmentation policies.
The result is slower development times, more friction, and a more complex environment to operate.
The future of segmentation solutions
At this point, you may ask yourself: Why do solutions for Kubernetes segmentation even exist?
If Kubernetes’ native controls are so powerful and superior to any other product, can’t we just use them?
While Kubernetes solved few of the main segmentation problems, primarily how to describe, configure, and enforce service-to-service segmentation, the fast-pace and constantly changing nature of cloud-native environments created a new set of challenges:
- Identifying all inbound and outbound connections needed by a service.
- Validating that applying a network policy is not going to cause a production outage.
- Modifying network policies when the application changes.
And finally, Kubernetes network policies are still tricky to get right, so even though it’s the native platform language, developers struggle with authoring them.
This is where future segmentation solutions should focus. While native controls are the better engines to use for segmentation, the ongoing process of maintaining policies and embedding them in the development cycle are still a challenge.
In Sysdig, we strongly believe that native controls and building on open technologies provides the best value for our customers. That’s why we just released a tool that will help you build Kubernetes network policies in minutes inside Sysdig Secure. You can get started in less than five minutes, start your free trial today!