Skip to content

6.17 Kubernetes Network Policies

Abstract

Network Policies control Ingress and Egress traffic between pods in Kubernetes. They enforce network segmentation and zero‑trust communication inside the cluster.

By default, Kubernetes networking allows all pods to communicate with each other. Network policies restrict this behavior to improve security.

Understanding Ingress and Egress

In Kubernetes networking there are two traffic directions.

Type Description
Ingress Incoming traffic to a pod
Egress Outgoing traffic from a pod

Example application flow:

  1. User → Web Pod (Port 80)
  2. Web Pod → API Pod (Port 5000)
  3. API Pod → DB Pod (Port 3306)

Note

When defining policies, only the originating direction of traffic matters.

Default Kubernetes Networking Behavior

Kubernetes networking follows the all-allow model by default.

  • Any pod can communicate with any other pod
  • No restrictions exist unless policies are defined

Warning

This default behavior can create security risks in production clusters.

What is a Network Policy

A NetworkPolicy is a Kubernetes resource used to restrict traffic.

It works by:

  1. Selecting target pods using labels
  2. Defining Ingress or Egress rules
  3. Allowing only specified traffic

Once applied:

  • All other traffic to the selected pods is blocked.

Example Architecture

Typical secure application architecture:

Component Port
Web Pod 80
API Pod 5000
DB Pod 3306

Desired restrictions:

  • Web Pod → API Pod allowed
  • API Pod → DB Pod allowed
  • Web Pod → DB Pod blocked

Example Network Policy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-policy
spec:
  podSelector:
    matchLabels:
      role: db

  policyTypes:
  - Ingress

  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: api
    ports:
    - protocol: TCP
      port: 3306

This policy:

  • Applies to pods with label role=db
  • Allows ingress only from API pods
  • Allows traffic only on port 3306

Tip

Use labels and selectors to connect policies with pods.

Production Best Practices

Recommended Production Practices

  • Use default deny policies
  • Restrict pod communication using labels
  • Separate frontend, backend, and database tiers
  • Allow only required ports
  • Audit network policies regularly

Example default deny policy:

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

Do's and Don'ts

Do

  • Implement least privilege networking
  • Use labels to define application tiers
  • Apply policies for both ingress and egress
  • Test policies before deploying to production

Don't

  • Don't allow unrestricted pod communication
  • Don't expose database pods directly
  • Don't rely only on service-level security

Danger

Without network policies, a compromised pod could scan and attack other pods inside the cluster.

Network Plugins Supporting Policies

Network policies are enforced by the CNI plugin, not Kubernetes itself.

Supported plugins include:

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

Not supported:

  • Flannel

Warning

If your CNI plugin does not support network policies, the policies will exist but will not be enforced.

Quick Production Checklist

Before deploying policies

  • Is the cluster using a CNI that supports network policies?
  • Are sensitive workloads isolated?
  • Are database ports restricted?
  • Are default deny policies implemented?

Summary

Quote

  • Kubernetes allows all pod communication by default
  • Network policies restrict Ingress and Egress traffic
  • Policies are applied using labels and selectors
  • Enforcement depends on the CNI network plugin
  • Production clusters should enforce least privilege networking