NetworkPolicy Calculator
Estimate how many pod-to-pod connection paths a NetworkPolicy will allow or block.
About NetworkPolicy Calculator
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.
Formula
allowedPairs = (ingressRules + egressRules) × avgPeersPerRule × podsSelected
- R_i
- Number of ingress rules
- R_e
- Number of egress rules
- P_r
- Average peers matched per rule
- P_s
- Pods selected by the policy
- A
- Estimated allowed connection pairs
Worked example
With the default values below, NetworkPolicy Calculator returns Total NetworkPolicy Rules of 7. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Ingress Rulesaccepts 0–10,000 rules
- 4 rules
- Egress Rulesaccepts 0–10,000 rules
- 3 rules
- Pods Selected by Policyaccepts 0–1,000,000 pods
- 20 pods
- Average Peers per Ruleaccepts 0–100,000 peers
- 5 peers
Results
- Total NetworkPolicy Rules
- 7 rules
- Estimated Allowed Connection Pairs
- 700
- Ingress Share of Rules
- 57.1%
Step by step
- 1Total rules = ingress + egress= 7
- 2Estimated allowed connection pairs= 700
Assumptions and limits
- The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
What happens with zero NetworkPolicies in a namespace?
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.
Does having any NetworkPolicy block all other traffic?
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.
Why does peer selector breadth matter so much?
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.