Reducing the attack surface and preventing lateral movement is a core tenet of effective cybersecurity design. When determining the approach in securing Kubernetes you have to find the right balance of controls that allow you to manage operations at scale.
Kubernetes advocates for a flat networking model as it allows for simpler application discovery and microservice communication. The flat network also eliminates the need for complex Network Address Translation (NAT) configurations, which allows for easier scaling and support for large numbers of networked containers. However, as a flat network with an open mic, pods can communicate unrestrainedly introducing security threats, unauthorized data access, and the lateral expansion of attacks in compromised environments. With planning and the application of readily available networking provisions like segmentation, secure Kubernetes can become your default.
What is Network Segmentation?
Network segmentation is the practice of dividing networks into smaller functional groups, or segments to improve security, performance, and management. Through segmentation, applications and workloads are compartmentalized using custom security and access policies to easily isolate users and data.
Network segmentation is implemented using either physical segmentation or logical segmentation. Physical segmentation relies on port, switch, router, and cable assignments to physically separate applications into isolated subnetworks. Thankfully, virtualized and cloudified deployments use Software Defined Networking (SDN) to logically and dynamically segment applications and workloads into separate virtual networks without touching the physical underlay.
Network segmentation simplifies the development of firewall rule sets for NetOps and contains the blast radius of cyberattacks by limiting the ability of attackers to move laterally within the network. Overall, network segmentation is an important best practice for enhancing the security and operability of modern computer networks.
Why is Network Segmentation important in Kubernetes?
Kubernetes is now the most popular orchestration tool for managing next generation applications. The use of containers and the growing deployment of microservices improves agility, speed, and efficiency. However, operations remain challenged to secure these applications, at scale, without increasing complexity.
When segmenting a Kubernetes cluster, NetOps typically defines a set of network policies using complex rules, labels, and IP lists to isolate applications. Given the default behavior of a network policy is to ‘fail open’, NetOps must carefully audit network policies for any unaccounted traffic that may slip through a policy set. In short, network policy is an effective and crucial tool for segmentation but when used alone, it is complex and impractical to manage at scale.
A Better Way to Kubernetes Segmentation
What if segmentation could be simplified and embedded into traditional networking models without any complexity? While it is an industry goal, it is today’s reality for Juniper’s Cloud-Native Contrail Networking (CN2), a combined Kubernetes Container Network Interface (CNI) and SDN providing network administrators with a powerful tool to secure their clusters and deploy multi-tenant application delivery environments. In these environments, network segmentation does not replace network polices but augments them to provide another layer of defense.
Using CN2, NetOps can choose from several options for implementing network segmentation in Kubernetes, including:
Namespace Isolation – As an additional level of abstraction, pods in an isolated namespace will not be able to communicate with workloads in other namespaces without additional configuration to connect those segments.
Kubernetes provides namespaces to divide application resources between multiple users or application functions. The below diagram depicts how namespaces can be extended to provide isolation such that NS1 and NS2 pods cannot communicate with each other.
Pod Networking – Multiple Pod networks can be created within a cluster, allowing Pods to be assigned to a specific network. In this way it is possible to create application specific network segments and attach them to workloads during the deployment. The below diagram depicts this feature.
Network segmentation options should augment the capabilities of regular Kubernetes objects like services, deployments, or network policies. This ensures that existing application manifests do not require modification to leverage enhanced security features.
Existing Kubernetes semantics like labels and annotations can be used to simply consume the custom networks that the CNI offers.
What’s Next?
While strict isolation is a use case for segmentation, the overwhelming need and greatest NetOps challenge is the secured communications between ephemeral workloads that can appear, grow, shrink, and disappear. The dynamic nature of these virtualized and containerized workloads requires tools and processes that are flexible, intuitive, and repeatable. Tune into the next blog in this series to learn how the Kubernetes CNI can further be extended to automate and simplify the security and networking of Kubernetes-hosted applications.
------------------------------
Prasad Miriyala
------------------------------