Kubernetes Network Policies: A Complete Security Guide

Network policies are essential for securing Kubernetes clusters in production. In this guide, we’ll explore how to implement effective network policies to control pod-to-pod communication.

Why Network Policies Matter

By default, Kubernetes allows unrestricted communication between all pods in a cluster. While this simplifies development, it creates significant security risks in production environments. Network policies act as firewalls for your pods, controlling which pods can communicate with each other.

Prerequisites

Before implementing network policies, ensure you have:

• A Kubernetes cluster with a CNI that supports network policies (Calico, Cilium, Weave Net). For local development, check our MicroK8s setup guide - you can enable Calico with microk8s enable calico.
• kubectl configured to access your cluster
• Basic understanding of Kubernetes pods and namespaces (see our Pods beginner guide if you’re new to Kubernetes)

Understanding Network Policy Basics

A network policy consists of three main components:

1. Pod Selector - Which pods the policy applies to
2. Policy Types - Ingress (incoming), Egress (outgoing), or both
3. Rules - Allowed sources (ingress) or destinations (egress)

Creating Your First Network Policy

Let’s start with a simple deny-all policy:

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

This policy selects all pods in the production namespace and blocks all traffic. From here, you can add specific allow rules.

Allowing Specific Traffic

Here’s how to allow traffic from frontend pods to backend pods:

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

Common Patterns

Allow DNS Resolution

Most applications need DNS access. Here’s how to allow it:

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

Namespace Isolation

Isolate namespaces from each other while allowing internal communication:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}

Debugging Network Policies

When things don’t work as expected:

1. Verify CNI support: Not all CNIs support network policies
2. Check policy syntax: Use kubectl describe netpol <name>
3. Test connectivity: Use kubectl exec to run curl or ping
4. Review labels: Ensure pod labels match selectors

Best Practices

1. Start restrictive: Begin with deny-all, then add specific allows
2. Document policies: Use annotations to explain each policy’s purpose
3. Test in staging: Always validate policies before production
4. Monitor traffic: Use tools like Cilium Hubble for visibility
5. Version control: Store policies in Git alongside application code

Conclusion

Network policies are a fundamental security control for Kubernetes clusters. By implementing a deny-by-default approach and carefully allowing necessary traffic, you can significantly reduce your attack surface.

At Fraway, we help organizations implement secure Kubernetes infrastructure. Our CKA and CKAD certified engineers can assist with network policy design, implementation, and troubleshooting. Contact us to learn more about our Kubernetes consulting services.