AKS clusters with no network policy engine, so pod-to-pod traffic is unrestricted
What does ZopNight detect here?
ZopNight flags an AKS cluster when its `networkProfile.networkPolicy` reports no engine, which Azure documents as the default when none is chosen. With no Azure NPM, Calico or Cilium engine, Kubernetes NetworkPolicy objects are accepted but never enforced, so every pod can reach every other pod. Severity is high and no saving applies.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1350 |
| Category | compliance |
| Severity | high |
| Metric | none — pure configuration read |
| Threshold | networkPolicy none or unset |
| Source | ZopNight |
| Permissions used | Microsoft.ContainerService/managedClusters/read |
Where it applies
NetworkPolicy objects need an engine to mean anything
Kubernetes lets you write NetworkPolicy resources that allow or deny traffic between pods, but
the API server only stores them. Enforcement comes from a network policy engine running on the
nodes. The AKS managed cluster API
describes the none value plainly: network policies will not be enforced, and it is the
default when no policy engine is specified.
On such a cluster a compromised pod in one namespace can open connections to databases, internal APIs and metadata services in every other namespace. The blast radius of any single vulnerable container is the whole cluster network.
Listing clusters without an engine
az aks list \ --query "[].{name:name, rg:resourceGroup, policy:networkProfile.networkPolicy}" \ -o tableAn empty or none value in the policy column means no engine. azure, calico or cilium
means one is installed.
The condition behind the finding
ZopNight reads the network policy value Azure reports for the cluster and fires when it is
none or missing, since no value at all is the AKS default. Nothing else is weighed: no traffic data, no count of
NetworkPolicy objects, no window. A cluster with an engine but zero policies is not flagged by
this check, because the capability to segment is present.
Clusters the check skips
Tags on the cluster describing its network policy are ignored. Traffic rules enforced outside Kubernetes NetworkPolicy, for example by a service mesh, are invisible to this check, which is the usual reason to dismiss a finding.
Blast radius, not a bill
The rule is rated high and carries no dollar figure. The exposure is lateral movement: without enforcement there is no way to express, let alone guarantee, that the payments namespace is unreachable from a public-facing frontend.
Choosing and installing an engine
Microsoft’s network policy guide recommends Cilium for its eBPF data plane and Layer 7 and FQDN features. Azure Network Policy Manager is being retired: on Windows nodes from 30 September 2026 and on Linux nodes from 30 September 2028. Azure NPM also does not support scaling beyond 250 nodes and 20,000 pods.
- For Linux clusters on Azure CNI Overlay or Azure CNI with dynamic IP allocation, move to
Azure CNI Powered by Cilium by updating the network data plane (
--network-dataplane cilium), following the upgrade prerequisites. - Otherwise install an engine in place:
az aks update --resource-group my-rg --name my-aks --network-policy calico. - Start with allow rules that match today’s traffic, then add a default-deny policy per namespace.
- Test each namespace after its policies land.