Kubernetes Network Policies

In the previous article, we explored Ingress and Ingress Controllers and learned how external traffic enters a Kubernetes cluster and reaches applications running inside Pods.

At this stage in the journey, we understand:

• How Pods run applications

• How Services provide a stable IP/DNS endpoint for ephemeral Pods

• How Ingress exposes applications to the outside world

From a connectivity perspective, everything is in place.

But this naturally raises an important question:

Once traffic is inside the cluster, who is allowed to talk to whom?

By default, Kubernetes allows all traffic.

This article focuses on how Kubernetes restricts and secures internal network communication using Network Policies.

---

🔹 Why Network Policies Are Needed

Kubernetes networking is designed to be open by default:

• Every Pod gets its own IP

• Any Pod can talk to any other Pod

• Communication works across namespaces

• No isolation exists unless explicitly defined

This simplifies development but creates serious risks in production:

• A compromised Pod can access internal services

• Lateral movement becomes trivial

• Sensitive workloads are unintentionally exposed

Network Policies allow platform teams to:

• Enforce least-privilege networking

• Isolate workloads

• Reduce blast radius

• Implement Zero Trust networking inside the cluster

If Ingress controls how traffic enters the cluster,
Network Policies control how traffic moves within the cluster.

---

🔹 What Network Policies Are

A NetworkPolicy is a Kubernetes resource that defines:

• Which Pods the policy applies to (via labels)

• Allowed ingress (incoming) traffic

• Allowed egress (outgoing) traffic

Once a Pod is selected by a NetworkPolicy:

All traffic is denied by default unless explicitly allowed.

This default-deny behavior is the foundation of Kubernetes network security.

---

🔹 Why Understanding Services Matters First

Before applying Network Policies, it’s important to clearly understand what Services do.

A Kubernetes Service:

• Provides a stable IP address and DNS name

• Represents a logical group of Pods selected by labels

• Load-balances traffic across Pods

• Hides Pod churn (Pods are ephemeral)

Services do not enforce security.
They only provide stable access.

Network Policies operate below Services, controlling whether traffic is allowed to reach Pods even if a Service exists.

---

🔹 Service vs Ingress vs NetworkPolicy

These resources complement each other — none of them replace the others.

---

🔹 NetworkPolicy Enforcement Depends on the CNI Plugin

Kubernetes defines the NetworkPolicy API, but it does not enforce it.

Enforcement is handled by the CNI (Container Network Interface) plugin installed in the cluster.

If your CNI does not support Network Policies, the policy YAML will apply successfully — but no traffic will actually be restricted.

This is one of the most common causes of false security assumptions.

---

🔹 Verifying the Installed CNI Plugin

Most CNIs run as Pods in the kube-system namespace.

kubectl get pods -n kube-system

Common indicators:

---

🔹 NetworkPolicy Support by CNI (Comparison)

---

Here’s a clean, readable table you can drop directly into the article under “Recommended CNIs (Cloud & On-Prem)”.

---

🔹 Recommended CNIs (Cloud & On-Prem)

If you are unsure which CNI to choose, start with Calico — it offers the best balance of simplicity, stability, and production readiness.

---

🔹 Installing a Policy-Capable CNI (Example: Calico)

For kubeadm or self-managed clusters:

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.29.1/manifests/calico.yaml

Verify:

kubectl get pods -n kube-system | grep calico

---

🔹 How Network Policies Work with Multiple Policies

Multiple NetworkPolicies can apply to the same Pod.

Key rules:

• Policies are additive

• There is no priority or order

• Traffic is allowed if any policy allows it

• Traffic is denied only if no policy allows it

Understanding this prevents accidental outages.

---

🔹 Deny All Traffic (Baseline Policies)

Deny All Ingress

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

Deny All Egress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
spec:
  podSelector: {}
  policyTypes:
    - Egress

These establish a default-deny security baseline.

---

🔹 Allow Traffic from One Pod to Another

Example: allow frontend Pods to reach backend Pods on port 80.

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

---

🔹 Controlling Egress Traffic

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-egress
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.0/16

---

🔹 DNS and Network Policies (Critical Pitfall)

DNS is essential for:

• Service discovery

• External access

• Internal communication

Always ensure DNS traffic to CoreDNS (kube-system) is explicitly allowed.

---

🔹 Network Policies in Real-World Clusters

Used to:

• Isolate microservices

• Separate environments

• Protect sensitive workloads

• Enforce Zero Trust

Most effective when combined with:

• RBAC

• Admission controllers

• Observability

---

🔹 Network Policies and Observability

Network Policy failures are often silent.

They appear as:

• Timeouts

• Partial outages

• Increased latency

Metrics and logs are essential to debug and validate policy behavior.

---

🔹 Common NetworkPolicy Mistakes

• Using a CNI without policy support

• Forgetting DNS access

• Ignoring egress rules

• Applying policies too aggressively

• Assuming policies are cluster-wide

---

🔹 Summary

• Kubernetes networking is open by default

• Network Policies introduce Zero Trust

• Enforcement depends on the CNI plugin

• Policies are additive and label-driven

If Services provide stable access to Pods,
Network Policies decide whether that access is allowed.