How to fix network policy denied in Kubernetes

KubernetesINTERMEDIATEMEDIUM

This error occurs when NetworkPolicy rules block traffic between pods. Fix it by verifying your CNI supports network policies, checking pod label selectors match, and ensuring both ingress and egress rules allow the required traffic paths.

What this error means

The "network policy denied" error indicates that Kubernetes NetworkPolicy rules are blocking traffic between pods. Unlike traditional firewalls, network policies in Kubernetes are implicit deny when any policy selects a pod—traffic not explicitly allowed is dropped. NetworkPolicies use label selectors to identify target pods and define allowed ingress (incoming) and egress (outgoing) traffic. When connections hang or timeout without explicit error messages, network policies are often the cause. Kubernetes doesn't expose which policy blocked traffic, making debugging challenging. Important: NetworkPolicies require a CNI plugin that supports them. Flannel does NOT support network policies—policies will be created but silently ignored.

How to fix "network policy denied"

1Verify CNI supports NetworkPolicy

Check if NetworkPolicy API is available and CNI supports it:

bash

# Check API availability
kubectl api-resources | grep networkpolicies

# Check which CNI is installed
kubectl get pods -n kube-system | grep -E 'calico|cilium|flannel|weave'

# Verify CNI plugin is running
kubectl logs -n kube-system -l k8s-app=calico-node --tail=20

If Flannel detected (no NetworkPolicy support):
Install Calico for network policy support:

bash

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/calico.yaml

2Verify pod and namespace labels match policy selectors

Check if pod labels match the policy's podSelector:

bash

# List pods with labels
kubectl get pods --show-labels -n production

# Check if pods match policy selector
kubectl get pods -l app=backend --show-labels -n production

# For cross-namespace policies, verify namespace labels
kubectl get namespace production --show-labels

# Add missing namespace label if needed
kubectl label namespace production tier=trusted

3Create default deny with explicit allow rules

Start with whitelist approach (block all, allow specific):

yaml

# Block all ingress traffic in namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
---
# Allow specific traffic
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

Apply and verify:

bash

kubectl apply -f network-policies.yaml
kubectl get networkpolicy -n production

4Allow DNS egress in restricted environments

When blocking all egress, pods can't resolve hostnames. Allow DNS:

yaml

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

Test DNS resolution:

bash

kubectl exec -it <pod-name> -n production -- nslookup kubernetes.default

5Test connectivity with debug containers

Test if network policies are blocking traffic:

bash

# Use debug container with network tools
kubectl debug frontend-pod -n production -it \
  --image=nicolaka/netshoot -- \
  curl --connect-timeout 5 -v http://backend:8080/health

# Test egress to external service
kubectl debug frontend-pod -n production -it \
  --image=curlimages/curl -- \
  curl --connect-timeout 5 https://api.example.com

# Temporary test pod
kubectl run --rm -i --tty test-curl --image=curlimages/curl --restart=Never \
  -n production -- curl http://backend:8080

Hanging requests (timeout) indicate policy is blocking traffic.

6Debug with CNI plugin logs

Check CNI plugin logs for policy enforcement:

bash

# Calico
kubectl logs -n kube-system -l k8s-app=calico-node | grep -i "denied\|policy"

# Cilium
kubectl logs -n kube-system -l k8s-app=cilium | grep -i "denied\|policy"

# Describe policy to see what it matches
kubectl describe networkpolicy <policy-name> -n production

Calico example denial log:

bash

deny=all from=10.0.1.5 to=10.0.2.10 sport=45321 dport=8080 proto=TCP

How to fix network policy denied in Kubernetes

What this error means

Typical symptoms

Common causes

How to fix "network policy denied"

Advanced notes

Related errors

Official resources & further reading