This is the third post in the CKS exam preparation series. In the previous part we covered runtime security using Falco. Now we focus on Cilium network policies — one of the more nuanced topics on the exam.

As with the rest of this series: I will not provide exam answers. The goal is to help you understand the concepts and techniques so you can solve problems yourself.

What is Cilium?

Cilium is a container networking tool that uses the Linux kernel technology called eBPF (extended Berkeley Packet Filter) to dynamically inject code into the kernel. This allows it to implement security, networking, and observability logic efficiently — without modifying the kernel’s source code.

Cilium functions as a Container Networking Interface (CNI) plugin, but it also doubles as an observability platform and service mesh. It’s a remarkably capable piece of software.

Kubernetes Network Policies — The Basics

By default, all pods in a Kubernetes cluster can communicate freely with each other. Network policies allow you to implement the Zero Trust principle by restricting traffic flows at OSI Layers 3 and 4.

Standard Kubernetes network policies can target traffic based on:

  • Pods via podSelector
  • Namespaces via namespaceSelector
  • IP ranges via ipBlock

One critical thing to know before moving on: in standard Kubernetes policies, an empty ingress rule {} allows all traffic. In Cilium, the same empty rule denies everything. This distinction will catch you out if you’re not expecting it.

Cilium Network Policies

Cilium significantly extends what’s possible beyond standard Kubernetes policies. It introduces additional selectors:

  • Endpoints (fromEndpoints, toEndpoints) — Cilium’s term for containers sharing an IP address, analogous to pods
  • Services (fromServices, toServices) — reference services directly by name or label, no hardcoded IPs needed
  • Entities (fromEntities, toEntities) — predefined categories like kube-apiserver, ingress, host, cluster, world
  • Nodes (fromNodes, toNodes)
  • CIDR ranges (fromCIDR, toCIDR)
  • DNS (toFQDN) — policy based on fully qualified domain names

Terminology difference

Cilium uses “endpoints” where Kubernetes uses “pods.” An endpoint is a collection of containers sharing an IP address — conceptually the same thing, just different naming.

Namespace handling

Rather than a dedicated namespaceSelector, Cilium references namespaces through labels inside matchLabels:

fromEndpoints:
  - matchLabels:
      k8s:io.kubernetes.pod.namespace: my-namespace

Service targeting

Instead of hardcoding IP addresses, Cilium lets you reference services directly:

toServices:
  - k8sService:
      serviceName: my-service
      namespace: default

Entities

Entities are pre-defined categorical references that simplify policy writing. Instead of maintaining IP ranges, you can write:

fromEntities:
  - kube-apiserver

This makes policies more readable and resilient to infrastructure changes.

Mutual Authentication (mTLS)

Cilium policies support mutual TLS authentication via the authentication property:

authentication:
  mode: "required"

When set, both client and server must authenticate each other before traffic is allowed through. This is a powerful security feature and worth understanding for the exam.

Exam Tips

The exam tests your ability to read and write Cilium policies under time pressure. A few things that help:

  • Know the documentation structure. You’ll have access to docs during the exam. Know where the Cilium policy examples live so you can find them fast.
  • Practice the selector syntax hands-on. The namespace label trick (k8s:io.kubernetes.pod.namespace) is easy to forget under pressure if you haven’t typed it out yourself.
  • Remember the empty rule inversion. {} means allow in Kubernetes, deny in Cilium. Getting this backwards will cost you points.

More posts in this series coming — including AKS-specific topics and Cilium Hubble for network observability.