No. A NetworkPolicy is just an object in the API. The Kubernetes documentation says network policies are implemented by the network plugin, and that creating a NetworkPolicy without a controller that implements it has no effect. A cluster can be full of policies and still allow every connection.
Why this catches teams out
kubectl accepts the policy. It shows up in listings. Nothing warns you that traffic is still flowing freely. Teams discover the gap during a penetration test or an incident, long after the YAML was reviewed.
This is a deploy-time control that needs a separate check that it works, because acceptance by the API is not the same as enforcement on the network.
What isolation means for a pod
The documentation describes two independent kinds of isolation, egress and ingress. By default a pod is non-isolated in both directions, so all connections are allowed. A pod becomes isolated for egress when any NetworkPolicy selects it and lists Egress in its policy types, and likewise for ingress. Once isolated, only connections that some policy allows are permitted, plus reply traffic for those allowed connections.
Two consequences follow:
| Situation | Result |
|---|---|
| No policy selects the pod | Fully open in both directions |
| A policy selects the pod for ingress only | Ingress restricted, egress still open |
| A policy with empty rules selects the pod | Isolated, so that direction is denied |
| Plugin does not enforce policies | Everything stays open regardless |
Isolation is not absolute, as the documentation puts it. It means some restrictions apply.
A simple enforcement test
Run this once per cluster and again after network plugin upgrades.
- Create a test namespace with two pods, a client and a server that answers on a port.
- Confirm the client can reach the server.
- Apply a default deny ingress policy that selects all pods in the namespace.
- Try again from the client. The connection should now fail.
- Delete the policy and confirm traffic returns.
If step 4 still succeeds, enforcement is not happening. Check your plugin's documentation and your cluster's configuration before relying on any policy.
Know the gray areas
The documentation warns that behavior can differ when traffic is rewritten. For ingress, the source address a policy sees may be that of a load balancer or a node rather than the original client. For egress, connections to a Service address that gets rewritten to an external address may or may not be subject to policy, depending on the plugin, cloud provider and Service implementation. Test the paths your applications actually use.
Make it part of deployment hygiene
- Apply a default deny policy to every new namespace as part of its template.
- Add allow rules per application, reviewed with the code.
- Check in CI or admission that new namespaces carry the default policy.
- Include the enforcement test in cluster build and upgrade runbooks.
A missing default deny is easy to find by listing policies per namespace, so automate that report.
Where Safeguard fits
Safeguard's asset discovery and policies help you see what you have and hold changes to your rules, but network enforcement itself happens in your cluster's network layer. Treat the test above as part of your own build checks.
Quick check
Why does my NetworkPolicy exist but traffic still flows?
Your network plugin may not enforce NetworkPolicy. The object is accepted by the API but ignored.
What is the default for a pod with no policy?
Non-isolated. All inbound and outbound connections are allowed.
Sources
Last reviewed: 19 October 2026.
