Securing Pod Communication With Network Policies

Security in Kubernetes isn’t just about securing nodes and pods — it’s also about controlling network traffic between them. That’s where Kubernetes Network Policies come in.

Without network policies, any pod can communicate with any other pod in a cluster, which isn’t ideal for security. With Network Policies, you can restrict ingress (incoming) and egress (outgoing) traffic based on namespaces, pod labels, IP ranges (CIDR) and ports.

In this guide, you’ll learn:
What Kubernetes Network Policies are and how they work
Examples of network policies for ingress and egress traffic

What Are Kubernetes Network Policies?

Kubernetes Network Policies are rules that control traffic flow between pods based on specific criteria. These policies are implemented at the network level by Kubernetes-compatible Container Network Interface (CNI) plugins, such as:

• Calico
• Cilium
• Weave Net

By default, Kubernetes allows all traffic between pods unless a network policy is applied to restrict it.

Checking Which CNI You Are Using

To check which CNI (Container Network Interface) is installed in your Kubernetes cluster, you can use the following :

Check Installed CNI Plugin via Node Configuration

Run the following command on one of your Kubernetes nodes:

ls /etc/cni/net.d/

This directory contains the configuration files for the installed CNI plugin.
Common CNI plugins you might see:

• Calico → 10-calico.conflist
• Flannel → 10-flannel.conflist
• Weave → 10-weave.conf
• Cilium → 05-cilium.conf
• Canal → 10-canal.conflist

How Do Network Policies Work?

A NetworkPolicy defines:
Ingress rules → Control incoming traffic to a pod
Egress rules → Control outgoing traffic from a pod

Policies are additive — if multiple policies apply to a pod, they are combined

Is There Any Order of Evaluation?

Unlike firewall rules that evaluate in order, Kubernetes does not process rules sequentially. Instead:

• If a pod has no policy, all traffic is allowed
• If a pod has one or more policies, only allowed traffic can pass
• Multiple policies can apply to the same pod — they are combined

Let’s go through examples of different types of network policies.

Checking Existing Networking Policies

first of all, to check the network policies are applied to the cluster, you need to run:

kubectl get netpol -A

Deny All Traffic NetworkPolicy

To create a deny-all NetworkPolicy in Kubernetes, you can define a policy that applies to all pods in a namespace anddoes not allow any ingress or egress traffic.

This is necessary, because now you can allow only the traffic you need. As soon as you face a necessary traffic blocked, you create a network policy for that, and everything else will be blocked.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default  # The namespace this policy will be applied to
spec:
  podSelector: {}  # Selects all pods in the namespace
  policyTypes: # Block all traffic
    - Ingress
    - Egress

Ingress and Egress Rules

Ingress rules — Control incoming traffic to a pod
Egress rules — Control outgoing traffic from a pod

This rule will allow only ingress traffic from pods with a specific label,and allow egress traffic only to a specific namespace

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-and-egress # <- Name of the policy
  namespace: my-namespace # <- namespace to be applied
spec:
  podSelector:
    matchLabels:
      role: backend # <- tag of the pods that the policies will be applied to
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend # <- tag of the pods that will have access 
                         # to the pods with role backend
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: external-services # <- pods with role backend will have 
                                  # access only to resources running
                                  # on external-services namespace

Only frontend pods can reach backend pods
backend pods can only talk to external-services namespace

Namespace Selector

Allow traffic only from a specific namespace

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-namespace
  namespace: backend
spec:
  podSelector: {} # Select ALL pods in "backend" namespace
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          project: frontend # Accept traffic only from pods from frontend 
                            # namespace, everything else will be blocked

Allows all pods in backend namespace to accept traffic only from frontend namespace
Blocks traffic from all other namespaces

Pod Selector

Allow communication only between pods with the same label

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-app
  namespace: my-app # <- namespace to be applied
spec:
  podSelector:
    matchLabels:
      app: my-app # Select ALL pods with label app:my-app in the my-app namespace
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: my-app # Only pods with this label will be able to talk to 
                      # pods with tag app: my-app

Only pods labeled app: my-app can talk to each other
No other pod (even in the same namespace) can access them

Restrict Egress with CIDR (IP Range)

Allow outbound traffic only to a specific IP range (e.g., private network)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-private-network
  namespace: my-namespace 
spec:
  podSelector: {} # Select ALL pods in "my-namespace" namespace
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/16 # Pods can only communicate with IPs in this range

Pods can only communicate with IPs in 10.0.0.0/16
Prevents them from reaching the internet

DNS-Based Network Policy

🔹 Allow only specific domains to be accessed (e.g., external APIs)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-specific-dns
  namespace: my-namespace
spec:
  podSelector: {}
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
    ports:
    - protocol: TCP
      port: 53

Ensures that DNS resolution is allowed by allowing egress to CoreDNS

Conclusion

With Kubernetes Network Policies, you can:
Restrict ingress and egress traffic to improve security
Enforce namespace and pod-based communication rules
Control outbound traffic using CIDR blocks

Using Network Policies, you can lock down your cluster to make sure only authorized communication happens between services.

If you want to dive deep on this, refer to the documentation here:
https://kubernetes.io/docs/concepts/services-networking/network-policies/

Want more insights on DevOps, security, and automation? Don’t miss out — Follow me!

Connect with me on Linkedin!