Kubernetes NetworkPolicy is a namespace-scoped API resource that controls which network flows are allowed to and from selected Pods. It gives teams a workload-level isolation layer without requiring every application to understand the network topology around it.
For small teams, the difficult part is rarely writing YAML. The real decision is how aggressively to isolate workloads without breaking DNS, monitoring, ingress traffic, database access, third-party APIs, or operational tooling. Raff managed Kubernetes gives teams a private infrastructure boundary through cluster networking and VPC connectivity, while NetworkPolicy addresses a different question: which workloads should be allowed to communicate once they share a cluster network.
The practical model is to start from documented application flows, move toward default-deny where the cluster supports enforcement, and add only the ingress and egress paths the application actually needs. This guide explains that model without turning NetworkPolicy into a procedural deployment tutorial.
Kubernetes NetworkPolicy controls workload traffic, not identity
A NetworkPolicy selects Pods and describes allowed ingress, egress, or both. It is additive: multiple policies that select the same Pod combine their allowed traffic rather than overriding one another in a simple top-to-bottom order.
The important boundary is that NetworkPolicy is not an authentication or authorization system. It can restrict traffic by Pod selectors, namespace selectors, IP blocks, protocols, and ports, but it does not know whether an HTTP request contains a valid user session or whether a database credential should be trusted.
A useful mental model is:
VPC / private cloud network ↓ Kubernetes cluster network ↓ NetworkPolicy ↓ Allowed Pod-to-Pod / Pod-to-external flows ↓ Application authentication and authorization
Each layer solves a different problem.
Kubernetes also does not guarantee that merely creating a NetworkPolicy object will enforce traffic restrictions. Enforcement depends on the cluster networking implementation supporting NetworkPolicy. A production security review should therefore verify behavior on the actual cluster rather than assuming the object itself provides isolation.
Default-open networking creates hidden trust between workloads
In a namespace with no effective NetworkPolicy isolation, Pods can commonly communicate more freely than application teams expect. That is convenient during development, but it creates broad east-west trust inside the cluster.
The risk becomes more visible as a cluster grows. A compromised frontend Pod should not automatically gain useful network access to every internal API, database proxy, cache, admin service, or worker endpoint merely because those workloads share a cluster.
For small teams, this does not mean every namespace needs dozens of fine-grained rules on day one. It means the team should be able to answer a simpler question:
Which communication paths are actually required for the application to work?
A typical SaaS workload might need only:
Ingress controller → web Pods web Pods → API Pods API Pods → database endpoint selected Pods → DNS selected Pods → approved external APIs monitoring agent → metrics endpoints
Everything else is a candidate for removal from the trust model.
At Raff, the security review rule is to document the required traffic graph before adding deny rules. Starting with an imagined zero-trust policy and discovering dependencies through outages is slower and less reliable than mapping the application first.
Ingress and egress policies solve different risks
NetworkPolicy separates incoming and outgoing traffic decisions.
| Policy direction | Question it answers | Typical use |
|---|---|---|
| Ingress | Who may connect to this Pod? | Restrict APIs, databases, admin services |
| Egress | Where may this Pod connect? | Limit outbound APIs, metadata paths, internal services |
| Both | What is the complete allowed traffic boundary? | Higher-assurance workloads and shared clusters |
Ingress limits who can reach a workload
Ingress policy is usually the easier starting point because application dependencies are often directional.
For example, an API workload may need traffic from the web tier but not from unrelated workers. A database proxy may need traffic from the API namespace but not from the ingress controller.
The important point is that exposing a Service does not itself define who should be allowed to use it. Services provide stable reachability; NetworkPolicy narrows that reachability when supported.
Egress limits what a workload can reach
Egress policy can reduce the blast radius of a compromised workload by preventing arbitrary outbound connections.
It is also easier to break production with egress policy because applications often depend on DNS, software repositories, telemetry endpoints, payment providers, email APIs, object storage, identity services, or other external systems.
For that reason, small teams should usually introduce egress restrictions after they can observe and document legitimate outbound dependencies.
A default-deny model should be introduced deliberately
Default-deny means selected workloads receive no allowed ingress, egress, or both until another policy explicitly permits required traffic.
That is a strong security baseline, but it is not automatically the right first deployment state for every existing application.
A small team can use this decision framework:
| Application state | Recommended starting point | Why |
|---|---|---|
| New, well-documented service | Default-deny plus explicit allows | Dependencies can be designed before launch |
| Existing production app with known flows | Namespace-by-namespace default-deny | Limits rollout risk |
| Existing app with poor dependency visibility | Observe and map traffic first | Avoids breaking unknown dependencies |
| Shared cluster with unrelated teams/clients | Strong namespace isolation plus explicit cross-namespace flows | Reduces accidental east-west trust |
| Single small app in one namespace | Start with high-value workloads and ingress isolation | Keeps policy set understandable |
A default-deny ingress policy does not automatically deny egress, and a default-deny egress policy does not automatically deny ingress. Teams should decide both directions explicitly instead of assuming one policy isolates everything.
The safest rollout sequence is usually:
- map required application flows;
- verify the cluster actually enforces NetworkPolicy;
- isolate one namespace or workload class;
- add explicit required allows;
- test DNS, health checks, metrics, ingress, database access, and external dependencies;
- expand the model gradually.
This is slower than applying a cluster-wide deny rule immediately, but it produces a policy set the team can understand and maintain.
Namespace selectors are useful but namespace labels become security inputs
Namespace-based policy is one of the most practical tools for small teams because it lets the architecture express boundaries such as:
frontend namespace → application namespace application namespace → data namespace monitoring namespace → selected metrics ports
That is easier to manage than maintaining individual Pod IP addresses, which are not stable application identities.
However, namespace selectors depend on namespace labels. If policy logic trusts a label such as environment=production or team=payments, then changing that label can change the effective network boundary.
Treat labels used by security policy as controlled configuration rather than casual metadata.
Pod selectors and namespace selectors can also be combined when the team needs a more precise rule such as “allow Pods labeled role=api from the production application namespace.”
For small teams, the goal should be a small number of meaningful labels rather than a large policy taxonomy that nobody remembers during an incident.
DNS and infrastructure dependencies need explicit attention
DNS is one of the most common dependencies overlooked when teams introduce egress restrictions.
An application that cannot resolve Service names or external domains may look like it has a database, API, or internet connectivity problem even though the real issue is a blocked DNS path.
Before tightening egress, document at least these dependency classes:
- cluster DNS;
- ingress-controller-to-workload traffic;
- readiness and liveness probes where relevant to the network path;
- metrics and logging collection;
- databases and caches;
- object storage or managed services;
- software update or package endpoints if workloads genuinely require them;
- external APIs such as payments, email, identity, or webhooks.
NetworkPolicy works best when application architecture already separates these dependencies clearly.
IP-based egress rules deserve extra caution for third-party SaaS services because provider IP ranges can change. If the application needs stable domain-oriented outbound policy, confirm what the cluster networking implementation supports before designing around DNS names that the standard Kubernetes NetworkPolicy API does not directly model as first-class policy identities.
NetworkPolicy does not replace VPC, Services, or application security
Small teams often overestimate what one Kubernetes security object can do.
NetworkPolicy should be used alongside other boundaries:
| Layer | Primary job |
|---|---|
| VPC/private networking | Infrastructure-level private connectivity |
| Kubernetes Service | Stable workload discovery and exposure |
| NetworkPolicy | Allowed workload network flows |
| Ingress/Gateway | HTTP/HTTPS routing into Services |
| TLS | Protect traffic in transit where configured |
| Application auth | Decide who or what is authorized at the application layer |
| Secrets/IAM | Control credentials and service permissions |
A private VPC reduces public exposure, but it does not automatically mean every Pod inside that private network should trust every other Pod.
Likewise, a NetworkPolicy can block a TCP connection, but it cannot decide whether an authenticated API client should be allowed to delete a record.
The Kubernetes Services guide covers stable Service identity and public traffic routing, while Kubernetes Networking and Storage Architecture places NetworkPolicy inside the wider cluster design.
Raff separates the infrastructure boundary from workload policy
Raff managed Kubernetes gives small teams a managed control plane, private cluster networking, VPC integration, multiple node pools, and a managed public traffic entry model. Those capabilities establish the infrastructure around the cluster, but they should not be confused with the workload-level policy expressed through Kubernetes NetworkPolicy.
Raff Kubernetes currently publishes a $0 standard managed control plane, with a $30/month three-master HA option for teams that require that control-plane availability model. Public egress is $0, and VM/Kubernetes public bandwidth is published as unmetered up to 3 Gbps. These network economics mean a team can design segmentation around security and architecture rather than trying to minimize per-GB egress charges.
The operational boundary is still important: before relying on NetworkPolicy as a security control, verify that the current cluster networking implementation enforces the policy behavior your design assumes. Do not treat a successfully created YAML object as proof of isolation.
Raff currently reports more than 15,000 VMs across the platform and publishes a 99.9% uptime SLA. NetworkPolicy does not change application availability requirements: teams still need appropriate replicas, health checks, recovery planning, storage protection, and tested traffic paths.
Small teams should optimize for understandable policy sets
The best NetworkPolicy design is not the one with the most rules. It is the one the team can explain, test, and safely change.
Use these practices:
- start with application flows, not YAML templates;
- separate ingress and egress decisions;
- introduce default-deny gradually on existing production workloads;
- keep namespace and Pod labels intentional;
- explicitly account for DNS and observability;
- prefer stable workload identities over Pod IP assumptions;
- test both allowed and denied traffic after policy changes.
A useful test is whether an engineer can answer, during an incident, why this flow is allowed and which policy would need to change if the dependency changes.
If the answer requires reading twenty overlapping policies and guessing how they combine, the policy model is too complicated for the team operating it.
NetworkPolicy should reduce trust without making operations opaque
Kubernetes NetworkPolicy gives small teams a practical way to reduce unnecessary east-west and outbound trust between workloads. Start by mapping real application traffic, verify enforcement on the actual cluster, and then introduce default-deny boundaries with explicit allows for the flows the application needs.
Use ClusterIP Services for stable internal reachability, VPC networking for the infrastructure boundary, and NetworkPolicy for workload-level segmentation. Keep application authentication, secrets, and authorization separate from network filtering.
Continue with Kubernetes Networking and Storage Architecture for the full cluster model. The next S05 decision guide on persistent storage will address a different production boundary: what survives when Pods and nodes are replaced.