NetworkPolicies Quick Reference: Control Kubernetes Network Traffic

NetworkPolicies are Kubernetes' native firewall. This NetworkPolicies quick reference covers YAML syntax, selectors, ingress/egress rules, and essential debugging commands.

Without NetworkPolicy, all pods communicate freely. With 82% of organizations running Kubernetes in production (CNCF Annual Survey 2025), mastering network control becomes essential for any Kubernetes system administrator.

TL;DR: A NetworkPolicy is a Kubernetes object that filters traffic at the pod level via ingress (incoming) and egress (outgoing) rules. It applies to pods matching its podSelector. Without a compatible CNI (Calico, Cilium, Weave), NetworkPolicies are ignored.

This skill is at the core of the LFS460 Kubernetes Security Fundamentals training.

---

NetworkPolicy Basic Syntax

Remember: An empty podSelector: {} targets all pods in the namespace. This is the basis for a "deny-all" policy.

---

Complete YAML Structure

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

This policy only allows app: frontend pods to contact app: backend pods on port 8080. Check the Kubernetes Training Complete Guide to learn more about network architecture.

---

Available Selectors

Example: Combined Selector

ingress:
- from:
- namespaceSelector:
matchLabels:
project: monitoring
podSelector:
matchLabels:
app: prometheus

Remember: When podSelector and namespaceSelector are at the same level (same dash), it's a logical AND. Two separate dashes = logical OR.

---

Essential Deny-All Policies

Deny All Ingress

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

Deny All Egress

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

Deny All (Ingress + Egress)

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

These policies are fundamental for the CKS exam, which requires a 67% score in 2 hours (Linux Foundation). The LFS460 training covers these scenarios in detail.

---

Common Use Cases

Allow DNS (Egress)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-dns
spec:
podSelector: {}
policyTypes:
- Egress
egress:
- to:
- namespaceSelector: {}
podSelector:
matchLabels:
k8s-app: kube-dns
ports:
- protocol: UDP
port: 53
- protocol: TCP
port: 53

Allow External CIDR

egress:
- to:
- ipBlock:
cidr: 203.0.113.0/24
except:
- 203.0.113.128/25
ports:
- protocol: TCP
port: 443

Multi-Port

ingress:
- from:
- podSelector:
matchLabels:
role: api-client
ports:
- protocol: TCP
port: 80
- protocol: TCP
port: 443
- protocol: TCP
port: 8080

Find more examples in the kubectl cheat sheet.

---

Debugging Commands

Quick Diagnosis

# Check installed CNI
kubectl get pods -n kube-system | grep -E "calico|cilium|weave"

# List NetworkPolicies in a namespace
kubectl get netpol -n production

# See pods targeted by a policy
kubectl get pods -n production -l app=backend

# Test connectivity
kubectl exec -it test-pod -- nc -zv backend-svc 8080

Remember: Without a compatible CNI, kubectl get netpol returns objects but they have no effect. Always verify your CNI.

---

CNI Verification

Cilium leverages eBPF for advanced network policies.

---

Common Pitfalls

Common Mistake: AND vs OR

# OR: allows ns1 OR pods with label
- from:
- namespaceSelector:
matchLabels:
name: ns1
- podSelector:
matchLabels:
app: web

# AND: allows pods with label IN ns1
- from:
- namespaceSelector:
matchLabels:
name: ns1
podSelector:
matchLabels:
app: web

---

Connectivity Tests

# Create a test pod
kubectl run test-client --image=busybox --rm -it -- sh

# From the test pod
wget -qO- --timeout=2 http://backend-svc:8080
nc -zv backend-pod-ip 8080

# Check CNI logs (Calico)
kubectl logs -n kube-system -l k8s-app=calico-node --tail=50

To master these debugging techniques, check out the Kubernetes tutorials and practical guides and the Kubernetes objects and API resources memo.

---

Evaluation Order

1. If no NetworkPolicy targets a pod: all traffic is allowed
2. If a NetworkPolicy targets a pod: only explicitly allowed traffic passes
3. Policies are additive: multiple policies = union of rules

Remember: An empty NetworkPolicy with policyTypes: [Ingress] blocks all incoming traffic because no ingress rule is defined.

---

Best Practices

Adopt a deny-by-default approach: first create a deny-all policy, then add explicit exceptions.

Label systematically: consistent labels (app, tier, env) simplify policy writing.

Document each policy: add annotations explaining the purpose of each rule.

Test before production: validate your policies in a test namespace with ephemeral pods.

The CKS exam tests these skills in real conditions. With 104,000 CKA candidates (49% growth year-over-year according to CNCF Training Report), CKS certification differentiates security profiles. Learn to deploy your first pod before implementing complex policies.

---

Take Action

NetworkPolicies represent a key skill for CKS certification and securing Kubernetes clusters in production. To structure your learning:

• LFS460 Kubernetes Security Fundamentals Training: 4 days to master NetworkPolicies, admission controllers, and runtime security
• LFS458 Kubernetes Administration Training: 4 days to consolidate your cluster basics before security specialization
• Kubernetes Fundamentals: 1 day to discover the ecosystem if you're starting out. For more information, check our review of the best Kubernetes lab platforms.

For more information, check our Kubernetes training Paris in-person. For more details, see our Deployment and Production Kubernetes training.

Contact our advisors to build your path to CKS certification.