Kubernetes revolutionised the deployment of cloud-native applications by making workloads portable, scalable, and easy to orchestrate. However, while Kubernetes excels at managing applications, its networking model introduces an important challenge for network services: a lack of flexibility in its networking model.

Most Kubernetes deployments rely on a flat network approach where every pod can potentially communicate with every other pod inside the cluster. Although Network Policies can restrict some traffic flows, workloads still fundamentally share the same networking space. For traditional microservice applications, which are usually application-layer oriented, this behaviour may be acceptable, but for network functions, multi-tenant platforms, or security-sensitive services, this approach quickly becomes limiting. This is where micro-segmentation becomes critical.

Micro-segmentation is the practice of dividing an infrastructure into isolated virtual network segments, where workloads only communicate with the components explicitly allowed to them. Instead of treating the cluster as a single trusted environment, micro-segmentation applies the principles of least privilege directly to network connectivity.

The benefit of applying micro-segmentation over K8s platforms can be substantial. First, micro-segmentation improves security by reducing lateral movement. If one workload becomes compromised, attackers cannot freely traverse the infrastructure to reach other services. Each segment behaves as an isolated environment with controlled entry and exit points.

Second, it enables the deployment of advanced network services inside Kubernetes. Functions such as firewalls, routers, proxies, or content delivery components often require separated Layer 2 or Layer 3 domains to operate correctly. In a flat network, these services lose much of their networking context because every workload remains directly reachable.

Third, micro-segmentation simplifies multi-tenant deployments. Different applications, customers, or services can coexist within the same Kubernetes infrastructure while remaining logically isolated from one another. This becomes increasingly important in edge computing, telecom platforms, and distributed cloud environments.

At the infrastructure level, achieving true micro-segmentation requires more than simple traffic filtering. It requires programmable virtual networking capable of creating isolated communication domains between workloads, independently of where they are physically deployed. This becomes even more relevant in distributed cloud-edge environments, where services may span multiple Kubernetes clusters and heterogeneous infrastructures.

To address these challenges, the CyberNEMO Zero Trust Network Access (ZTNA) framework extends the capabilities of the NEMO meta Network Cluster Controller (mNCC) to provide secure micro-segmentation mechanisms for both intra-cluster and inter-cluster communications. By enabling isolated virtual networking domains across cloud-native infrastructures, CyberNEMO introduces a flexible networking foundation for advanced network services, secure workload isolation, and distributed edge deployments. In next posts, we will explore in more detail the technology behind this functionality:

L2S-M.Why Micro-Segmentation Matters in Kubernetes

Kubernetes revolutionised the deployment of cloud-native applications by making workloads portable, scalable, and easy to orchestrate. However, while Kubernetes excels at managing applications, its networking model introduces an important challenge for network services: a lack of flexibility in its networking model.

Most Kubernetes deployments rely on a flat network approach where every pod can potentially communicate with every other pod inside the cluster. Although Network Policies can restrict some traffic flows, workloads still fundamentally share the same networking space. For traditional microservice applications, which are usually application-layer oriented, this behaviour may be acceptable, but for network functions, multi-tenant platforms, or security-sensitive services, this approach quickly becomes limiting. This is where micro-segmentation becomes critical.

Micro-segmentation is the practice of dividing an infrastructure into isolated virtual network segments, where workloads only communicate with the components explicitly allowed to them. Instead of treating the cluster as a single trusted environment, micro-segmentation applies the principles of least privilege directly to network connectivity.

The benefit of applying micro-segmentation over K8s platforms can be substantial. First, micro-segmentation improves security by reducing lateral movement. If one workload becomes compromised, attackers cannot freely traverse the infrastructure to reach other services. Each segment behaves as an isolated environment with controlled entry and exit points.

Second, it enables the deployment of advanced network services inside Kubernetes. Functions such as firewalls, routers, proxies, or content delivery components often require separated Layer 2 or Layer 3 domains to operate correctly. In a flat network, these services lose much of their networking context because every workload remains directly reachable.

Third, micro-segmentation simplifies multi-tenant deployments. Different applications, customers, or services can coexist within the same Kubernetes infrastructure while remaining logically isolated from one another. This becomes increasingly important in edge computing, telecom platforms, and distributed cloud environments.

At the infrastructure level, achieving true micro-segmentation requires more than simple traffic filtering. It requires programmable virtual networking capable of creating isolated communication domains between workloads, independently of where they are physically deployed. This becomes even more relevant in distributed cloud-edge environments, where services may span multiple Kubernetes clusters and heterogeneous infrastructures.

To address these challenges, the CyberNEMO Zero Trust Network Access (ZTNA) framework extends the capabilities of the NEMO meta Network Cluster Controller (mNCC) to provide secure micro-segmentation mechanisms for both intra-cluster and inter-cluster communications. By enabling isolated virtual networking domains across cloud-native infrastructures, CyberNEMO introduces a flexible networking foundation for advanced network services, secure workload isolation, and distributed edge deployments. In next posts, we will explore in more detail the technology behind this functionality: L2S-M.

In the architectural hierarchy of CyberNEMO, the White Shark probe acts as the primary sensory organ, providing the critical observability required for a secure meta-Operating System. While other components focus on high-level orchestration or AI-driven analysis, White Shark operates at the “ground level,” functioning as a high-precision network probe that monitors the most fundamental unit of connectivity: the network socket.

Technical Architecture and Integration

Technically, White Shark is designed for seamless deployment within Kubernetes-based environments, where it integrates into the data plane to capture real-time telemetry. Its architecture is built around a lightweight footprint to minimize overhead while maintaining the ability to collect granular network metrics across the distributed Computing Continuum. As a key asset within Work Package 2 (WP2), it is specifically engineered to support Zero Trust Network Access (ZTNA) by providing the visibility needed to enforce “explicit verification” for every connection within the cluster.

Point-to-Point Measurement for High Precision

The defining feature of White Shark is its use of point-to-point measurement. Unlike traditional tools that provide broad averages, White Shark retrieves specific metrics—including latency, throughput, and jitter—directly between two communication endpoints. This socket-level approach bypasses the “fog” created by virtual network overlays and high-level abstractions, ensuring that the captured data reflects the actual communication experience of the microservices. This high-fidelity data is essential for differentiating between standard network fluctuations and subtle anomalies.

Driving Intelligence: The Link to NADA

The precision of White Shark is not just for monitoring performance; it is the essential fuel for NADA (Network Anomaly Detection AI). By providing a continuous stream of verifiable point-to-point data, White Shark allows NADA to analyze temporal and contextual patterns with extreme accuracy. Together, they form a proactive security loop: White Shark captures the “ground truth” of the network, and NADA interprets that truth to identify, ensuring the CyberNEMO environment remains resilient and secure.

The transition from the NEMO project to CyberNEMO marks a critical evolution in how we approach network visibility within distributed systems. In the original NEMO project, the primary challenge was establishing reliable performance monitoring across diverse infrastructure. Our response, developed by UPM within the networking work package, was White Shark. White Shark was designed as a network probe, focusing on the fundamental socket layer to measure point-to-point communication metrics like latency, throughput, and jitter. This provided a foundational level of observability, allowing operators to understand how the network was performing at any given moment.

However, as we moved into CyberNEMO, the landscape shifted dramatically. The emergence of a true “computing continuum”—spanning Cloud, Edge, and IoT devices—introduced complexity and a expanded attack surface. Simple performance monitoring was no longer sufficient. We realized that the massive stream of high-fidelity network telemetry generated by White Shark was not just performance data; it was a rich, untapped source of security intelligence. The data that previously told us if the network was fast, could now tell us if the network was being compromised.

This realization led to the development of the NADA (Network Anomaly Detection AI) component in CyberNEMO. NADA represents the intelligent brain that sits atop the White Shark sensing layer. Its purpose is to ingest the granular, socket-level data captured by the probe and use advanced machine learning algorithms to identify temporal and contextual anomalies.

The journey from NEMO to CyberNEMO is therefore characterized by a shift from reactive performance observation to proactive, AI-driven security validation. By enriching the data previously used only for network optimization, we have created a robust mechanism for enforcing Zero Trust principles by design. This evolutionary step ensures that CyberNEMO doesn’t just provide a high-performance network, but a verifiably secure and resilient foundation for the next generation of meta-operating systems.

In a standard Kubernetes (K8s) deployment, the sheer level of abstraction is a double-edged sword. While it simplifies orchestration, it often obscures the granular reality of network traffic. For the CyberNEMO project, specifically within WP2, we move past these high-level views to focus on the network socket. Why? Because sockets represent the “ground truth” of connectivity. In a distributed meta-OS, understanding the real-time state of point-to-point communication is the only way to ensure Cybersecurity and Privacy by Design.

Capturing the “Ground Truth” with White Shark

Traditional Kubernetes monitoring often looks at service-level averages, which can mask micro-bursts of latency or intermittent failures. By monitoring at the socket level, our White Shark probe can collect raw, high-fidelity data—including latency, throughput, and jitter—directly from the source. This allows us to see exactly how data moves between specific pods, bypassing the “fog” of virtualized overlays. This level of precision is essential for building a verifiable data plane, ensuring that every packet follows its intended path without manipulation.

Building a Stronger Zero Trust Foundation

Ultimately, focusing on sockets supports the Zero Trust principle of “explicit verification”. In CyberNEMO, we don’t just trust that a connection is secure because it’s inside the cluster. Instead, we use socket-based telemetry to constantly validate that communication patterns match the intended security policies.