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
Ready to rethink the way you do DevOps?
Qovery is a DevOps automation platform that enables organizations to deliver faster and focus on creating great products.
Book a demo

Suggested articles

Kubernetes
 minutes
How to Deploy a Docker Container on Kubernetes: Step-by-Step Guide

Simplify Kubernetes Deployment. Learn the difficult 6-step manual process for deploying Docker containers to Kubernetes, the friction of YAML and kubectl, and how platform tools like Qovery automate the entire workflow.

Mélanie Dallé
Senior Marketing Manager
Observability
DevOps
 minutes
Observability in DevOps: What is it, Observe vs. Monitoring, Benefits

Observability in DevOps: Diagnose system failures faster. Learn how true observability differs from traditional monitoring. End context-switching, reduce MTTR, and resolve unforeseen issues quickly.

Mélanie Dallé
Senior Marketing Manager
Heroku
15
 minutes
Heroku Alternatives: The 10 Best Competitor Platforms

Fed up of rising Heroku costs and frequent outages? This guide compares the top 10 Heroku alternatives and competitors based on features, pricing, pros, and cons—helping developers and tech leaders choose the right PaaS.

Mélanie Dallé
Senior Marketing Manager
Product
Infrastructure Management
Deployment
 minutes
Stop tool sprawl - Welcome to Terraform/OpenTofu support

Provisioning cloud resources shouldn’t require a second stack of tools. With Qovery’s new Terraform and OpenTofu support, you can now define and deploy your infrastructure right alongside your applications. Declaratively, securely, and in one place. No external runners. No glue code. No tool sprawl.

Alessandro Carrano
Head of Product
AI
DevOps
 minutes
Integrating Agentic AI into Your DevOps Workflow

Eliminate non-coding toil with Qovery’s AI DevOps Agent. Discover how shifting from static automation to specialized DevOps AI agents optimizes FinOps, security, and infrastructure management.

Mélanie Dallé
Senior Marketing Manager
DevOps
 minutes
Top 10 Flux CD Alternatives: Finding a Better Way to Deploy Your Code

Looking for a Flux CD alternative? Discover why Qovery stands out as the #1 choice. Compare features, pros, and cons of the top 10 platforms to simplify your deployment strategy and empower your team.

Mélanie Dallé
Senior Marketing Manager
DevOps
5
 minutes
The 6 Best GitOps Tools for Developers

Discover the top 6 GitOps tools to streamline your development workflow. Compare Qovery, ArgoCD, GitHub Actions, and more to find the perfect solution for automating your infrastructure and deployments.

Morgan Perry
Co-founder
AWS
Cloud
Business
7
 minutes
AWS Production Deployment Checklist: The 4 Pillars for Stability and Scale

AWS Production Deployment Checklist: Ensure stable, scalable deployments. Follow this four-pillar guide covering CI standards, IaC for CD, integrated DevSecOps, and proactive application monitoring.

Morgan Perry
Co-founder

It’s time to rethink
the way you do DevOps

Say goodbye to DevOps overhead. Qovery makes infrastructure effortless, giving you full control without the trouble.