How to use
What it is
Paste your Kubernetes manifests (or the output of kubectl get pods,netpol,svc,ns -A -o yaml, or of helm template) and it works out which pod can connect to which according to their NetworkPolicies, with the port. Click a cell to see why: which policy isolates each side and which rule lets the traffic through. It also flags what leads nowhere: Services without pods, ConfigMaps or Secrets that are missing, policies that select nothing.
The rules almost everyone gets wrong
A pod that no policy selects is NOT isolated: everything reaches it. For a connection to go through, the source’s egress AND the destination’s ingress must allow it. Without policyTypes, a policy always affects ingress, and egress only if it has an egress section. And namespaceSelector with podSelector in the SAME element is “and”; in separate elements, “or”.
Pod Security Standards
For each workload, the highest level it meets (baseline or restricted) and what it is missing for the next one, with the rules of the official Kubernetes 1.37 admission controller. If a namespace declares pod-security.kubernetes.io/enforce, it flags the workloads that namespace would REJECT on creation, which is a silent failure: the Deployment is created and its pods are not. Checked against the controller’s own 4,537 test cases and against its library on more than 700 real workloads.
What a compromised pod could do
If you also paste your Role, ClusterRole and bindings, each workload shows what its ServiceAccount can do from the list of escalation risks in the official Kubernetes guide (read secrets, create pods, exec, nodes/proxy, escalate, bind, impersonate…), in which scope and which binding grants it. And whether the token is mounted in the pod: without a token, compromising the pod does not give those permissions. It uses the same engine as the Access lab. It does not evaluate resourceNames: a permission on ONE secret shows up as “read secrets” — overestimated, never hidden.
Schema validation
It checks each object against the OFFICIAL schema of the Kubernetes version you choose (from 1.33 to 1.37): fields that do not exist, with the one you probably meant, wrong types (an “80” in quotes where a number goes), missing required fields and retired apiVersions, with the version in which they disappeared and which one to migrate to. The schema is downloaded only when validating and only for that version: about 9 KB. Checked against kubeconform in strict mode on more than a thousand manifests, real ones and with injected errors.
How far can you trust it?
It follows the official NetworkPolicy specification, and its results have been checked against netpol-analyzer (np-guard) on more than a hundred scenarios from its own repository. What it does NOT compute: each CNI’s own policies (CiliumNetworkPolicy, Calico), AdminNetworkPolicy, or traffic from the node itself, which always goes through. If your CNI does not enforce NetworkPolicy, none of them does anything.
