Kubernetes Network Policies

Why Network Policies Matter

By default, every pod in a Kubernetes cluster can communicate with every other pod — regardless of namespace. This flat network model is convenient for development but creates a massive blast radius in production. Network Policies provide microsegmentation, limiting lateral movement if a pod is compromised.

Default-Deny Foundation

Start with a default-deny policy in every namespace, then explicitly allow required traffic:

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

This blocks all ingress and egress traffic for every pod in the production namespace. You then create allow policies for specific communication paths.

Allow Ingress from Specific Sources

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-ingress
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-service
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: ingress-nginx
      podSelector:
        matchLabels:
          app.kubernetes.io/name: ingress-nginx
    ports:
    - protocol: TCP
      port: 8080

This allows traffic to api-service only from the Nginx Ingress Controller — no other pod can reach it directly.

Allow Egress to Specific Destinations

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-egress
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-service
  policyTypes:
  - Egress
  egress:
  # Allow DNS resolution
  - to:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
  # Allow database access
  - to:
    - podSelector:
        matchLabels:
          app: postgres
    ports:
    - protocol: TCP
      port: 5432
  # Allow external HTTPS
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.0.0.0/8
    ports:
    - protocol: TCP
      port: 443

Common Policy Patterns

• Frontend → API only — Frontend pods can only talk to API pods, not directly to databases
• API → Database only — API pods can reach the database but not other services' databases
• Monitoring exempt — Allow Prometheus to scrape all pods for metrics
• DNS always allowed — Every pod needs DNS resolution (kube-dns on port 53)

CNI Requirements

Network Policies require a CNI plugin that supports them:

• Calico — Most popular, supports both L3 and L4 policies
• Cilium — eBPF-based, supports L7 policies (HTTP path/method filtering)
• Weave Net — Supports basic network policies
• AWS VPC CNI — Requires Calico as an add-on for network policy support on EKS

Testing Network Policies

# Deploy a test pod
kubectl run test-pod --image=busybox --rm -it --restart=Never -- sh

# Test connectivity from within the pod
wget -qO- --timeout=2 http://api-service.production:8080/health
wget -qO- --timeout=2 http://postgres.production:5432  # Should fail

Visualization

Use tools like Cilium Network Policy Editor or Orca to visualize allowed traffic flows. This makes it easy to audit policies and identify gaps in your security posture.

Eazy SaaS Tip: We implement network policies as part of our Kubernetes security hardening service. Starting with default-deny and explicit allow rules reduces the attack surface by 90% and is a key requirement for SOC 2 and ISO 27001 compliance.