In a flat Kubernetes network, a compromised frontend pod can trivially pivot to attack internal backend databases. Traditional iptables-based network policies struggle with the scale and dynamic churn of ephemeral workloads. Cilium, leveraging eBPF (Extended Berkeley Packet Filter), provides highly performant and granular micro-segmentation at the kernel level.

The Challenge: Zero-Trust Networking in Kubernetes

Achieving Zero-Trust requires enforcing least-privilege communication. We must explicitly define which services can talk to each other, blocking all other traffic by default, without introducing unacceptable latency overhead.

The Solution: eBPF-Powered CiliumNetworkPolicy

We will define a CiliumNetworkPolicy (CNP) that isolates a PostgreSQL database, permitting ingress traffic only from authorized backend API pods over a specific port. Cilium implements this directly in the Linux kernel via eBPF maps.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "db-micro-segmentation"
  namespace: "production"
spec:
  endpointSelector:
    matchLabels:
      app: postgres-db
      tier: storage
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: backend-api
        tier: application
    toPorts:
    - ports:
      - port: "5432"
        protocol: TCP

Policy Anatomy and eBPF Mechanics

Let's dissect this policy to understand how Cilium translates declarative YAML into robust kernel-level security:

• kind: CiliumNetworkPolicy: Unlike standard Kubernetes NetworkPolicy objects, CNPs offer advanced features like L7 filtering (HTTP/gRPC/Kafka) and DNS-based rules, though here we focus on stringent L4 isolation.
• endpointSelector: matchLabels: app: postgres-db: This defines the target of the policy. Cilium agents running on each node assign a unique cryptographic identity to pods matching these labels. The policy is applied to the eBPF programs attached to the veth interfaces of these specific pods.
• ingress: fromEndpoints: matchLabels: app: backend-api: This establishes the "allow list". Only traffic originating from endpoints holding the identity of app=backend-api is permitted. Because Cilium uses identities rather than IP addresses, it seamlessly handles pod churn without constantly rewriting iptables rules.
• toPorts: port: "5432", protocol: TCP: Restricts the allowed traffic exclusively to the standard PostgreSQL port. An attacker compromising the backend API pod cannot probe the database pod on SSH (22) or any other port.

By defaulting to a deny-all posture and explicitly allowing via CNPs, you establish a resilient micro-segmented architecture where blast radiuses are strictly contained.