Kubernetes Network Policies: Invisible Walls Between Pods

Kubernetes Network Policies: Invisible Walls Between Pods

In the Kubernetes ecosystem, the security and isolation of our applications is one of the most critical concerns. Communication between pods — the different building blocks of your apps — happens by default with no restrictions whatsoever. In complex, microservice-based architectures especially, that opens the door to serious security holes. This is exactly where Kubernetes Network Policies come in. Network Policies let you weave invisible walls between your pods so you can control network traffic and tighten security.

In this article I’ll walk through what Kubernetes Network Policies are, why they matter, how they work, and how to put them to use in practice. The goal is to help you take network security in your Kubernetes environment to the next level using this powerful tool. Ready? Let’s start the journey of locking down communication between your pods.

What Are Kubernetes Network Policies and Why Do They Matter?

Kubernetes Network Policies are an API object you use to segment and control network traffic between pods in your cluster. At their core, they let you define rules that decide which pods can talk to which others, and on which ports. It’s an effective way to apply the “least privilege” principle at the network layer.

By default, Kubernetes imposes no network restrictions between pods. That means any pod can reach any other pod or service in the cluster. From a security standpoint, this carries serious risk — once one pod is compromised, an attacker can pivot to other pods with ease. Kubernetes Network Policies close that “open door” and meaningfully strengthen your security posture.

The importance of Network Policies stands out particularly in scenarios like these:

• Security Isolation: Isolating pods that handle sensitive data from the rest of your pods.
• Reducing the Attack Surface: Making it harder for an attacker to spread laterally inside the cluster after compromising a single pod.
• Compliance Requirements: Standards like PCI DSS require network segmentation and access control.
• Managing Service Dependencies: Ensuring services can only reach the other services they’re explicitly allowed to.

How Do Kubernetes Network Policies Work?

Kubernetes Network Policies start with an “allow-all” default that permits all traffic. But the moment you define a Network Policy, layered behavior kicks in on top of that default. The Network Policy filters incoming (ingress) and outgoing (egress) traffic for the pods it selects, according to the rules you’ve laid out.

The core building blocks of a Network Policy are:

1. podSelector: Decides which pods the policy applies to. An empty podSelector matches every pod.
2. policyTypes: Specifies whether this policy controls Ingress, Egress, or both.
3. ingress Rules: Control traffic coming into the pod. Define which source IPs are allowed in on which ports.
4. egress Rules: Control traffic leaving the pod. Define which destination IPs are reachable on which ports.

The traffic-filtering logic operates against the rules you’ve defined. If a flow doesn’t match any rule, it gets denied by default. That’s the “deny-all” mindset — anything not explicitly permitted is blocked. So when you design Network Policies, you have to be careful and make sure you’ve allowed every flow your apps actually need.

Core Network Policy Scenarios and Examples

Let’s look at how to apply some common scenarios using Kubernetes Network Policies. These examples will help you get a feel for the basic policy primitives.

Scenario 1: Deny All Inbound Traffic (Secure by Default)

Often, you want to block — by default — all traffic coming into pods in a namespace from outside or from elsewhere in the cluster. To do that, you can create a Network Policy that targets every pod and specifies no ingress rules at all.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: default
spec:
  podSelector: {} # Selects all pods
  policyTypes:
  - Ingress
  # Leaving ingress rules empty causes all incoming traffic to be denied.

This policy will permit no inbound traffic to any pod in the default namespace. You then layer on additional Network Policies that explicitly grant access to specific pods, giving you controlled access overall.

Scenario 2: Allowing Inbound Traffic to a Specific Group of Pods

Now let’s create a policy that allows traffic from pods labeled role=frontend into our pods labeled app=backend.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend # This policy applies to pods labeled 'app: backend'
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend # Allow traffic from pods labeled 'role: frontend'
    ports:
    - protocol: TCP
      port: 8080 # Only allow port 8080

This policy allows pods labeled app: backend in the default namespace to receive traffic only from pods labeled role: frontend, and only over TCP on port 8080. All other incoming traffic is denied.

Scenario 3: Restricting Outbound Traffic from a Pod (Egress)

Sometimes you want to make sure a pod can only reach specific services or IP addresses. That matters especially for pods handling sensitive data, or pods that should only talk to certain external services.

For example, let’s say our pod labeled app=database should only be able to reach the in-cluster app=redis pod over TCP on port 6379, plus a single external IP (say, 1.2.3.4) over TCP on port 443.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: limit-db-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: database # This policy applies to pods labeled 'app: database'
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: redis # Permission to reach the Redis pod
    ports:
    - protocol: TCP
      port: 6379
  - to:
    - ipBlock:
        cidr: 1.2.3.4/32 # Permission to reach a specific external IP
    ports:
    - protocol: TCP
      port: 443

With this policy, outbound traffic from the app: database pod is only possible to the Redis pod and the specified external IP, on the listed ports, over TCP. Every other outbound request is blocked.

What to Watch for When Building Network Policies

Being careful when you apply Kubernetes Network Policies is critical for avoiding unexpected outages and closing security gaps. A few important points:

1. The “Default Deny” Mindset: As much as possible, embrace “deny-all” thinking. Permit only traffic that’s explicitly allowed. That’s the safest approach.
2. Thorough Testing: Always test your policies thoroughly in a staging environment before rolling them out to production. Make sure every flow your application needs is permitted.
3. Labeling Strategy: Because Network Policies select pods based on their labels, having a consistent and meaningful labeling strategy is essential.
4. CNI Compatibility: Make sure the CNI plugin you’re running fully supports Network Policies and is up to date.
5. Namespace-Scoped Application: Network Policies are usually defined inside a namespace and apply to pods in that namespace. To manage cross-namespace communication, use NamespaceSelector.

It’s also worth remembering that Network Policies operate at L3/L4. That is, they control TCP/UDP ports and IP addresses. To filter on L7 information like HTTP headers, you’ll need more advanced solutions (Ingress Controllers or Service Meshes, for example).

Managing and Monitoring Network Policies

Managing and monitoring Network Policies effectively is an integral part of running a secure Kubernetes environment.

Management Tools:

• kubectl: The fundamental tool for creating, updating, and deleting Network Policies.
• GitOps Tools (Argo CD, Flux): Treating your Network Policies as code and managing them through GitOps principles gives you consistency and rollback capabilities.
• Network Policy Editors: Some tools make it easier to create Network Policies via visual interfaces.

Monitoring and Analysis:

• CNI Plugin Logs: Logs from the CNI plugin you’re running can help you understand policy violations or denied traffic.
• Project-Specific Monitoring Tools: Tools like Prometheus and Grafana let you observe network traffic and policy enforcement.
• Packet Analysis: When needed, doing packet-level analysis at the pod level with tools like tcpdump can help you diagnose problems.

Conclusion

Kubernetes Network Policies are an indispensable tool for securing network communication between pods. Adopting this technology is hugely important for hardening your applications, shrinking the attack surface, and meeting compliance requirements. Moving from an environment where everything is permitted by default to a controlled one where only the necessary communication is allowed will substantially strengthen your security posture.

In this piece I covered what Network Policies are, how they work, the core scenarios, and the points to watch out for. Bear in mind that using Network Policies effectively takes careful planning, thorough testing, and continuous monitoring. By making security a priority in your Kubernetes environment, you can run your applications on more solid and secure ground.

I hope this guide has helped you better understand Kubernetes Network Policies and start applying them in your own environments. Wishing you secure code and secure infrastructures!