Zero Trust Networking with Cilium

Introduction

In today’s cloud-native landscape, the traditional perimeter-based security model is no longer sufficient. With microservices communicating across dynamic, ephemeral environments, the zero trust model has become the gold standard for Kubernetes security. The core principle is simple: never trust, always verify. No workload should be implicitly trusted, regardless of its network location.

Cilium is an open-source CNI (Container Network Interface) plugin that leverages eBPF (Extended Berkeley Packet Filter) to provide highly scalable networking, security, and observability for Kubernetes. Unlike traditional iptables-based approaches, Cilium applies security policies at the kernel level with minimal overhead, making it ideal for enforcing zero trust principles at scale.

In this tutorial, you will learn how to:

• Install Cilium on a Kubernetes cluster
• Implement zero trust network policies using Cilium’s identity-based security model
• Enforce Layer 7 (HTTP/gRPC) policies for fine-grained API-level control
• Encrypt inter-node traffic with Cilium’s WireGuard integration
• Monitor and audit network flows with Hubble
• Apply practical zero trust patterns to a sample microservices application

Understanding Zero Trust in Kubernetes

Zero trust architecture (ZTA) is built on three foundational principles:

1. Verify explicitly — Always authenticate and authorize based on all available data points (identity, context, workload labels).
2. Use least-privileged access — Limit access with just-in-time and just-enough-access (JIT/JEA).
3. Assume breach — Segment access, encrypt all traffic, and continuously monitor for anomalies.

In a Kubernetes context, this translates to:

• Default deny: All ingress and egress traffic is blocked unless explicitly allowed.
• Identity-based policies: Policies are based on workload identity (labels/service accounts), not IP addresses.
• Layer 7 awareness: Policies can inspect HTTP methods, paths, and even gRPC calls.
• Encryption in transit: All pod-to-pod traffic is encrypted, including east-west traffic within the cluster.

Cilium excels at all of these because eBPF allows it to see and control traffic at multiple layers of the network stack without modifying application code.

Step 1: Installing Cilium on Your Cluster

Let’s start by installing Cilium. The recommended way is using the cilium-cli tool, which handles Helm chart installation and validates the setup.

1.1 Install the Cilium CLI

# Download the latest Cilium CLI
curl -L --remote-name-all https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz{,.sha256sum}
sha256sum --check cilium-linux-amd64.tar.gz.sha256sum
sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
rm cilium-linux-amd64.tar.gz{,.sha256sum}

Verify the installation:

cilium version
# Expected output: cilium-cli: v0.16.x (or newer)

1.2 Install Cilium on Your Cluster

Install Cilium with encryption enabled and Hubble (the observability layer):

cilium install \
  --set encryption.type=wireguard \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

# Wait for all pods to be ready
cilium status --wait

This command enables WireGuard-based encryption for all pod-to-pod traffic, implements zero trust at the transport layer, and enables Hubble for network observability.

Verify that all Cilium pods are running:

kubectl -n kube-system get pods -l k8s-app=cilium
# NAME               READY   STATUS    RESTARTS   AGE
# cilium-xxxxx       1/1     Running   0          2m

1.3 Deploy the Hubble UI

cilium hubble enable --ui

# Port-forward to access the UI (in a separate terminal)
cilium hubble ui
# Opens at http://localhost:12000

Step 2: Applying a Default Deny Policy

Before we allow any traffic, we must establish a default deny posture. CiliumNetworkPolicy (CNP) is the custom resource definition (CRD) that Cilium uses.

2.1 Default Deny Ingress on All Pods

cat <

cat <

cat <

kubectl -n demo get pods
# NAME       READY   STATUS    RESTARTS   AGE
# frontend   1/1     Running   0          30s
# api        1/1     Running   0          30s
# db         1/1     Running   0          30s

cat <

cat <

cat <

cat <

# Test frontend can reach api
kubectl -n demo exec frontend -- wget -qO- http://api-svc:5000/get | head -5
# ✅ Should return JSON response

# Test frontend CANNOT reach db directly
kubectl -n demo exec frontend -- wget -qO- http://db-svc:6379 2>&1
# ❌ Connection refused / timeout — policy is enforced!

# Test api CAN reach db
kubectl -n demo exec api -- wget -qO- --timeout=2 http://db-svc:6379 2>&1
# ✅ Service response (Redis hates plain HTTP but connection is established)

cilium config set --restart proxy-http-enabled true

cat <

# ✅ Allowed: GET /get
kubectl -n demo exec frontend -- wget -qO- http://api-svc:5000/get

# ✅ Allowed: POST /post
kubectl -n demo exec frontend -- wget -qO- --post-data='{"key":"value"}' http://api-svc:5000/post

# ❌ Denied: GET / (root path)
kubectl -n demo exec frontend -- wget -qO- http://api-svc:5000/ 2>&1
# "Access denied" — Layer 7 policy enforced!

# ❌ Denied: DELETE /get (wrong method)
kubectl -n demo exec frontend -- wget -qO- --method=DELETE http://api-svc:5000/get 2>&1
# "Access denied"

# Check WireGuard status on any Cilium node pod
kubectl -n kube-system exec ds/cilium -- cilium encrypt status
# Expected: Wireguard is enabled

cilium config set encryption-type wireguard
cilium config set encrypt-node true

# Enable the Hubble client
cilium hubble enable

# Port forward to the Hubble relay
kubectl -n kube-system port-forward svc/hubble-relay 4245:80 &

# Watch live flows
hubble observe --namespace demo --not ip=127.0.0.1

# See flows dropped by policy
hubble observe --namespace demo --verdict DROPPED

# Observe HTTP layer data
hubble observe --namespace demo --protocol http

cat <

cat <

cat <

kubectl delete namespace demo
kubectl delete ciliumnetworkpolicies --all
kubectl delete ciliumclusterwidenetworkpolicies --all