Network Policies and Pod-to-Pod Encryption on Kubernetes

Kubernetes network policies control network traffic between pods, namespaces and external endpoints. Without these rules, every pod freely communicates with all others, creating a massive attack surface. Pod-to-pod encryption adds an essential confidentiality layer for sensitive data in transit.

TL;DR: Deploy NetworkPolicies with default deny-all, then explicitly allow necessary flows. Enable mTLS encryption via a service mesh to protect inter-pod communications.

To master these critical skills, follow the LFS460 Kubernetes Security Fundamentals training.

What is a Kubernetes Network Policy?

A Network Policy is a native Kubernetes resource defining network traffic rules at layer 3/4 (IP/port). It specifies which pods can communicate with each other via label selectors.

By default, Kubernetes allows all traffic between pods. This permissive behavior facilitates development but exposes production.

According to the CNCF Annual Survey 2025, 82% of organizations run Kubernetes in production. Every unsegmented cluster represents a lateral movement risk for attackers.

Key takeaway: Without Network Policy, a compromised pod accesses all other pods in the cluster. Segmentation limits attack propagation.

How to implement basic Kubernetes network policies?

Start with a deny-all policy that blocks all traffic by default, then add explicit allow rules.

Deny-all policy per namespace

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

This policy applies to all pods in the production namespace and blocks all inbound and outbound traffic.

Allow specific application traffic

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

For a complete Kubernetes training, explore our courses including network security.

Key takeaway: Apply the deny-by-default principle. Each allowed flow must correspond to a documented application need.

Which CNIs support Kubernetes network policies?

Network Policies require a compatible CNI (Container Network Interface). Not all CNIs support this feature.

CNI comparison

Check your current CNI:

# Identify the deployed CNI
kubectl get pods -n kube-system -l k8s-app=calico-node
kubectl get pods -n kube-system -l k8s-app=cilium

Cilium and Calico offer advanced features like L7 policies (HTTP, gRPC) and integrated network observability.

To deepen Kubernetes cluster administration, see our dedicated guide.

How to configure advanced Kubernetes network policies?

Beyond basic rules, Network Policies support complex selectors for microservices architectures.

Allow traffic from a specific namespace

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-monitoring
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
purpose: monitoring
ports:
- protocol: TCP
port: 9090

Allow traffic to external IPs

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-external-api
namespace: production
spec:
podSelector:
matchLabels:
app: backend
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 203.0.113.0/24
ports:
- protocol: TCP
port: 443

According to Orca Security 2025, 70% of organizations use Kubernetes in cloud with Helm. Network Policies must integrate with deployment charts.

Key takeaway: Combine podSelector, namespaceSelector and ipBlock for granular rules adapted to your architecture.

Explore Kubernetes production best practices to complete your network strategy.

How to enable Kubernetes pod-to-pod encryption?

Kubernetes pod encryption protects data in transit against interception. Three main approaches exist.

Option 1: WireGuard with Calico

# calico-installation.yaml
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
name: default
spec:
calicoNetwork:
bgp: Disabled
ipPools:
- cidr: 192.168.0.0/16
encapsulation: WireguardCrossSubnet

Verify activation:

# WireGuard status on nodes
calicoctl node status
kubectl get nodes -o custom-columns='NAME:.metadata.name,WIREGUARD:.metadata.annotations.projectcalico\.org/WireguardPublicKey'

Option 2: mTLS with Istio

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: production
spec:
mtls:
mode: STRICT

The service mesh automatically injects Envoy sidecars for transparent mTLS encryption.

Option 3: IPsec with Cilium

# Cilium installation with encryption
helm install cilium cilium/cilium \
--namespace kube-system \
--set encryption.enabled=true \
--set encryption.type=ipsec

To master Kubernetes security, structured training accelerates acquisition.

What are L7 policies for HTTP encryption and filtering?

Layer 7 policies filter HTTP/gRPC traffic, offering superior granularity to native Network Policies.

Cilium Network Policy L7

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: api-policy
namespace: production
spec:
endpointSelector:
matchLabels:
app: api
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: "8080"
protocol: TCP
rules:
http:
- method: GET
path: "/api/v1/products"
- method: POST
path: "/api/v1/orders"

This policy allows only GET requests on /api/v1/products and POST on /api/v1/orders.

Key takeaway: L7 policies require a compatible CNI (Cilium, Istio). They complement native Network Policies without replacing them.

See the guide on Kubernetes monitoring with Prometheus and Grafana to observe network traffic.

How to test and validate Kubernetes network policies?

Systematically test your policies before production. Traffic blocked by mistake causes application incidents.

Test with a debug pod

# Create a test pod
kubectl run debug --rm -it --image=nicolaka/netshoot -- bash

# From the pod, test connectivity
curl -v http://backend.production:8080/health
nc -zv backend.production 8080

Visualization with Cilium Hubble

# Observe flows in real-time
hubble observe --namespace production --verdict DROPPED
hubble observe --namespace production --verdict FORWARDED

Audit applied policies

# List NetworkPolicies by namespace
kubectl get networkpolicies -A

# Policy details
kubectl describe networkpolicy allow-frontend-to-backend -n production

According to Spectro Cloud State of Kubernetes 2025, teams manage an average of 20+ clusters. Automating network tests becomes critical at this scale.

For Kubernetes network troubleshooting, master observability tools.

Kubernetes network security checklist

Validate each point for robust segmentation:

• [ ] Deny-all policy by default on each namespace
• [ ] Explicit ingress rules for each service
• [ ] Egress rules limiting access to external APIs
• [ ] CNI compatible with Network Policies (Calico, Cilium)
• [ ] Pod-to-pod encryption enabled (WireGuard, mTLS)
• [ ] Automated connectivity tests
• [ ] Network flow observability (Hubble, Goldilocks)
• [ ] Documentation of allowed flows

Key takeaway: Kubernetes network security combines segmentation (Network Policies), encryption (mTLS/WireGuard) and observability (Hubble/Prometheus).

Take action: get trained in Kubernetes network security

The LFS460 Kubernetes Security Fundamentals training covers Network Policies, pod-to-pod encryption and CKS certification preparation. In 4 days, master network segmentation and defense in depth.

Next steps:

• Explore Kubernetes CKA CKAD CKS certifications
• Discover Kubernetes for Developers LFD459
• See the training calendar

Contact our advisors to build your Kubernetes security path.