Kubernetes Network Policies explained with real security scenarios

Quick summary

Before going deeper, here is the easiest way to think about Network Policies.

Why Network Policies exist

Kubernetes networking is designed so that Pods can communicate with each other across the cluster by default. This makes application connectivity simple, but it also creates a security risk if communication is not controlled.

In real-world systems, not every workload should be allowed to talk to every other workload. Different components of an application have different responsibilities, and their communication should be restricted accordingly.

Network Policies allow you to define these rules clearly and enforce controlled communication between workloads.

Simple security example

Consider a typical three-tier application:

• frontend → backend allowed
• backend → database allowed
• frontend → database blocked

This type of controlled communication is called workload isolation and is a key part of securing Kubernetes environments.

What is a Kubernetes NetworkPolicy?

A NetworkPolicy is a Kubernetes object that defines how selected Pods are allowed to communicate over the network. It operates at the IP and port level and focuses on controlling traffic between workloads.

Policies can control:

• Ingress — traffic coming into Pods
• Egress — traffic leaving Pods
• Or both ingress and egress together

Plugin support matters (very important)

One of the most important concepts to understand is that Network Policies are enforced by the cluster’s networking layer, usually the CNI plugin.

If your cluster does not use a network plugin that supports Network Policies:

• The policy can be created
• But it will have no effect

Common CNI plugins that support Network Policies include:

• Calico
• Cilium
• Antrea
• Kube-router
• Weave Net

Mental model: allow rules, not firewall complexity

Network Policies are easier to understand when you think of them as allow rules for selected Pods.

Default deny explained

One of the most important patterns in Kubernetes security is default deny.

Instead of allowing everything and trying to block later, you:

• First block all traffic
• Then explicitly allow only required communication

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

This policy selects all Pods and blocks all incoming traffic until you define explicit allow rules.

Ingress rules

Ingress rules control who is allowed to connect to selected Pods.

• other Pods
• namespaces
• IP blocks
• and optional port restrictions

This is where Network Policies become very powerful: they express workload intent instead of just raw IP firewalling.

Egress rules

Egress rules control where selected Pods are allowed to send traffic. This is especially useful when you want to restrict outbound communication, such as allowing a Pod to call DNS and one API, but nothing else.

Pod selectors, namespace selectors, and IP blocks

Network Policies can identify allowed communication sources or destinations in several ways.

This makes policies much more expressive than simple one-to-one firewall rules.

Real-world architecture example

Imagine a three-tier application:

• frontend namespace
• backend namespace
• database namespace

In this design:

• frontend can call backend
• backend can call database
• frontend cannot call database directly
• database may have no internet egress at all

YAML examples that readers can understand

Allow only frontend to backend

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-allow-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Allow backend egress only to database

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-egress-db
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

Important limitations and exceptions

A few limitations matter in real clusters:

• a Pod cannot block access to itself
• traffic to and from the node where the Pod is running is generally still allowed
• some behavior depends on the network plugin
• Network Policies are not a replacement for every type of firewall or Layer 7 security control

Common beginner mistakes

• assuming policies work without a supporting CNI
• forgetting that policies target Pods, not generic applications
• not understanding that default deny should usually come before selective allow rules
• allowing ingress but forgetting required egress
• breaking DNS because egress to DNS was not considered
• mixing namespace and Pod selectors without understanding how they match

Common interview questions

• What does a Kubernetes NetworkPolicy do? It controls allowed ingress and egress traffic for selected Pods.
• Do Network Policies work by default in every cluster? No, the network plugin must support enforcement.
• What is default deny? A pattern where you first block traffic for selected Pods and then explicitly allow only what is needed.
• Can Network Policies match namespaces? Yes.
• Can they match CIDR ranges? Yes, using ipBlock.
• Do they work at Layer 7? No, they are generally Layer 3/4 controls.

How Network Policies fit into the Kubernetes path

A clean Kubernetes networking learning path now looks like this:

• Pods are the workloads
• Services give stable access to workloads
• DNS gives names to Services
• Ingress brings web traffic in
• Network Policies decide which traffic is allowed between workloads