NetworkPolicy
Does ZopNight manage NetworkPolicy?
NetworkPolicies restrict pod-to-pod traffic, but only once one selects a pod: a namespace with 0 policies leaves every pod reachable from every other. ZopNight records ingressRuleCount and egressRuleCount per policy, making coverage the visible finding: which namespaces have any policy at all. Absence fails silently while misconfiguration breaks loudly.
Rules that fire on NetworkPolicy
No active rule family targets NetworkPolicy today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
A NetworkPolicy restricts which pods may talk to which, forming the cluster’s internal firewall. The type’s defining property is its default: in a namespace with no policies, every pod accepts traffic from every other pod in the cluster, and applying the first policy to a pod is what flips it from allow-all to deny-by-default.
Open by default, closed by selection
Policies do not have an explicit deny verb. A pod becomes isolated the moment any policy selects it, and from then on only traffic matching some policy’s allow rules gets through. That mechanic produces the two classic surprises: a namespace that looks locked down but has zero policies (fully open), and a freshly applied policy that breaks DNS because nobody allowed egress to the resolver once egress isolation kicked in.
Rule counts as a coverage map
Discovery records each policy’s namespace plus an ingressRuleCount and egressRuleCount. The counts distinguish the shapes that matter at inventory scale: a policy with 0 ingress rules that declares the ingress policy type is a deny-all (deliberate isolation), while higher counts describe how much allowed surface a namespace maintains. The more valuable read is the join: namespaces carrying real workloads with no NetworkPolicy at all, because in this type absence is the finding. Misconfigured policies get debugged quickly since something breaks; missing policies fail silently forever.
Enforcement depends on the CNI
A NetworkPolicy is a request, not a guarantee: the API server stores it regardless, but only a network plugin that implements the policy API enforces it. On clusters whose CNI lacks support, policies sit inert while looking authoritative in every audit. Verifying that the cluster’s network plugin enforces policy is prerequisite 1 for trusting anything else on this page. The managed offerings differ in what their default dataplanes enforce and what needs enabling.
kubectl get networkpolicy -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,POD-SELECTOR:.spec.podSelector.matchLabels,TYPES:.spec.policyTypesWhere to start when coverage is zero
The standard incremental path: a default-deny ingress policy per namespace, then explicit allows for known flows, then egress once ingress is stable. Rolled out namespace by namespace, each step is small, testable, and reversible, the property that makes teams actually finish.