Effective security requires context: building context on who (identity of a machine, human, application, etc) is performing what action (e.g. opening a file, launching into a new server, running commands, and more). Traditional network security relies on network-level identifiers like IP addresses or Kubernetes pod labels. But these are often too coarse to stop modern threats. If an attacker gains access to a container, they can use any binary inside that pod to move laterally or exfiltrate data, and standard network policies remain blind to the lower-level attacker movements. With Isovalent, Tetragon helps teams drill an entire layer deeper into the question of who for networking operations. Tetragon Network Policy hooks into the process initiating the traffic and validates the process identity behind the traffic. Now teams don't just see that a pod is talking; they see and control the context that a specific process (e.g. /usr/bin/my-app) is talking. Destination identity is another side of the same coin: by parsing DNS synchronously within the kernel, Tetragon Network Policy resolves not just the IP a process is connecting to but the domain behind it, so policies can be written against a name like internal-db.isovalent.com rather than a specific IP address. This provides security and platform teams granular policy control to enforce network security with surgical precision, so only authorized binaries initiate connections. By shifting control from the network path to binary identity, the microsegmentation strategy strengthens from a broad network boundary to a precise, process-aware defense. The need for a process & destination-aware network policy When a container is compromised, an attacker can leverage any binary inside that environment to initiate network connections. Standard network controls remain too coarse and unaware of which specific process is driving the traffic, creating a security gap. Tetragon Network Policy introduces process-level enforcement to address this and build defense in depth with microsegmentation. By defining which processes are permitted to communicate, security teams prevent attackers from using tools to exfiltrate data or move laterally. Take a payment-processing pod. It talks constantly with a ledger database and a PCI tokenization vendor, traffic that can't stop because the business depends on it. It also sits one misconfigured dependency away from a shell. If an attacker lands inside that pod, a standard network policy has already lost: the pod is allowed to reach the database, and everything running inside it (e.g. the legitimate payment binary, a compromised sidecar, a rogue script the attacker just dropped) inherits that same permission. The attacker doesn't need to break the database's authentication. They just need to run curl from a pod that already has the door open. This is the gap Tetragon Network Policy closes. Where a Kubernetes Network Policy or Cilium Network Policy governs which pod can talk to what, Tetragon Network Policy governs which binary inside that pod can talk to what. Enforcement and DNS parsing occurs directly within the Linux kernel using eBPF. This eliminates the need for sidecars or userspace proxies, significantly improving on latency and deployment complexity. This approach works consistently across Kubernetes clusters and hybrid environments (e.g. on-prem servers). Embedding microsegmentation across the fleet The granularity of microsegmentation is (as implied by the name) fundamental to its success. The deeper into the application layers you go and the more ‘micro’ you go, the more control you have to accurately describe good (allowed) and bad (blocked) behavior. Microsegmentation serves two distinct roles: proactive hardening and post-exploit containment. Zero trust and microsegmentation have reinforced securing infrastructure from inside and out. The goals of zero trust being to prevent lateral movement, reduce attack surface, and enforce boundaries across workloads. Here, we take microsegmentation (traditionally based on workload) and bring the use cases deeper into the application. Before an exploit, Tetragon Network Policy enforces a strict least-privilege posture across workloads. Security teams define exactly which binaries are authorized to communicate, removing the "default-allow" east-west behavior found inside most containers. If a binary isn't on your allowlist, it has no network access. This creates a clean, locked-down environment where only verified processes participate in the network. After an exploit, this policy becomes a containment barrier. If an attacker gains a shell, they are confined to authorized binaries. They cannot easily reach out to external command-and-control servers or scan your internal network using unauthorized tools outside the policy scope. Because the policy is tied to the binary rather than the pod, the attacker is trapped within the execution context of the compromised process. The network remains closed to them, preventing lateral movement and locking the blast radius to a single, isolated process. Protecting a pod with Tetragon Network Policy Here’s what that looks like as a TetragonNetworkPolicy for the payment pod described above. The business needs the payment-svc talking to the ledger database and the tokenization vendor around the clock, but nothing else on that Pod should ever touch the network: one binary, two destinations, everything else denied by default: The selectors scope on what identity we enforce the policy: the source of the traffic must come from Pods having an app: payment-processor label and a binary at the path /usr/bin/payment_svc. Then, the rules define the destinations' identities. First any Pod with the specific target label app.kubernetes.io/name: "ledger-db" and port 5432, this is for east-west traffic as the Tetragon agent must gather Kubernetes Pods label knowledge. Or second, an IP block, in particular here just a single IP at address 203.0.113.10 and port 443, which captures north-south traffic to an external identity. The default action defines what action to perform with all the rest of the traffic that doesn’t match the selectors and the rules [deny]. With this policy, we have specified (at the binary path level) which binaries on specific Pods are allowed to send network traffic to specific identities (at the Pods and IP levels). This means that if an attacker gets a shell in this Pod and tries curl or wget to reach anywhere, including the target ledger database itself, the kernel drops the connection before it leaves the host, because curl was never on the allow list. Reinforcing with FQDN identity That’s a great starting policy and we’ve seen a few possibilities to define identities: we can use advanced Kubernetes concepts to select local objects: labels, but also namespaces or Services, and binary path for the source of the traffic, but we are limited to IP blocks to define outside world destinations. Nowadays, IPs are often dynamically allocated, they rotate and many can point to the same identity: the “not so modern” solution to managing IP addresses manually is domain names. DNS is more durable, and more secure, since identity travels with the name instead of a point-in-time IP snapshot. Let’s combine Tetragon’s in-kernel DNS parser with the network policy to define a destination based on FQDN directly: Now the rule holds no matter how many IPs sit behind that hostname, and it works just as well for internal names like ledger-db.internal.corporate.com that never had a stable IP to begin with. While this may look simple at first glance, here are more technical details on why it’s a challenge and how Tetragon solves this. How does FQDN enforcement work? To make process-aware security usable, you need to enforce rules based on domain names (FQDNs), not just static IPs. Historically, this has been done asynchronously in userspace, since the kernel is unaware of domains and deals only with addresses. This introduces latency, race conditions, and security trade-offs for policy control. Isovalent solves this by implementing an advanced eBPF DNS parser that operates inline in the kernel. By parsing DNS requests and responses synchronously, Tetragon makes the IP-to-domain mapping available to the kernel the moment a process attempts a connection, eliminating async race conditions. The parser supports DNS A and AAAA queries and responses carried over both IPv4 and IPv6. It handles DNS name compression, correlates queries with their corresponding responses by matching the DNS transaction ID and can process up to 75 DNS answers in a single packet.1 Parsing failures are categorized and exposed as health metrics. The eBPF parser runs as an independent component and provides IP-to-domain associations to other Tetragon subsystems. Since Tetragon v1.18, DNS state is maintained separately for each Pod. This isolation prevents noisy neighbor scenarios where one rogue workload could pollute the cache for others, providing a DDoS-resistant, high-performance security layer that remains stable even under heavy load. Learn more and see Tetragon Network Policy in action Defense-in-depth that moves as fast as your workloads is the next step in runtime security. Whether you are operating in Kubernetes or across a diverse hybrid infrastructure, Isovalent provides the granular control necessary to keep your environment secure, performant, and resilient against modern threats. Tetragon Network Policy changes how teams approach microsegmentation. By moving the security boundary from the network path to the binary identity, you enforce security with kernel-level precision. FQDN extends the stability of these policies with near-zero performance impact for highly ephemeral workloads. This keeps network infrastructure restricted to traffic from validated execution contexts, containing internal threats at the source without overhead of traditional proxies or sidecars. See how Cisco and Isovalent help safeguard your global infrastructure, connect with us! 1This corresponds to the theoretical maximum that fits within an unfragmented IPv6 packet with a 1280-byte MTU and a 1232-byte UDP payload when EDNS(0) is used. Without EDNS(0), DNS over UDP is traditionally limited to 512 bytes as specified by RFC 1035, which allows approximately 30 answers.