Cilium network policy & Hubble

Identity-based L3–L7, default-deny, encryption.

Runtime security is not only about processes — it is about what a compromised workload can reach. Cilium, the eBPF-based CNI, provides identity-aware network policy and observability that constrain lateral movement and reveal east-west traffic.

Identity-based, L3–L7 network policy

Cilium enforces network policy on workload identity derived from labels rather than fragile pod IPs, so a policy follows the workload as pods churn and reschedule. It spans L3/L4 (which identities may talk on which ports) up to L7 (which HTTP methods and paths, which Kafka topics, which DNS names), letting you express "the frontend may call the API’s /checkout via POST, and nothing else". A default-deny policy blocks all pod-to-pod traffic until explicitly allowed — zero-trust east-west that sharply limits how far a compromised pod can move.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata: { name: api-ingress }
spec:
  endpointSelector: { matchLabels: { app: api } }
  ingress:
    - fromEndpoints: [{ matchLabels: { app: frontend } }]
      toPorts:
        - ports: [{ port: "8080", protocol: TCP }]
          rules:
            http:
              - method: "POST"
                path: "/checkout"     # frontend may ONLY POST /checkout to api
# With a cluster default-deny in place, every other flow is blocked.

Visibility and encryption

Cilium’s Hubble gives flow-level observability — a live service map of who talks to what, with L7 detail — without instrumenting applications, which is invaluable both for writing tight policies and for investigating an incident. Cilium can also transparently encrypt pod-to-pod traffic with WireGuard or IPsec, so east-west confidentiality does not depend on every app implementing TLS. Together with Tetragon for process enforcement, Cilium gives you runtime control across both the network and process dimensions from a single eBPF foundation.