Enterprise-Grade Network Security Policy for Kubernetes: FNS Comes to Flow CNI

Introduction

Nutanix Flow Network Security (FNS) is the policy engine behind Nutanix's network security model: AppType policies define what an application is allowed to talk to, and Isolation policies draw hard boundaries between environments. Either can run in monitor mode to observe traffic before you commit, or in enforce mode once you're confident. Until Flow CNI, that full security model only reached VM workloads on AHV.

Where you're coming from changes what this release means to you, but not what you get:

• If you already run FNS on VMs, that same posture, same policy types, same modes, same enforcement capabilities, now extends to Kubernetes® pods, including in hybrid deployments where a single policy governs traffic between a VM tier and a container tier together. Nothing new to learn, no separate framework to maintain, and no need to write one policy for the VM side and another for the container side of the same application.

• If you're Kubernetes-only, no AHV footprint, no existing FNS deployment, possibly hearing "FNS" for the first time, this is still relevant to you. You don't need any VMs to use it: apply AppType or Isolation policies to your pods, and you get the same network-layer enforcement described below, entirely within Kubernetes. There's no VM/container unification step required to benefit from this.

The problem this solves

Some Kubernetes environments today rely on NetworkPolicy, a single, comparatively thin policy model: software-enforced, label-matching, with the structural weakness already covered above, where a misconfigured rule or missing label can silently open traffic that should have been blocked.

FNS brings two things Kubernetes doesn't get from NetworkPolicy alone.

A richer policy model. FNS gives you AppType and Isolation policies, each running in monitor or enforce mode, four distinct capabilities that let you observe traffic before committing to block it, then move to enforcement with confidence. Traditional CNIs' NetworkPolicy support comes closest to just one of these four, roughly comparable to AppType policy in enforce mode, with no equivalent for the other three, including the staged monitor-mode rollout that matters most for a real compliance process. FNS covers more of the policy lifecycle, not just the end state.

Policy that spans VM and container workloads together. This is new, not an extension of something that already exists elsewhere, a single policy can govern traffic across VM and container endpoints in one rule. If you already run FNS on VMs, this is the first time that exact posture with all set of features extends to Kubernetes; if you're Kubernetes-only, the same policy model is available to you just as fully. Either way, this is what Workload Federation makes possible (more on that below).

That means container workloads either go unmonitored by a policy-driven, audited security model, or your team builds and maintains a custom framework just to get equivalent coverage.

What FNS on Flow CNI changes

Flow CNI delivers full FNS policy parity for container workloads. AppType and Isolation policies now work on pods and services, in both monitor and enforce mode, all four combinations, addressing the gap with the other CNIs completely.

Practically, this means:

• The same policy types. AppType policies (what an application is) and Isolation policies (what it's allowed to reach) apply to pods, whether or not there's a single VM anywhere in the environment.
• The same modes. Monitor mode lets you observe live traffic against a proposed policy before anything is blocked. Enforce mode turns that policy into an active boundary.
• A standard rollout workflow. Roll out a policy in monitor mode, watch traffic for a representative period, address the surprises, then flip to enforce.
• No new mental model if you're coming from VMs. If your team already thinks in AppType and Isolation policies, there's nothing new to learn. The semantics are identical; only the workload type changed.
• One central place to manage it. Policies are configured from Prism Central, Nutanix's control plane, regardless of whether the cluster in question runs any VMs at all.
• Seamless policy enforcement across a mixed VM and container environment. Policies span both VMs and pods. Configure once, with the appropriate labels or categories, and any change in the infrastructure is handled automatically by Flow CNI. New workloads spawning, IPs changing: those updates propagate across both worlds without anyone touching the policy. This works cleanly because VM-to-pod and VM-to-service traffic within a federated VPC skips NAT and load balancing entirely, so both endpoints see each other's real IP, FNS policies apply end-to-end, against actual endpoints, not a proxy standing in for them.

How policy targeting works

FNS policies have always targeted VMs through categories, labels attached to a VM that a policy's rules reference. Flow CNI extends the same mechanism to Kubernetes: you can specify labels on Kubernetes: the kube entity group, along with a VM category or VM entity group, can be referenced together within the same AppType or Isolation policy, as separate rule members.

This matters operationally: a security team can write a single policy that governs traffic between a VM tier and a container tier, without needing two separate policy objects on two separate systems. The naming primitive differs by workload type, category on the VM side, label on the Kubernetes side, and so does the grouping mechanism, but the policy itself is what unifies them.

Seamless enforcement across a mixed VM and container environment

Policy enforcement across VM and container environments is difficult, sometimes impossible, for a basic reason: pod traffic typically gets NAT'ed by the time it reaches a VM, and the pod loses its original identity in the process. A policy engine can only enforce against what it can actually see. If all it sees is a translated gateway address, it can't write or enforce a rule against the actual pod that originated the traffic.

This is where extending the overlay network across the two environments helps. By Workload Federation, the Flow CNI extends an overlay network between pods and VMs, so pod and service private IPs are retained when that traffic reaches a VM, no NAT, no external load balancer in the path. Both endpoints see each other's real IP address, not a translated or proxied one.

That matters for policy specifically: because the path stays direct, FNS policies can apply end-to-end, against the actual endpoints, rather than against a proxy standing in for them. And because FNS policies reference categories rather than IPs, policy membership resolves dynamically against whatever currently carries the category, add a pod, remove a VM, scale a tier up or down, and the policy doesn't change, because it was never written against an individual workload's address to begin with.

That's what makes one-time policy configuration possible: configure once, with the appropriate labels or categories. New workloads spawning, IPs changing, those updates are streamlined across both environments, minimizing the need for manual policy adjustments.

Creating a policy from Prism Central

Prism Central is the primary interface for this, it follows the same guided pattern as VPC creation, no YAML required.

Step 1: Create an entity group for the Kubernetes pods or services you want to target. This is the same category/group mechanism FNS has always used to target VMs, now available against pod and service entities too.

Step 2: Create a policy scoped to a VPC, selecting the specific VPC it should apply within, for example, team-alpha. Scoping the policy to a VPC keeps it aligned with the isolation boundary you've already set up: the policy governs traffic inside that VPC, not across it. Choose a policy type, Shared Services, Isolation, or Application, depending on what you're trying to control. This VPC can be container-only, there's no requirement to federate with VMs, or to have any VMs at all, for this step or any step after it.

Step 3: Configure the secured entities, inbound, and outbound rules. The policy shows the entity group you created as the secured entity, along with configured inbound sources and outbound destinations.

Step 4: Once the policy exists, confirm exactly what it's applying to. Clicking into a secured entity resolves it down to the actual pods currently matched, a direct way to confirm you're targeting what you think you're targeting before anything is enforced.

Step 5: Set the policy to monitor mode first. Watch traffic against it, Prism Central shows discovered traffic against the policy's rules, confirm nothing unexpected is being flagged, then switch the same policy to enforce mode. The mode is a toggle on the existing policy object, not a separate policy to create.

This is the same staged monitor-to-enforce workflow FNS has always used for VM policies, walked through here against pod and service entities, and it pairs naturally with VPC scoping, since a policy created inside a given VPC never has to reason about entities outside it.

The underlying CRD: ApplicationPolicy

Both AppType and Isolation policies ship in this release, but this section focuses on the ApplicationPolicy object specifically, the CRD behind AppType policies, for teams who manage infrastructure through GitOps rather than the PC UI. Here's what one looks like on a running cluster:

A few things worth calling out, taken directly from the object above:

• mode is MONITOR or ENFORCE, and switching between them is the same staged rollout described above, no need to recreate the policy, just flip the mode.
• vpc references the policy's VPC by UID, tying the policy to the same VPC boundary set up for isolation. The policy governs traffic inside that VPC.
• Each rule pairs a securedEntity with an endpoint match. securedEntity is defined by a namespace selector plus a pod label selector, the same targeting primitive used elsewhere in Flow CNI. A rule can allow traffic to ALL, scope it to a specific dstEndpoint, or allow traffic freely within the secured entity itself via allowTrafficWithinSecuredEntity.
• PC auto-generates some rules for you. A policy created through the UI typically includes more rules than you'd hand-write, for example, an explicit rule permitting DNS resolution against kube-system/kube-dns on the expected ports, so a monitor-mode policy doesn't immediately start flagging basic cluster services as unexpected traffic.
• Status conditions confirm enforcement, not just declaration. kubectl describe on the policy shows conditions like ACLUpdateSuccess and PortGroupUpdateSuccess, useful for confirming the policy's rules actually made it into the data plane, not just that the object was accepted by the API server.
• Coverage isn't limited to simple pod-to-pod traffic. Policies apply regardless of whether the pod is the source, the destination, or the entity being secured, matching FNS behavior for VMs.
• Policies work in both container-only and federated VPCs. Whether pods live in a container-only VPC or a federated VPC alongside VMs, the same AppType and Isolation policies apply consistently.

Isolation policies are a separate object type (isolationpolicies) with their own CRD, outside the scope of this walkthrough, but the same PC workflow and monitor/enforce staging applies to them as well.

Why this matters beyond checkbox parity

The value here isn't just “containers now have security policies”, plenty of CNIs offer network policy of some kind. The value is a full policy-driven, audited security model that's consistent across your infrastructure, not conditional on running Nutanix VMs. That has real operational consequences:

• One policy language across your infrastructure, whether that's containers only or containers and VMs together.
• One audit trail, not a VM audit and a separate Kubernetes audit that need to be reconciled, or no audit trail at all if you were relying on label-matching NetworkPolicy alone.
• One team's expertise applies everywhere, instead of requiring container-specific security specialists.

For any customer already running FNS on VMs, this is the first time that exact posture, same policy types, same modes, same enforcement guarantees, extends to Kubernetes without asking anyone to learn a new model or accept a smaller set of controls.

A note on precision

It's worth being exact about what's being compared here, especially in any competitive conversation. The claim is not that “other CNIs don’t support security policies”. The precise claim is narrower and more useful: FNS specific policy types, AppType and Isolation, in monitor mode, are not supported on other common CNIs, where often only limited policy combinations are available. Flow CNI supports all four. That's the comparison that matters to a security team evaluating real coverage, not marketing shorthand.

Where this shows up in practice

A Kubernetes-only environment, no VMs anywhere. None of this requires an existing Nutanix VM footprint. A team standing up Kubernetes for the first time on Nutanix infrastructure can create a container-only VPC, apply AppType or Isolation policies to it, and get network-layer-enforced security policy from day one, without ever touching AHV, and without needing to understand or care about VM/container parity as a concept. The “one policy plane” story matters if you're bridging VMs and containers; if you're not, you still get the same policy engine, monitor/enforce workflow, and PC-managed configuration on its own merits.

A staged compliance rollout across a mixed VM/container estate. A security team running FNS on VMs today can roll the exact same policy, same category, same policy type, onto a namespace of pods in monitor mode, watch traffic for a representative period, then flip to enforce. Because it's the same policy object type and the same modes, there's no separate Kubernetes-specific rollout process to design.

Microsegmentation on bare metal. FNS/CNS policy enforcement doesn't depend on a hypervisor, enforce mode, monitor mode, AppType, and Isolation policies all work the same way on bare-metal Kubernetes nodes as they do on AHV-based deployments. For teams running Kubernetes directly on bare metal for performance reasons, this means the same policy posture is available without needing a virtualization layer underneath it.

Migrating off other CNIs without losing coverage. Because targeting uses the same category mechanism as VM policies, a team moving workloads from a third party Kubernetes cluster can bring their existing FNS category taxonomy with them rather than re-deriving policy from the source CNI’s rules.

Pairing with VPC isolation

FNS and VPC isolation solve adjacent problems. VPC isolation is the hard network boundary between tenants, it decides whether one namespace can reach another's at all, enforced at the network layer regardless of policy. FNS's AppType and Isolation policies control what's allowed to happen within that boundary, which application tiers can talk to which, monitored first and enforced once you're confident. Used together, VPC isolation stops cross-tenant traffic outright, and FNS governs the traffic that's supposed to be there.

Verifying it yourself

The quickest way to see this working depends on where you're starting from:

• If you already run FNS on VMs, take a policy you already use and point it at a namespace of pods instead: apply the same category to a test pod, create the equivalent AppType or Isolation policy in monitor mode targeting that category, and confirm traffic shows up in discovered traffic the same way VM traffic would.
• If you're starting fresh, create a container-only VPC, label a namespace and a test pod with a category, create an AppType or Isolation policy in monitor mode scoped to that VPC, and generate some traffic to and from the pod.

Either way: confirm the traffic appears in discovered traffic while in monitor mode, then flip the policy to enforce mode and confirm traffic outside the allowed rule is blocked.

If you're comparing against a Cilium baseline, the useful check is specifically whether AppType monitor mode, Isolation monitor mode, and Isolation enforce mode are available at all, on Cilium they aren't; on Flow CNI they behave identically whether the workload is a pod or a VM.

Getting started

• Review the FNS + Flow CNI field one-pager for the full policy combination matrix.
• Run the policy parity demo with your Nutanix SE to see monitor-to-enforce in action against a live cluster, whether or not VMs are part of your environment.

Flow CNI is available now, included with NCI Pro at no additional cost. If you already run FNS, this is your existing posture, extended to containers. If you don't, this is a full security policy engine available to you from the moment you stand up a Kubernetes cluster on Nutanix.

Minimum versions

©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).