Kubernetes Network Policies Demystified – From Basics to Advanced (2025 Edition)

Mohammad Gufran Jahangir May 30, 2025 0

Table of Contents

🔐 Kubernetes Network Policies Demystified – From Basics to Advanced (2025 Edition)

In Kubernetes, everything is designed to be dynamic and open by default — including network communication. While that’s great for flexibility, it’s a nightmare for security.

Enter:

🔐 Kubernetes Network Policies – your firewall for Pod-level communication.

Whether you’re building a multi-tenant app or locking down microservices, Network Policies give you fine-grained control over who can talk to whom.

In this blog, we’ll break it all down — simply, clearly, and with real-world examples.

🧠 What Are Network Policies in Kubernetes?

By default, all pods in Kubernetes can talk to each other. No restrictions.

Network Policies are rules that:

Allow or block traffic to or from pods
Work at Layer 3 & 4 (IP + port) level
Are enforced by a CNI plugin like Calico, Cilium, or Weave

✅ Think of it like iptables for pods — but declarative and namespace-aware.

⚙️ Prerequisite: Your CNI Plugin Must Support It

Not all CNIs enforce Network Policies.

CNI Plugin	NetworkPolicy Support
Calico	✅ Yes (Full)
Cilium	✅ Yes + eBPF
Weave	✅ Yes (Basic)
Flannel	❌ No (use with Calico)
AWS VPC CNI	✅ Yes (with extra config)

🔍 You can check support by reviewing your cluster’s network plugin or running:

kubectl get pods -n kube-system

Look for names like calico-node, cilium-agent, etc.

🧱 Basic Anatomy of a NetworkPolicy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-nginx
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: nginx
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend

Key Sections:

podSelector: Which pods this policy applies to
policyTypes: Ingress, Egress, or both
ingress/egress: Allowed sources or destinations

🔒 Ingress vs Egress

Type	Controls
Ingress	Who can connect to the selected pods
Egress	Where the selected pods can connect to

By default:

If no NetworkPolicy exists, traffic is allowed.
If one NetworkPolicy exists, and it has no rules — it blocks everything (deny by default starts here).

📦 Use Case Examples

1️⃣ Allow Only Frontend to Talk to Nginx

podSelector:
  matchLabels:
    app: nginx
ingress:
  - from:
      - podSelector:
          matchLabels:
            app: frontend

🚫 This blocks all other pods from reaching Nginx.

2️⃣ Allow Ingress from Same Namespace Only

ingress:
  - from:
      - namespaceSelector:
          matchLabels:
            name: default

✅ Useful for isolating tenants by namespace.

3️⃣ Allow Egress to Internet (DNS & HTTPS only)

egress:
  - to:
      - ipBlock:
          cidr: 0.0.0.0/0
    ports:
      - protocol: TCP
        port: 443
      - protocol: UDP
        port: 53
policyTypes:
  - Egress

✅ Allows your pod to pull images, call APIs, or resolve DNS — but nothing else.

4️⃣ Deny All Ingress

podSelector:
  matchLabels:
    app: sensitive
ingress: []

🚫 Fully blocks all inbound traffic to pods with label app=sensitive.

5️⃣ Allow Traffic from a Specific Namespace

ingress:
  - from:
      - namespaceSelector:
          matchLabels:
            project: web

🔐 Great for multi-team clusters with isolated dev, staging, and prod namespaces.

🧪 Testing Network Policies

You can test enforcement using tools like:

kubectl exec into a pod and try to curl another service
Use network testing tools:
- netshoot container
- BusyBox for minimal tests
- k8s-netpolicy-tester

Example:

kubectl exec -it test-pod -- curl nginx.default.svc.cluster.local

🧠 Advanced NetworkPolicy Tips

Tip	Explanation
✅ Start with Allow-Only Policies	Declare what’s allowed, assume rest is blocked
🔐 Combine with RBAC & Secrets	NetworkPolicy ≠ identity or data protection
🛠 Use Labels Strategically	Group and select pods with intent
🧾 Version Control YAMLs	Apply with CI/CD and GitOps
🚧 Avoid Wide ipBlocks	Too broad? It’s no longer secure
📡 Use Calico Enterprise or Cilium UI	For visual policy dashboards

📚 Recommended Tools

Tool	Purpose
Netpol Visualizer	View policies as graphs
Calico Policy Manager	GUI for Calico security
K9s	CLI for Kubernetes navigation
Kubescape	Security audits for policies
OPA + Gatekeeper	Policy-as-code validation engine

🛡 Network Policy ≠ Firewall for Nodes

Important:
Network Policies only affect Pod-to-Pod communication.

They don’t:

Block host networking
Protect node-level traffic (use firewalls for that)
Replace TLS or mutual authentication

🚀 Final Thoughts

Network Policies may seem overwhelming at first, but they’re critical for zero trust Kubernetes.

Start simple: deny all ingress to a pod.
Then allow only what’s required — nothing more.

🔐 In today’s cloud-native world:

Apps are dynamic.
Threats are real.
Secure defaults + declarative controls = resilient systems.

🧩 TL;DR — Network Policy Quick Recap

Item	Example
Block all ingress	`ingress: []`
Allow frontend → backend	podSelector-based
Allow DNS & HTTPS egress	`egress` + ports
Apply to namespace	namespaceSelector
Visualize	Netpol Visualizer, Calico UI

Tags: DevOps, Kubernetes

Category: