Introduction

In today's dynamic hybrid cloud and Kubernetes® environments, traditional security and network monitoring tools are hitting their limits. With IP ephemerality making static rules obsolete, and AI workloads remaining opaque to standard Endpoint Detection & Response (EDR), Platform Engineering teams need a new approach that offers highly accurate visibility with minimal latency impact.

Today, we are taking one more step ahead in integrating Nutanix Flow and eBPF with our established OVS-based networking data path to build a "secure kernel" dedicated to every workload. As part of this vision, we are delighted to say that Retina and Tetragon have officially achieved Nutanix Ready Validation for Flow CNI on the Nutanix Kubernetes Platform (NKP) solution. This testing by the Nutanix Ready validation team is designed to support seamless interoperability, enterprise-grade stability, and non-invasive kernel security out of the box. This milestone unlocks a new era of programmable, non-invasive security rooted directly in the kernel.

The Power of eBPF: Why Does It Matter?

Extended Berkeley Packet Filter (eBPF) is a Linux kernel technology that allows developers to run small, sandboxed programs safely within the kernel. Originally designed for packet filtering, eBPF has evolved into a general-purpose mechanism for observing and controlling kernel behavior. 

To support microsegmentation and networking use-cases, Nutanix Flow utilizes the eBPF ring buffer mechanism for both Flow Virtual Networking as well as Flow Network Security, to help ensure vNIC-to-IP mapping.

This provides three critical advantages for modern architectures:

  1. Non-Invasive: No application code changes or restarts required.
  2. Low Overhead: Safely runs in the kernel space; designed for AI/GPU latency.
  3. Enhanced Accuracy: Bypasses compromise at the user-space/container level.

Introducing Unified Zero Trust

By combining eBPF as the intelligent sensor with Nutanix Flow as the security brain, you establish a comprehensive Zero Trust Foundation directly inside the Linux kernel:

  • Verify Explicitly: Moves past traditional IP-based assumptions by continuously validating the running Process Identity, Kubernetes orchestration metadata, and User Context before allowing packets to traverse the Nutanix Flow network fabric.
  • Least Privilege Enforcement: Security is restricted deep within the kernel down to the individual Syscall and File-path level, designed to help prevent malicious binaries from gaining access to underlying data pipelines or sensitive AI model files.
  • Assume Breach Architecture: Using continuous, low-overhead runtime monitoring, the system detects and flags anomalous behaviors in real time. If a container or pod is compromised, the eBPF sensor instantly notifies the Flow control plane to quarantine the workload, helping to mitigate threats before lateral movement can occur and is designed to help safeguard proprietary AI models.

Elevating Network Security Across Critical Pillars

This kernel-native approach redefines the competitive edge over traditional security methods across five critical pillars:

Capability Traditional Agents Nutanix Flow & eBPF
Performance Low High
Deployment Requires binary per distribution Universal via Kernel Hooks
Visibility Application level only Full Stack (L4 - L7 + Kernel)
Maintenance Frequent re-instrumentation Transparent / No restarts
AI Support Limited / Non-GPU aware Deep GPU/Driver Observability

Table 1: Traditional agents vs. Nutanix Flow & eBPF

What does this mean for Your Business and Engineering Teams?

While technologies like eBPF, Tetragon, Retina, and Hubble bring impressive kernel-level capabilities, the real value lies in the practical impact on your organization's security posture, performance, and operational efficiency:

  • For Platform Engineers & SREs: Minimizing "Blind Spots" Without CPU Overhead: Traditional security agents often demand 15% to 20% CPU utilization, creating friction between security and performance teams. By moving enforcement and telemetry down into kernel hooks, you get full-stack visibility (L4-L7 + Syscalls) with minimal CPU overhead. You no longer have to choose between rich network observability and application performance.
  • For Security & CISO Teams: True Zero Trust Built into the Kernel: IP addresses are ephemeral, and traditional perimeter defenses fail once a container is breached. By inspecting process execution, file accesses, and privilege changes directly inside the Linux kernel, you gain highly accurate monitoring. Threats like shell spawning or unauthorized access to sensitive data are blocked at the source before lateral movement can occur.
  • For AI & Modern Workload Teams: Protecting Invisible Data Pipelines: AI workloads rely heavily on specialized GPU/driver interfaces that traditional Endpoint Detection and Response (EDR) agents may have limited visibility into. Kernel-level eBPF monitoring gives teams visibility over GPU data flows, designed to help safeguard proprietary AI models, weights, and training datasets against exfiltration without requiring any modifications to your application code.
  • For Ops & Incident Response: Minutes to Troubleshoot Instead of Hours: When networking issues occur, debugging usually requires SSHing into individual nodes to manually capture traffic with tcpdump. With CNI-agnostic observability and native Grafana/Prometheus metrics, teams can trigger cluster-wide, live packet captures via a single CLI command. This helps streamline incident response for service disruptions.

Key Benefits of the Unified Stack

Runtime Security Enforcement with Tetragon

While standard RBAC and IP-based trust give you a foundation, they provide limited visibility into what processes actually do once they are running. 

Tetragon steps in to act as a runtime shield, enabling behavior-based enforcement down to the syscall and file-path level :

  • Process Blacklisting: Helps block binaries that attempt shell spawning or unauthorized malware execution.
Figure 1: Process Blacklisting using Tetragon Figure 1: Process Blacklisting using Tetragon

 

  • Filesystem Audit: Monitoring and blocking access to sensitive paths (like credentials or host mounts) directly at the kernel level.
  • Monitoring Privilege Escalations: In Linux environments, processes have various credentials such as user and group IDs, capabilities, and security flags that define their privileges. Threat actors frequently exploit these credentials to escalate privileges or circumvent security controls. Without real-time visibility into these changes, security teams are left blind to critical signs of compromise.
    • Tetragon addresses this challenge by providing real-time monitoring of process credentials at both the system call and kernel levels. By hooking into system calls that manipulate credentials, Tetragon can capture detailed information about which processes or containers are attempting to change user IDs, group IDs, or capabilities.

 

Figure 2: Monitoring Privilege Escalation Figure 2: Monitoring Privilege Escalation
  • Tetragon Policy Events: Tetragon’s events can be exposed to the system through either the gRPC endpoint or JSON logs. Tetragon’s TracingPolicy is a user-configurable resource that allows users to trace events in the kernel and optionally define actions to take on a match. Policies consist of a hook point e.g.- kprobe as shown below for in-kernel filtering.
Figure 3: Tetragon Policy Events Figure 3: Tetragon Policy Events
Figure 4: tcp_connect call being tracked via a kprobe Figure 4: tcp_connect call being tracked via a kprobe

CNI-Agnostic Observability with Retina

Nutanix Flow CNI is built on the robust OVN-Kubernetes architecture. One of the standout advantages of Retina; an open-source Kubernetes Network Observability platform by Microsoft, is that it is completely CNI-agnostic. 

By deploying Retina using the Hubble control plane on an NKP cluster running Flow CNI, the integration is seamless. The eBPF kernel hooks simply tap into the existing network fabric without requiring a rip-and-replace of your CNI, providing distributed packet captures for deep-dive troubleshooting with a minimal CPU overhead.

Rich Telemetry Visualizations with Hubble

Utilizing Cilium's Hubble as the control plane for Retina unlocks a treasure trove of actionable telemetry gathered at both the Node and Pod levels. These industry-standard Prometheus metrics can be natively exported to Prometheus and visualized in Grafana, enabling teams to pinpoint network issues with forensic accuracy.

When Retina is deployed with the Hubble control plane, the metrics include Node-level and Pod-level. Metrics are stored in Prometheus format, and can be viewed in Grafana.

Types of Metrics:

  • Node-Level Metrics: (networkobservability_* prefix)
    • These metrics provide insights into traffic volume, dropped packets, number of connections, etc. by node.
Figure 5: Node-Level Metrics Figure 5: Node-Level Metrics
  • Hubble Metrics (DNS and Pod-Level Metrics): (hubble_* prefix)
    • These metrics include source and destination pod information allowing to pinpoint network-related issues at a granular level.
    • Metrics cover DNS queries/responses, L4/L7 packet flows, dropped packets, and TCP flags.
  • L4-L7 Packet Flows: Real-time visibility into service-to-service mapping and communication.
Figure 6a: L4-L7 Packet Flows Figure 6a: L4-L7 Packet Flows
Figure 6b: L4-L7 Packet Flows Figure 6b: L4-L7 Packet Flows
  • DNS Insights: Tracking DNS queries, missing responses, and error spikes.
Figure 7a: Tracking DNS queries Figure 7a: Tracking DNS queries
Figure 7b: Top Pods with DNS Errors Figure 7b: Top Pods with DNS Errors
  • Network Health: Deep analytics on TCP resets, dropped packets, and API Server latency via Hubble CLI and Hubble UI.

[root@localhost ~]# hubble observe --since 1m -t l7
Mar 10 05:36:25.088 [hubble-relay-6b7c54d9ff-xk7nw]: 3 nodes are unavailable: nkp-wrkld-new-t7d75-7njq8 (and 2 more)
Mar 10 05:35:26.097: default/xwing (ID:2639) -> 
Mar 10 05:35:26.101: default/xwing (ID:2639) -> kube-system/coredns-668d6bf9bc-b6vgb (ID:26378) dns-request  FORWARDED (DNS Query deathstar.default.svc.cluster.local.cluster.local. AAAA)
Mar 10 05:35:26.102: default/xwing (ID:2639) <- kube-system/kube-dns (world) dns-response  FORWARDED (DNS Answer RCode: Non-Existent Domain (Query deathstar.default.svc.cluster.local.cluster.local. AAAA))
Mar 10 05:35:26.102: default/xwing (ID:2639) <- kube-system/kube-dns (world) dns-response  FORWARDED (DNS Answer RCode: Non-Existent Domain (Query deathstar.default.svc.cluster.local.cluster.local. A))
Mar 10 05:35:26.102: default/xwing (ID:2639) -> kube-system/coredns-668d6bf9bc-b6vgb (ID:26378) dns-request  FORWARDED (DNS Query deathstar.default.svc.cluster.local. A)
Mar 10 05:35:26.102: default/xwing (ID:2639) -> kube-system/coredns-668d6bf9bc-b6vgb (ID:26378) dns-request  FORWARDED (DNS Query deathstar.default.svc.cluster.local. AAAA)
Mar 10 05:35:26.102: default/xwing (ID:2639) <- kube-system/kube-dns (world) dns-response  FORWARDED (DNS Answer  (Query deathstar.default.svc.cluster.local. AAAA))
Mar 10 05:35:26.103: default/xwing (ID:2639) <- kube-system/kube-dns (world) dns-response  FORWARDED (DNS Answer "10.x.x.151" (Query deathstar.default.svc.cluster.local. A))
Mar 10 05:35:27.466: default/xwing (ID:2639) -> kube-system/coredns-668d6bf9bc-hls59 (ID:26378) dns-request  FORWARDED (DNS Query deathstar.default.svc.cluster.local.default.svc.cluster.local. A)
Mar 10 05:35:27.466: default/xwing (ID:2639) -> kube-system/coredns-668d6bf9bc-hls59 (ID:26378) dns-request  FORWARDED (DNS Query deathstar.default.svc.cluster.local.default.svc.cluster.local. AAAA)

Snippet 1: Network Health Monitoring with Hubble CLI

Figure 8: Network Health monitoring with Hubble UI Figure 8: Network Health monitoring with Hubble UI

Live In-line Packet Captures

Retina enables distributed packet captures for deep-dive troubleshooting across the entire cluster. 

  • Instead of manually SSHing into nodes to run tcpdump, administrators can trigger cluster-wide, on-demand captures via a single CLI command or CRD.

./kubectl-retina-linux-amd64 capture create   --name example-single-pod   --namespace default   --pod-names "pod1"

./kubectl-retina-linux-amd64 capture download --all -o /tmp/
  • This pulls in critical metadata like Iptables rules, socket statistics, and kernel network info.

####Output Truncated#############

Chain OVN-KUBE-NODEPORT (2 references)
    pkts      bytes target     prot opt in     out     source               destination
       0        0 DNAT       6    --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL tcp dpt:32580 to:10.x.x.x:443
       0        0 DNAT       6    --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL tcp dpt:31168 to:10.x.x.x:80
       0        0 DNAT       6    --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL tcp dpt:32561 to:10.x.x.x:5000
       0        0 DNAT       6    --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL tcp dpt:30671 to:10.x.x.x:8085


####Output Truncated#############

10.x.x.x/x via 192.168.3.1 dev ovn-k8s-mp0 table 7
default via 10.x.x.x dev brens3 table 1006 mtu 1400
unreachable default table 1006 metric 4278198272
10.x.x.x/x via 169.254.0.4 dev brens3 table 1006 mtu 1400
20.0.0.0/16 via 20.0.4.1 dev ovn-k8s-mp2 table 1006
20.0.4.0/24 dev ovn-k8s-mp2 table 1006 proto kernel scope link src 20.0.4.2
local 20.0.4.2 dev ovn-k8s-mp2 table 1006 proto kernel scope host src 20.0.4.2
broadcast 20.0.4.255 dev ovn-k8s-mp2 table 1006 proto kernel scope link src 20.0.4.2
169.254.0.3 via 20.0.4.1 dev ovn-k8s-mp2 table 1006
169.254.0.14 dev ovn-k8s-mp2 table 1006 mtu 1400
default via 10.x.x.x dev brens3 proto dhcp src 10.x.x.x metric 100
10.x.x.x/x dev brens3 proto kernel scope link src 10.x.x.x
10.x.x.x/x dev brens3 proto kernel scope link src 10.x.x.x metric 100
10.x.x.x dev brens3 proto dhcp scope link src 10.x.x.x metric 100
10.x.x.15 via 10.x.x.x dev brens3 proto dhcp src 10.x.x.x metric 100
10.x.x.16 via 10.x.x.x dev brens3 proto dhcp src 10.x.x.x metric 100
10.x.x.x/x via 169.254.0.4 dev brens3 src 169.254.0.2 mtu 1400
169.254.0.0/17 dev brens3 proto kernel scope link src 169.254.0.2
169.254.0.1 dev brens3 src 10.x.x.x


####Output Truncated#############

Netid State 	Recv-Q Send-Q    	Local Address:Port       	Peer Address:Port Process
udp   UNCONN    0  	0            	127.0.0.54:53              	0.0.0.0:* 	uid:991 ino:24036 sk:1 cgroup:unreachable:bce <->
     	skmem:(r0,rb212992,t0,tb212992,f0,w0,o0,bl0,d0)
udp   UNCONN    0  	0         	127.0.0.53%lo:53              	0.0.0.0:* 	uid:991 ino:24034 sk:2 cgroup:unreachable:bce <->
     	skmem:(r0,rb212992,t0,tb212992,f0,w0,o0,bl0,d0)
udp   UNCONN    0  	0          10.x.x.x%ens3:68                  0.0.0.0:* 	uid:998 ino:20027 sk:3 cgroup:unreachable:c82 <->
         skmem:(r0,rb212992,t0,tb212992,f0,w0,o0,bl0,d0)

Snippet 2: IPTables, IPRules, SocketStats being via runtime packet captures

Conclusion

By bringing together Flow CNI, Tetragon, Retina, and Hubble, Nutanix is ushering in an era of Zero Trust where security is programmable, non-invasive, and rooted in the absolute truth of the kernel. Whether you are managing highly ephemeral pods, stateful VMs, or opaque AI training workloads, Nutanix Flow with eBPF delivers a single pane of glass for your network and runtime security needs.

To learn more, check out our documentation:

 

©2026 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and all Nutanix product and service names mentioned are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. Kubernetes is a registered trademark of The Linux Foundation in the United States and other countries. All other brand names mentioned are for identification purposes only and may be the trademarks of their respective holder(s). Code samples and snippets that appear in this content are unofficial, are unsupported, and may require extensive modification before use in a production environment. As such, the code samples, snippets, and/or methods are provided AS IS and are not guaranteed to be complete, accurate, or up-to-date. Nutanix makes no representations or warranties of any kind, express or implied, as to the operation or content of the code samples, snippets and/or methods. Nutanix expressly disclaims all other guarantees, warranties, conditions and representations of any kind, either express or implied, and whether arising under any statute, law, commercial use or otherwise, including implied warranties of merchantability, fitness for a particular purpose, title and non-infringement therein.