Zero Trust Security with Kubernetes Network Policies: A Practical Guide

By default, Kubernetes allows completely unrestricted pod-to-pod communication across all namespaces. If a single container is compromised, the attacker gains network access to every service in the cluster — databases, internal APIs, and sensitive services included.

Kubernetes Network Policies provide the native solution to this problem. This guide walks through implementing a complete zero trust network, from Default Deny to advanced L7 policies with Cilium and Calico, using practical YAML examples throughout.

Kubo is a managed Kubernetes platform from ¥48,000/month that includes baseline Network Policy enforcement as part of its security foundation.

Understanding the Zero Trust Model

Zero trust means "nothing is trusted by default; every connection must be explicitly allowed." According to Groundcover's explanation, in Kubernetes this means that pods can only communicate when there is a clear policy permitting it.

Why Kubernetes Needs Zero Trust

Atmosly's security guide identifies these critical risks:

• Lateral movement: A compromised pod can reach every service in the cluster
• Data exfiltration: Direct access to database pods becomes trivial
• Supply chain attacks: Compromised third-party containers can explore internal networks

Network Policies control traffic at OSI layers 3-4 (IP/port) to mitigate these risks.

On Kubo with Captain.AI, communication between AI workers is also restricted to the minimum necessary via Network Policies.

Default Deny: The Foundation of Zero Trust

Deny All Ingress Traffic

The Default Deny policy from the Kubernetes official documentation:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}      # Empty selector = applies to all pods in namespace
  policyTypes:
  - Ingress             # Deny ingress only; egress remains allowed

Deny All Egress Traffic

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

Deny All Traffic (Ingress + Egress)

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

Critical: After applying Default Deny, you must add explicit allow policies for required communication, or your applications will stop working. In particular, never forget to allow DNS (port 53) egress.

Practical Network Policy Patterns

Pattern 1: Frontend to Backend to Database

A typical three-tier architecture with Network Policies:

# Backend: Allow ingress only from frontend
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
---
# Database: Allow ingress only from backend
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-database
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - protocol: TCP
      port: 5432

Pattern 2: Cross-Namespace Communication Control

Namespace-based isolation recommended by Red Hat's guide:

# Allow metrics collection only from monitoring namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: monitoring
    ports:
    - protocol: TCP
      port: 9090

Pattern 3: DNS and External Communication

The essential DNS allow rule emphasized by Daily.dev's best practices:

# Allow DNS egress for all pods (required with Default Deny Egress)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

Cilium vs Calico: Choosing an Advanced CNI

Standard Kubernetes Network Policies are limited to L3-L4 (IP/port) control. For L7 (HTTP/gRPC) policies and advanced features, consider Cilium or Calico.

Cilium

According to Cilium zero trust implementation guides:

• eBPF-based: High-performance packet processing at the kernel level
• L7 policies: Filter by HTTP method, path, and headers
• DNS-based egress control: Restrict external destinations by FQDN
• Hubble: Real-time network flow visualization

# Cilium L7 policy example: Allow only GET requests
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: l7-api-policy
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/v1/.*"

Calico

According to Calico's zero trust guide:

• BGP routing: High scalability for large networks
• GlobalNetworkPolicy: Cluster-wide policy enforcement
• Policy tiers: Hierarchical policy management (Security > Platform > Application)
• Enterprise-ready: Mature compliance capabilities

Phased Rollout: Monitor-then-Enforce

2026 best practices recommend a "Monitor-then-Enforce" lifecycle to avoid breaking production traffic.

Step 1: Map Current Traffic Flows

Use Hubble (Cilium) or Calico Enterprise flow visualization to record actual communication patterns.

Step 2: Test Policies in Audit Mode

Apply policies in staging environments and verify no unintended blocks occur.

Step 3: Enforce Gradually

Apply Default Deny namespace-by-namespace, confirming stability before moving to the next.

Step 4: Continuous Monitoring and Iteration

Update policies continuously as new services are added and communication patterns change.

Zero Trust Implementation Checklist

Implement zero trust networking with Kubernetes Network Policies by following these steps:

• Apply Default Deny (Ingress + Egress) to all namespaces
• Explicitly allow DNS egress
• Allow minimum necessary application-to-application communication
• Control cross-namespace traffic
• Restrict egress to only required external destinations
• Deploy Cilium or Calico if L7 control is needed
• Follow the Monitor-then-Enforce phased rollout

Kubo applies baseline Network Policies at the platform level. From just ¥48,000/month, you get a secure Kubernetes environment ready for production. Combined with Captain.AI, your AI workload security is comprehensive.

For zero trust implementation support, contact us.