Zero-Trust Kubernetes: Network Policy From First Principles

By default, every pod in Kubernetes can talk to every other pod. The frontend can reach the database. The logging sidecar can call the payment service. This is convenient for development and disastrous for security.

Why Zero-Trust Matters

The perimeter model is dead. Attackers who breach one workload shouldn't get free lateral movement to everything else. Zero-trust assumes the network is hostile — every connection must be explicitly allowed, authenticated, and authorized.

In Kubernetes, this means: deny all traffic by default, then allow only the specific connections your application needs. If the web frontend needs to call the API, allow that. If it doesn't need to reach the database, block it.

Network Policies: The Foundation

Kubernetes NetworkPolicy is a resource that controls traffic to and from pods. You select pods by labels, then define allowed ingress and egress. If no policy selects a pod, all traffic is allowed. Once any policy selects a pod, everything not explicitly allowed is denied.

Start with a default-deny policy in each namespace. This flips the model: nothing is allowed until you say so. Then add policies for each legitimate communication path. Yes, this requires knowing how your applications actually communicate.

Beyond Basic Network Policy

Standard Kubernetes NetworkPolicy has limitations. It doesn't support DNS-based rules, layer 7 filtering, or comprehensive logging. CNI providers like Calico add these capabilities. Calico's network policies can filter by DNS name, HTTP path, and protocol — and log every denied connection.

For egress to external services, consider Calico's DNS-based policies. Instead of hardcoding IP addresses for third-party APIs, allow traffic to 'api.stripe.com'. When their IPs change, your policies still work.

Service Mesh for Identity

Network policies work on IPs and ports. Service mesh adds identity. With Istio or Linkerd, each workload gets a cryptographic identity. Authorization policies can say 'only the frontend service can call the API' — regardless of what namespace or IP address the frontend happens to have.

mTLS between all services means traffic is encrypted and authenticated at every hop. Even if an attacker is on the network, they can't intercept or forge requests.

Practical Implementation

Don't boil the ocean. Start with your most sensitive workloads — the database, the payment service, anything holding customer data. Add default-deny policies to those namespaces first. Monitor for broken connections. Add allow rules for legitimate traffic. Expand from there.

Observability is critical. Use a CNI that logs policy decisions. When something breaks, you need to know whether it's the network policy or something else. Calico's flow logs and Hubble (for Cilium) provide this visibility.

Zero-trust in Kubernetes is achievable. It requires explicit network policies, potentially a service mesh for identity, and good observability. The effort is worth it — proper segmentation contains breaches and satisfies compliance requirements.

Key Takeaways

• Zero-trust network policy in Kubernetes means every pod-to-pod connection is explicitly permitted — nothing is allowed by default.
• Cilium and Calico both support L3/L4 network policies; Cilium additionally enforces L7 (HTTP/gRPC) rules using eBPF without a sidecar.
• Identity-based policy (using pod labels and service accounts rather than IP addresses) survives pod restarts and cluster scaling events.

Implementing Zero-Trust Network Policy Step by Step

Begin with a namespace-level default-deny policy. Apply the following in every production namespace: ingress and egress are both denied for all pods unless an explicit NetworkPolicy selector permits them. This single policy eliminates lateral movement between services that have no business communicating.

Next, enumerate your service dependencies. For each microservice, list the other services it must reach and on which ports. Translate this dependency map into NetworkPolicy resources. A typical API service policy allows ingress from the ingress-controller namespace on port 8080, and egress to the database namespace on port 5432 and to external HTTPS (port 443) for third-party API calls.

For fine-grained L7 enforcement without a full service mesh, Cilium Network Policies extend the standard Kubernetes API to allow and deny specific HTTP methods and paths. A payment service can be restricted to accept only POST requests on /v1/payment, blocking any other HTTP verb from any other service — even ones that share the same namespace.

Zero-Trust Beyond Networking

Network policy is one layer of a complete zero-trust Kubernetes architecture. Pair it with pod-level controls: run containers as non-root, enforce read-only root filesystems, and apply the Restricted pod security standard to all production namespaces. Use RBAC to limit service account permissions to the minimum required — no service account should have cluster-admin unless it explicitly needs it.

Our cybersecurity zero-trust practice designs and deploys layered zero-trust architectures for Kubernetes environments across financial services, healthcare, and government sectors. Contact us to assess your cluster's current posture.