Explains Cilium networking terms including endpoints and identities and how identity based policies replace brittle IP based policies for Kubernetes Pod security and observability
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.
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).
To inspect endpoints from a node’s Cilium agent, exec into the Cilium agent Pod and run cilium endpoint list:
Copy
kubectl exec -n kube-system cilium-cfkzf -- cilium endpoint list
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.
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.
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.
Benefits:
Identities remain stable across Pod lifecycle events.
Security policies are decoupled from changing network addresses, simplifying enforcement and scaling.
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.
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.
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:
Copy
kubectl exec -n kube-system cilium-cfkzf -- cilium endpoint list
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.
