About the NetworkPolicy Generator
By default every pod in a Kubernetes cluster can reach every other pod in every namespace. NetworkPolicy is how that gets narrowed, and this generator builds the manifest with the selectors and port rules in the right shape.
Two behaviours account for most of the confusion. First, policies are additive and there is no deny rule — a pod is unrestricted until at least one policy selects it, and from that moment only what some policy explicitly allows is permitted. Second, the ingress and egress directions are independent: a policy listing only ingress rules leaves egress completely unrestricted, and a policy whose policyTypes names egress with no rules blocks all outbound traffic, including DNS.
That last point is the single most common outage this feature causes. A default-deny egress policy that forgets to allow UDP and TCP port 53 to kube-dns breaks name resolution for every selected pod, and the symptom looks like a total application failure rather than a network policy problem.
Frequently asked questions
Why is my NetworkPolicy not blocking anything?
Almost always because the CNI plugin does not enforce them. NetworkPolicy is an API that the network plugin must implement, and the API server accepts the object regardless. Flannel has no support at all, so policies apply silently and do nothing. Calico, Cilium, Weave, and the major managed offerings do enforce them — check which plugin the cluster actually runs before debugging the rules.
How do I create a default-deny policy for a namespace?
Apply a policy with an empty podSelector, which selects every pod in the namespace, and a policyTypes list naming the directions to lock down, with no matching rules. Add allow policies afterwards. If you deny egress, add an allow rule for DNS to kube-dns on port 53 in the same change — otherwise every pod in the namespace loses name resolution the moment the policy lands.
What is the difference between podSelector and namespaceSelector?
Within a rule, podSelector matches pods in the policy's own namespace, while namespaceSelector matches whole namespaces by label. Combining them inside a single from or to entry means both must match, which selects specific pods in specific namespaces. Listing them as two separate entries means either may match, which is a much broader grant — the indentation difference is subtle and easy to get wrong.
Can a policy match traffic by IP address?
For external addresses, yes, through an ipBlock with an optional list of exceptions. For pod-to-pod traffic you should always use label selectors instead, because pod IPs are reassigned constantly and any rule pinned to one is wrong as soon as the pod restarts. Note that ipBlock rules are evaluated against the source address the plugin sees, which may already be translated.
Do NetworkPolicies apply to traffic from outside the cluster?
It depends on the path and the plugin. Traffic arriving through an ingress controller is usually seen as coming from the controller's pod, so a rule allowing that pod is what matters rather than a rule about the original client. Traffic through a LoadBalancer or NodePort may have its source address translated to a node address before policy is evaluated, which changes which rule matches.