A NetworkPolicy is a Kubernetes resource that defines which pods can communicate with each other, on ingress and egress. Without any policies defined, every pod in a cluster can freely talk to every other pod by default — convenient when you’re starting out, but a serious security risk in a production, multi-team environment.
Quick Overview
What you’ll learn from this article:
- What NetworkPolicy is and why Kubernetes’ default “flat network” is risky
- Who in the organisation should write, review and maintain network policies
- How to split responsibility between a platform team and application teams
- Mistakes to avoid so policies don’t become a dead, never-updated YAML file
Who this article is for: platform engineers, DevOps/SRE engineers responsible for a Kubernetes cluster, and tech leads of application teams running on a shared cluster.
Reading time: 6 minutes
Kubernetes NetworkPolicy fundamentals
The Kubernetes documentation is explicit: NetworkPolicy is enforced by the network plugin (CNI) — a NetworkPolicy object sitting in a cluster whose CNI doesn’t support this mechanism has no effect whatsoever. This is the first mistake teams make: they write policies, deploy them, and the cluster keeps passing all traffic anyway, because the default CNI (a bare-bones flannel setup, for instance) doesn’t enforce them.
The second fundamental rule: NetworkPolicy works on a “default deny, explicit allow” basis. If no policy selects a given pod, all traffic to it is allowed. Only once the first policy starts targeting that pod does the rule flip: anything not explicitly allowed is blocked.
Who should write and maintain network policies?
| Role | Responsibility | Why |
|---|---|---|
| Platform / Infrastructure team | Baseline cluster policies (namespace isolation, default deny-all, access to DNS/monitoring) | Requires knowledge of the whole cluster’s architecture and the global consequences of a mistake |
| Application team | Policies specific to their own namespace (access to particular services and ports) | Knows their application’s actual traffic patterns without needing to understand the entire cluster |
| Security / DevSecOps | Reviews and audits policies, enforces the standard (e.g. via OPA/Gatekeeper) | Ensures consistency and catches gaps between namespaces |
The key split: the platform team ships a baseline “deny-all plus DNS/monitoring exceptions” template for every new namespace, and the application team adds its own detailed rules within that skeleton. Without this split, either the platform team becomes a bottleneck for every change, or application teams leave their namespace wide open because “nobody has time to write it.”
Step by step: rolling out policies across multiple teams
- Start with an audit — check which CNI is installed in the cluster and whether it supports NetworkPolicy.
- Roll out a default “deny-all” at the namespace level, with explicit exceptions for DNS (port 53) and the monitoring stack.
- Delegate the details to application teams — provide a policy template they fill in with their own service access rules.
- Bring policy review into code review — treat the NetworkPolicy file the same way you treat application code, requiring approval.
- Monitor dropped traffic — tools such as Cilium Hubble let you see what traffic was actually blocked before you enforce a policy in production.
Common mistakes when rolling this out
- No CNI that supports NetworkPolicy — the policy exists in the cluster, but nothing enforces it, creating a false sense of security.
- Policies written once and forgotten — a new application release adds a port or a service, and the policy is never updated, so traffic simply gets blocked (or, worse, the policy is deleted “to make it work”).
- No audit-mode testing — rolling out “deny-all” without first analysing real traffic can instantly break inter-service communication in production.
- Treating NetworkPolicy as purely a platform-team task — without input from the application team on real traffic patterns, policies end up either far too restrictive or far too permissive.
Read Also
- GitHub Actions for Deployment Automation
- Cloud FinOps and Cost Control: A Practical Comparison of Approaches
Develop Your Skills
Want to build practical Kubernetes skills? Check out our training led by experienced EITT instructors.
➡️ Advanced Container Orchestration Practices with Kubernetes — EITT training ➡️ Advanced Docker and Kubernetes — EITT training
Frequently Asked Questions (FAQ)
Does a NetworkPolicy take effect as soon as I create the object in the cluster?
Not always. NetworkPolicy is enforced by the network plugin (CNI), so if your cluster runs a CNI that doesn’t implement this mechanism, the NetworkPolicy object exists in the cluster but has no effect on actual traffic. Before writing policies, check whether your CNI supports them.
Who should own network policies in a multi-team organisation?
A layered split works best: the platform team ships a baseline “deny-all” template with system-level exceptions for every namespace, and application teams add their own detailed rules on top of that skeleton. Centralising everything in one team creates a bottleneck, while full decentralisation without a shared standard leads to inconsistency and security gaps.
What happens if I roll out “deny-all” without auditing traffic first?
You risk instantly breaking communication between services that previously worked without restriction — including DNS access, which can look like a full application outage. Before enforcing a restrictive policy in production, test it in audit mode or on a staging environment and analyse actual traffic with an observability tool.
How often should NetworkPolicy files be reviewed and updated?
Policies should be treated like application code — updated with every architectural change (a new service, a new port, a changed dependency) and reviewed alongside the rest of the changes in the repository. It’s also worth running a periodic quarterly audit to catch policies that no longer reflect the application’s actual traffic.