Kubernetes Network Policies

Welcome to the world of Kubernetes security! By default, Kubernetes is incredibly friendly perhaps a bit too friendly. Out of the box, any application (Pod) can talk to any other application in the cluster. This is called a “default-allow” behavior. Network Policies are your internal firewalls. They tell Kubernetes exactly who is allowed to talk to whom, ensuring that if a hacker compromises your front-end web app, they cannot secretly jump over to your backend database.

Think of a default Kubernetes cluster like a giant open-plan office where everyone can walk up to anyone else’s desk and start talking.

Now, imagine introducing a highly strict security badge system. You lock all the doors (this is your Default-Deny policy). Now, the HR team can only enter the HR room, and the IT team can only enter the Server room. You grant access strictly based on their ID badges. In Kubernetes, Network Policies are the door locks, and the Pod Labels (like app=frontend) are the ID badges!

Quick Reference

• Default Behavior: All Pods communicate freely; applying a NetworkPolicy instantly isolates the selected Pods.
• Ingress: Incoming traffic (Who can talk to me?).
• Egress: Outgoing traffic (Who can I talk to?).
• podSelector: The target—who does this policy apply to?
• Enforcement: Kubernetes just saves the rule; your CNI (Container Network Interface) does the actual blocking.
• Golden Rule: Always create a Default-Deny policy first, then whitelist what you need.

Concept	What it Means	Real-World Impact
Ingress Rule	Filters inbound connections	Stops rogue pods from querying your database.
Egress Rule	Filters outbound connections	Stops a hacked pod from downloading malware from the internet.
Namespace Selector	Matches labels on Namespaces	Allows traffic from the testing environment but not production.
CIDR Block	IP address ranges	Restricts traffic strictly to your corporate network IPs.

A Network Policy contains three vital pieces:

1. The Target: Defined by podSelector. This tells Kubernetes which pods this rule applies to.
2. The Direction: Defined by policyTypes (Ingress, Egress, or both).
3. The Rules: The actual list of who is allowed in (from) or out (to), based on IP blocks, Namespaces, or Pod labels.

Let us break this down into the absolute basics.

• Pods: The smallest unit in Kubernetes. They run your containers.
• Labels: Key-value pairs attached to Pods (e.g., role: database). Network policies rely heavily on these to identify targets.
• Isolation: A pod is “non-isolated” by default. The moment any NetworkPolicy selects that pod, it becomes “isolated,” and only explicitly whitelisted traffic is allowed.
• Additive Nature: Network Policies do not conflict; they add up. If Policy A allows traffic from the Web, and Policy B allows traffic from the API, the Pod will accept traffic from both. There are no “Deny” rules in standard Kubernetes Network Policies—you can only write “Allow” rules!

For production-grade architectures, the native Kubernetes NetworkPolicy API has limitations (e.g., no explicit deny, no Layer 7 filtering, no cross-cluster policies). As a DevSecOps Architect, you must look beyond the default API and choose a robust CNI.

• CNI Selection: Your network plugin must support policies. Flannel does not enforce them. You must use Calico, Cilium, or Weave Net.
• eBPF Technology: Modern CNIs like Cilium use eBPF (Extended Berkeley Packet Filter) in the Linux kernel for high-performance networking and security, completely bypassing traditional iptables for massive performance gains.
• Advanced Policies (CRDs): * CiliumNetworkPolicy: Allows L7 HTTP inspection (e.g., allow GET requests but block POST requests) and DNS-aware policies (allow egress to api.github.com without hardcoding IPs).
  • Global/ClusterNetworkPolicies: Standard K8s policies are limited to a single namespace. Tools like Calico and Cilium offer Custom Resource Definitions (CRDs) to apply rules across the entire cluster.
• GitOps Integration: Network policies should be treated as Code. Store them in Git and deploy them using tools like ArgoCD or Flux to ensure drift detection.
• Tool Links:
  • Cilium (eBPF-powered CNI): https://cilium.io
  • Calico (Standard robust CNI): https://www.tigera.io/project-calico

• Key Components: podSelector, ingress, egress, namespaceSelector, ipBlock.
• Key Characteristics: Additive rules, label-driven, namespace-scoped natively, relies on CNI for enforcement.
• Use Case: Isolating a multi-tenant cluster where Team A’s workloads must not communicate with Team B’s workloads.
• Benefits: Prevents lateral movement of attackers, meets compliance requirements (PCI-DSS, HIPAA), limits blast radius of compromises.
• Best Practices:
  • Always apply a Default-Deny-All policy per namespace.
  • Never forget to explicitly allow DNS resolution (UDP Port 53) in your Egress rules, otherwise, your pods will not be able to resolve service names!
  • Use Labels consistently across your organization.
  • Visualize your policies before deploying them in production.

• Problem: I applied a Network Policy, but traffic is still flowing!
  • Solution: Check your CNI. If you are using a basic CNI like Flannel, it silently ignores Network Policies. Migrate to Calico or Cilium.
• Problem: I applied a Default-Deny rule, and now my Pods keep crashing.
  • Solution: You likely blocked Egress traffic to the Kubernetes DNS server (CoreDNS). Your apps cannot resolve internal service names. You must add an Egress rule allowing traffic to the kube-system namespace on port 53.
• Limitation: You cannot log blocked traffic easily with native Kubernetes policies.
  • Solution: Upgrade to Calico Enterprise or Hubble (Cilium’s observability tool) to get real-time network flow logs and view dropped packets.
• Limitation: No explicit “DENY” rule.
  • Solution: Remember that K8s policies are whitelist-only. If you need a strict “DENY THIS SPECIFIC IP” rule, you must use CNI-specific CRDs (like CalicoNetworkPolicy).

• Kubernetes Official Network Policy Docs: https://kubernetes.io/docs/concepts/services-networking/network-policies/
• Kubernetes Network Policy Recipes (Great for learning!): https://github.com/ahmetb/kubernetes-network-policy-recipes