Blog
Kubernetes
Engineering
3
minutes

Kubernetes - Network isolation with NetworkPolicy

As your number of deployed applications within Kubernetes grows, you may want to isolate them from a network point of view. By default, Kubernetes does not offer any network isolation, all pods of all your namespaces can talk to each other without any isolation, and even on network port that you have not defined. Yes, that's scary! There are different approaches and tools to do network isolation; let's take a look at the NetworkPolicy.
Pierre Mavro
CTO & Co-founder
Summary
Twitter icon
linkedin icon

Kubernetes Networking plugin

Kubernetes provides a resource called NetworkPolicy that allows rules to allow/deny network traffic, which works like a network firewall. By default using this resource doesn't do anything. To make it work, you need first to add a Kubernetes Networking plugin that implements it.

Some Kubernetes cluster providers propose their implementation, like GKS and AKS. On the other side, you can use Calico, like recommended by AWS with EKS.

This page assumes you have installed the Kubernetes Networking Plugin (See below).

Installation

Here are the links to install the Kubernetes Networking plugin according to your Cloud provider.

Configuration

Implementing Network Isolation is the same rule of thumb as configuring a firewall - block every inbound request and allow what you need.

Block all incoming traffic

In the example below, we will configure the production to be isolated from all other namespaces but still allow any pods deployed within the production namespace to talk to each other.

First, let's create a namespace:

apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
role: production

Then, blocking incoming traffic for this namespace looks like this:

#...
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: no-inbound-traffic
namespace: production
spec:
policyTypes:
- Ingress
podSelector:
matchLabels: {}

The rule is:

  • policyTypes=Ingress to select only the incoming traffic
  • an empty set in podSelector/matchLabels, to apply the rule to all pods within the namespace.
  • no ingress rules have been defined, so everything is blocked

Allow traffic between pods within the same namespace

To allow any pods within the production namespace to communicate to each other, add a NetworkPolicy rule:

#...
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-same-namespace-traffic
namespace: production
spec:
policyTypes:
- Ingress
podSelector:
matchLabels: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
role: production

The ingress rules indicate that we want to allow all traffic from the namespace with the label role=production.

Allow incoming traffic from outside.

Let's now imagine that you have a web application listening on port 8000. To make it publicly accessible, we need to add one more rule:

#...
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-port-8000
namespace: production
spec:
policyTypes:
- Ingress
podSelector:
matchLabels:
app=web-server
ingress:
- ports:
- port: 8000

Instead of selecting all pods, I pick only those with the label app=web-server of the productions namespace. Then the ingress: rule allows anybody to connect to the port 8000 of my web-server.

Block outgoing traffic

NetworkPolicy can also be used to prevent traffic from going out. For instance, we may not want an application to read the AWS metadata server information.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: disable-aws-metadata
namespace: production
spec:
policyTypes:
- Egress
podSelector:
matchLabels: {}
egress:
- to:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 169.254.169.254/32

Going further

NetworkPolicy is useful for simple network traffic filtering but not enough to have perfect control over pods communication. Filtering rules are made only with Pod and Namespace selectors. A person with bad intentions can still connect directly to the application port (here 8000) and bypass your Ingress resources and Loadbalancer setup once the network port is open.

In a forthcoming post, we will see how we can have fine-grained filtering with a sidecar service called Istio.

Resources

Share on :
Twitter icon
linkedin icon
Tired of fighting your Kubernetes platform?
Qovery provides a unified Kubernetes control plane for cluster provisioning, security, and deployments - giving you an enterprise-grade platform without the DIY overhead.
See it in action

Suggested articles

AI
 minutes
Beyond Compute Constraints: Why AI Success is an Orchestration Problem

As the AI race shifts from hardware acquisition to GPU utilization, success is now an orchestration problem. Learn how to bridge the 84% capacity gap, eliminate "ghost" expenses, and leverage AI infrastructure copilots to maximize ROI in 2026.

Romaric Philogène
CEO & Co-founder
Kubernetes
DevOps
Platform Engineering
6
 minutes
Kubernetes vs. Docker: Escaping the complexity trap

Is Kubernetes complexity killing your team’s velocity? Compare Docker vs. Kubernetes in 2026 and discover how to get production-grade orchestration with the "Git Push" simplicity of Docker.

Morgan Perry
Co-founder
Kubernetes
DevOps
Platform Engineering
7
 minutes
Kubernetes vs. OpenShift (and how Qovery simplifies it all)

Stuck between Kubernetes and OpenShift? Discover their pros, cons, differences, and how Qovery delivers automated scaling, simplified deployments, and the best of both worlds.

Morgan Perry
Co-founder
Platform Engineering
DevOps
Kubernetes
9
 minutes
Rancher vs. OpenShift (and why Qovery might be the accelerator)

Comparing Rancher vs. OpenShift for Kubernetes management? Discover their pros, cons, and why Qovery offers a simpler, cost-effective alternative for growing teams.

Morgan Perry
Co-founder
DevOps
Platform Engineering
Kubernetes
8
 minutes
VMware Tanzu vs. Red Hat OpenShift (and why Qovery is the fast track)

Comparing VMware Tanzu vs. Red Hat OpenShift for enterprise Kubernetes? Explore their features, pros, cons, and discover why Qovery is the smarter alternative for rapid application delivery.

Morgan Perry
Co-founder
Kubernetes
6
 minutes
When Kubernetes Becomes the Bottleneck, and How to Fix It

Struggling with Kubernetes configuration sprawl and long deployment queues? Discover how to identify technical vs. workflow bottlenecks and why shifting to a self-service Kubernetes management platform like Qovery is the key to scaling your engineering velocity.

Mélanie Dallé
Senior Marketing Manager
DevOps
Kubernetes
Platform Engineering
6
 minutes
10 Red Hat OpenShift alternatives to reduce licensing costs

Is OpenShift too expensive? Compare the top 10 alternatives for 2026. Discover how to transition to Rancher, standard EKS, or modern K8s management platforms.

Morgan Perry
Co-founder
DevOps
6
 minutes
The enterprise guide to DevOps automation: scaling kubernetes and delivery pipelines

Scale your enterprise DevOps automation without configuration sprawl. Learn how a Kubernetes management platform like Qovery enables secure, self-service infrastructure.

Mélanie Dallé
Senior Marketing Manager

It’s time to change
the way you manage K8s

Turn Kubernetes into your strategic advantage with Qovery, automating the heavy lifting while you stay in control.