Kubernetes Network Policies: Enforcing Zero-Trust at the Network Layer

With this baseline in place, you then layer on explicit allow rules.

Mistake 2: Allowing All Namespace Traffic Instead of Specific Pods

A common pattern is to open ingress from an entire namespace. This allows any pod in the namespace to reach the target pods — even compromised pods running cryptominers. An attacker who breaches one frontend service can now reach every backend.

The fix:Always combinenamespaceSelector with podSelector to lock traffic to specific pods:

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        tier: frontend
    podSelector:
      matchLabels:
        app: web-gateway

Now only pods labelledapp: web-gateway in the frontend tier can reach the selected pods. The podSelector inside a from block uses AND semantics with its sibling namespaceSelector — both conditions must match.

Mistake 3: Forgetting to Allow DNS (Egress Port 53)

This is the single most common cause of NetworkPolicy broke my app tickets. When you apply an egress deny-all policy, pods lose the ability to resolve DNS names — including the internal Kubernetes service DNS. Without port 53/UDP egress to kube-dns / CoreDNS, service discovery breaks silently:curl http://my-service hangs, and engineers waste hours blaming the CNI plugin.

The fix:Always include a DNS egress rule alongside any deny-all egress policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
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
    - protocol: TCP
      port: 53

Deploy this as a companion to every deny-all egress policy. CoreDNS typically runs inkube-system with the label k8s-app: kube-dns.

Mistake 4: Relying on IP Blocks Instead of Label Selectors

UsingipBlock rules for pod-to-pod communication inside the cluster is tempting but fragile. This falls apart when pods are rescheduled, the cluster scales up, the pod CIDR range changes, or a new node joins the cluster.

The fix:Use podSelector and namespaceSelector for all pod-to-pod communication. ReserveipBlock for external traffic — e.g., allowing a monitoring tool running outside the cluster:

ingress:
- from:
  - ipBlock:
      cidr: 203.0.113.0/24
      except:
      - 203.0.113.100/32

Mistake 5: Ignoring Egress Restrictions

Many teams focus entirely on ingress rules and leave egress unrestricted. This is a critical blind spot. A pod with full egress can exfiltrate data to a command-and-control server on the internet, mine cryptocurrency by reaching mining pools, or download malware from external registries.

The fix:Pair every ingress rule with explicit egress rules. Define what each tier of your application is allowed to reach:

egress:
- to:
  - podSelector:
      matchLabels:
        app: database
  ports:
  - protocol: TCP
    port: 5432
- to:
  - ipBlock:
      cidr: 0.0.0.0/0
      except:
      - 10.0.0.0/8
      - 172.16.0.0/12
      - 192.168.0.0/16
  ports:
  - protocol: TCP
    port: 443

Advanced Patterns: Cilium Network Policies

If your cluster usesCiliumas the CNI, you gain Layer 7 (HTTP/gRPC) policy enforcement through CiliumNetworkPolicy CRDs. This enables API-level allowlisting — you can permitGET /api/v1/users while blocking POST /api/v1/admin/delete:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-http-rules
spec:
  endpointSelector:
    matchLabels:
      app: my-api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/v1/users/.*"

Cilium also supports DNS-based policies, cluster mesh policies, and Kafka/MySQL protocol-aware rules — making it the de facto choice for zero-trust networking in production Kubernetes environments.

Monitoring and Debugging Network Policies

When a NetworkPolicy blocks traffic unexpectedly, diagnosing the issue can be painful. Essential tools:

• kubectl describe networkpolicy — Verify the policy spec.
• kubectl run tmp --image=nicolaka/netshoot -it --rm — Launch a netshoot pod and use nslookup, curl, nc, and tcpdump to test connectivity.
• cilium connectivity test — If using Cilium, built-in test validates all policies.
• Network Policy Editor (NPE)— Tools likenp-viewer generate visual maps of policy intent vs. actual traffic flow.

Complete Zero-Trust Network Policy Checklist

Use this checklist to audit your cluster before deploying a new workload:

• ☐ Deploy a default-deny-all NetworkPolicy to every namespace
• ☐ Allow DNS egress (UDP/TCP 53) explicitly in every namespace
• ☐ Define ingress rules with podSelector AND namespaceSelector
• ☐ Restrict egress for every tier — not just ingress
• ☐ Use ipBlock only for external traffic, never for pod-to-pod
• ☐ Verify your CNI actually enforces NetworkPolicies
• ☐ Test connectivity from a netshoot pod before and after
• ☐ Add Layer 7 policies with Cilium for HTTP/gRPC services
• ☐ Audit policy changes as part of your CI/CD pipeline
• ☐ Document which services depend on which other services in your repo

Related ShieldOps Reads

• Kubernetes RBAC Deep Dive: Least Privilege Access Control Patterns
• Kubernetes Pod Security in 2026
• Kubernetes Secrets Management: Beyond Base64
• Container Runtime Security: A Complete Guide
• ShieldOps Pricing

Frequently Asked Questions

Do all CNI plugins support Network Policies?

No. Flannel (default mode), Weave Net (some modes), and basic bridge plugins do not enforce policies. CNIs that support NetworkPolicies include Calico, Cilium, OVN-Kubernetes, Antrea, and Kube-router. Policies are accepted by the API server regardless of CNI support — they just will not do anything if the data plane ignores them.

Can a NetworkPolicy block traffic between containers in the same pod?

No. Containers in the same pod share the same network namespace and loopback interface. NetworkPolicies operate at the pod IP level, not the container level. Use seccomp profiles and Pod Security Standards to isolate containers within a pod.

How many NetworkPolicies can affect a single pod?

Multiple policies can select the same pod. Kubernetes unions the rules from all matching policies: if ANY policy allows ingress traffic on a given port, the traffic is permitted. There is no deny rule that overrides an allow — the union is always additive.

Is there a performance impact from Network Policies?

Yes, but it is negligible in most clusters. Each additional policy and rule adds to the iptables or eBPF ruleset that the CNI installs on each node. Cilium eBPF-based implementation processes policies at sub-millisecond overhead.

Can I use Network Policies with a service mesh like Istio?

Yes — Network Policies and service meshes are complementary. Network Policies enforce L3/L4 segmentation at the kernel level, while Istio enforces L7 policies via sidecar proxies. Deploy both for defense in depth.

How do I apply a NetworkPolicy only to new pods, not existing ones?

NetworkPolicies apply to all pods matching the podSelector at any time. To phase in a policy, start withpodSelector: {} and empty ingress: list (deny-all), then gradually add allow rules. Alternatively, use a new label on new pods and update the policy podSelector to match only that label.

Conclusion

Kubernetes Network Policies are the foundation of zero-trust network security in any containerized environment. Without them, your cluster is a flat network where any compromised pod can reach every other service. By layering default-deny policies, explicit allow rules, and CNI-aware advanced policies, you transform your cluster into a least-privilege fortress.

Start by deploying a default-deny-all policy in every namespace today. Then add selective ingress and egress rules one service at a time. TheShieldOps platformcan scan your live cluster and recommend the exact Network Policy rules you need based on observed traffic patterns.