Estimate how many pod-to-pod connection paths a NetworkPolicy will allow or block.
A NetworkPolicy's total rule count (ingress plus egress) combined with how many pods it selects and how broad each rule's peer selector is determines the effective size of the allowed-connections graph it opens up. This calculator gives a rough magnitude estimate of that connection surface — useful for sanity-checking whether a policy is more permissive than intended before applying it, since overly broad peer selectors can silently negate the intent of network segmentation.
allowedPairs = (ingressRules + egressRules) × avgPeersPerRule × podsSelected
By default, with no NetworkPolicy selecting a pod, all ingress and egress traffic is allowed (assuming the CNI supports NetworkPolicy enforcement at all) — network segmentation is opt-in and only takes effect once a policy selects the pod.
Once at least one NetworkPolicy selects a pod for a given direction (ingress/egress), only traffic explicitly allowed by policies for that direction is permitted — everything else is denied by default, so an empty or narrow policy can be more restrictive than intended.
A rule with a broad namespaceSelector or empty podSelector can inadvertently allow far more traffic than a specific rule targeting named pods — always review the effective peer set a selector resolves to, not just the rule count.