Skip to main content
In this lesson we define key Cilium terms used throughout the architecture and internal operation of Cilium. These definitions are intentionally consistent so you can reliably map concepts (for example, policies and identities) to everyday Kubernetes objects such as Pods.

​
Endpoint

An endpoint in Cilium represents a network identity for which Cilium enforces network policy. In Kubernetes, each Pod receives its own IP address, so you can practically treat a Pod as a Cilium endpoint. Cilium generalizes this by stating “every IP address is an endpoint” to support non‑Kubernetes deployments. Cilium assigns each endpoint a unique numeric ID that the agent uses internally to manage that endpoint (for example, Pod1 → Endpoint ID 100, Pod2 → Endpoint ID 200).
A diagram titled "Cilium Endpoint" showing four pods (POD1–POD4) with pod icons, IPs (172.16.1.1, .20, .30, .40), Endpoint buttons and IDs (100, 200, 300, 400). Below them is a long bar labeled "Cilium Operator."
To inspect endpoints from a node’s Cilium agent, exec into the Cilium agent Pod and run cilium endpoint list:
Example (trimmed) output:
This listing shows per-endpoint numeric ID, identity, labels, IP address, and status. In day-to-day Kubernetes troubleshooting you can think of an endpoint as the corresponding Pod.
Remember: in Kubernetes, a Pod’s IP ≈ Cilium endpoint for practical policy and observability tasks. Use cilium endpoint list to map Pod IPs to Cilium endpoint IDs.

​
IP-based policy limitations

Traditional network policies are often IP-based: they allow or deny traffic by matching source/destination IPs. This approach presents operational challenges in dynamic environments (Kubernetes autoscaling, rolling updates, etc.):
  • Adding or removing Pods requires updating IP allowlists.
  • Rule changes must be propagated to all nodes, which is costly at scale.
  • Convergence delays can temporarily block legitimate traffic or allow unintended access.
For example, if backend 172.16.1.100 should only accept traffic from frontend 172.16.1.1, that mapping must be updated whenever frontends or backends change.
A slide titled "IP-Based Policies – Limitations" showing two frontend pods (172.16.1.20, 172.16.1.1) and two backend pods (172.16.1.100, 172.16.1.101). It states "Allow traffic only from the frontend; deny all others" and includes a table mapping allowed frontend sources to backend destinations.

​
Cilium identities

Cilium addresses IP volatility by decoupling policy from IP addresses: it assigns stable numeric identities to sets of endpoints that share the same semantic labels (for example, role=frontend). Policies are written against these identities rather than raw IPs, so they remain valid when pods scale or move.
A slide titled "Cilium Identities" showing three connected blocks — Security, Identity, and Networking (IP) — each with a colored icon and arrows indicating a left-to-right flow.
Benefits:
  • Identities remain stable across Pod lifecycle events.
  • Security policies are decoupled from changing network addresses, simplifying enforcement and scaling.
A slide titled "Cilium Identities" showing two colored cards. The left card reads "Consistent & Scalable — Identities stable throughout the pod's lifecycle," and the right card reads "Decouples Security from IPs — No reliance on changing network addresses."
How identities are derived
  • In Kubernetes, identities are derived from Pod labels (and other label sources).
  • All Pods that share the same set of labels are mapped to the same numeric identity.
  • Policies reference identities like role=frontend or role=backend, not IP addresses.
Example Pod manifests:
All Pods labeled role=backend share the same identity; likewise for role=frontend. A policy such as “allow traffic from frontend to backend” targets identities, so it remains unchanged as Pods are created or deleted. Note: labels may come from Kubernetes, the container runtime, or reserved/internal sources.

​
Verifying identities

To list identities known by a Cilium agent:
Example output:
Each identity row shows a numeric ID and the set of labels (the k8s: prefix indicates Kubernetes‑origin labels). You can correlate endpoints to identities using cilium endpoint list:
Trimmed example:
This output shows multiple endpoints (different Pod IPs) sharing the same identity (32563) because they have identical labels (role=frontend). Policies target identities, so scaling the frontend Pods does not require changing policies.
A slide titled "Verifying Identity" showing two rounded boxes: one labeled "container" with the text "Labels from the local container runtime" and the other labeled "k8s" with the text "Labels from Kubernetes." A small green "reserved" tag and a KodeKloud copyright appear at the bottom.

​
Quick reference table

Watch Video