Learn Cilium - Identity-Based Security Model

#Introduction

From episode 4 we already know that every endpoint has an identity — a numeric value that is the key to Cilium's security model. Episode 5 dissects this concept deeply: how Kubernetes labels are turned into identity, why identity-based security beats IP-based security, and how default allow and deny work in Cilium.

This understanding matters because almost all the policies you will write in episodes 6 to 13 use identity as their raw material. If you understand what identity is and how it is formed, writing and reading policies becomes natural.

It is also important to distinguish two terms that are often confused: identity and labels. Labels are strings attached to a pod; identity is the number derived from the label set. You may change labels at any time, but identity only changes when the labels forming it change. All Cilium policies actually deal with identity, not labels directly.

#Labels Become Numeric Identity

Every pod in Kubernetes has labels — key-value pairs such as app=frontend or tier=web. Cilium takes the label set of a pod and turns it into an identity, i.e., a unique number. All pods using the same combination of labels will share the same identity.

The benefit is huge: when a policy is written against identity, and a new pod is born with the same labels, the policy applies automatically without any update. Conversely, in an IP-based approach, every new pod forces you to add a new rule. This is the fundamental difference between Cilium and Kubernetes' built-in NetworkPolicy.

Identity allocation is done by the Cilium Operator and synchronized to all agents. The label-to-identity mapping is stored in a Kubernetes object named CiliumIdentity, which you can view with kubectl:

kubectl get ciliumidentity

kubectl get ciliumidentity shows the list of identities along with the labels that triggered them. You will see many identities with labels similar to your cluster's pod labels.

A consequence of the label-to-identity mapping to be aware of: changing a pod's labels means changing its identity. If a deployment adds a new label, all running pods will get a new identity, and policies targeting the old labels can lose their scope. Changing labels on a deployment must be treated as a security change, not merely a metadata change.

#Default Allow vs Deny

One concept that often confuses people: Cilium allows all traffic by default. With no policy active, all communication is allowed — just like a default Kubernetes cluster. Default deny only appears after the relevant policy is applied.

The rule is simple and important to remember:

• An endpoint without ingress policy accepts all incoming traffic.
• An endpoint without egress policy can send anywhere.
• When the first policy is applied to an endpoint, the mode switches to default deny for that direction.
• Policies are additive: they combine all allowed rules.

This pattern is also called an allow-list. Instead of writing rules to block (block-list), you write what may pass, and everything else is automatically blocked. To understand why this matters, consider: in a block-list system, a forgotten rule means a security gap; in an allow-list, a forgotten rule means communication is held back — and that can be detected through observability.

This allow-list pattern is why designing policy from scratch often feels "easier" than fixing an already-messy policy: everything is explicit and verifiable. In episode 6 we will practice writing this allow-list for ingress and egress, and in episode 13 we will extend it to the application level.

#Policy Evaluation in the Data Plane

When a packet arrives at the destination endpoint, the data plane performs layered evaluation:

1. Read the packet's identity (taken from socket metadata or an additional header).
2. Look up the ingress policy applicable to the source identity.
3. Match against existing rules (label selector, port, protocol).
4. If it matches one of the allow rules, the packet is forwarded; if not, the packet is dropped.

All these steps happen inside the kernel with the help of eBPF. Because identity is included in the metadata, the data plane does not need to do expensive per-packet label lookups — it only compares identity numbers, which is much faster than comparing label strings.

This evaluation applies in both directions: ingress and egress. For egress, the data plane checks the outgoing policy of the source endpoint; for ingress, the data plane checks the incoming policy at the destination endpoint. A connection is only allowed if both sides allow it. This means ingress and egress policies work together — you cannot "smuggle" traffic by writing only one side.

#Seeing Identity with Cilium

Besides kubectl, identity can be seen from the data plane side. Enter the agent pod and run:

kubectl exec -n kube-system -it ds/cilium -- cilium-dbg identity list

cilium-dbg identity list shows the identity table from that node's point of view, including special identities such as host, remote-node, and world. Some important identities you will see frequently:

• host identity: traffic originating from the node itself.
• remote-node identity: traffic from other nodes in the cluster.
• world identity: traffic from outside the cluster (internet).
• unreserved identity: pods that have no policy yet or have not been identified.

To check the identity of one specific pod, use the command that shows labels and identity together:

kubectl exec -n kube-system -it ds/cilium -- cilium-dbg endpoint list

cilium-dbg endpoint list shows the Identity column for every endpoint. Match the identity number here with the numbers in cilium identity list to understand the label combination that forms it.

#Identity at the Kubernetes Level

Identity is not an abstract kernel concept; it is also exposed as a Kubernetes object. Two resources worth viewing:

kubectl get ciliumidentity
kubectl get cep -n default

kubectl get ciliumidentity shows identities along with their triggering labels from the control plane perspective. kubectl get cep -n default shows CiliumEndpoints — per-pod resources containing the IP address and the identity the pod is currently using.

This difference in point of view matters: cilium-dbg identity list reads the state inside the agent (data plane), while kubectl get ciliumidentity reads the state in the control plane. The two are usually in sync, but when they are not — for example a new identity not yet synchronized to the agent — that is the starting point of the problems we will discuss in episode 19.

kubectl get ciliumidentity -n default -o yaml | grep -A5 -B2 labels

kubectl get ciliumidentity -o yaml shows the full details of the label-to-identity mapping. By combining this output and cilium-dbg endpoint list, you can trace from a pod, to its labels, to its identity, to the policies targeting it — the chain that is the backbone of Cilium's security model.

#Closing

Key takeaways:

• Kubernetes labels are mapped to numeric identity by the Cilium Operator.
• Endpoints with the same labels share the same identity, whatever their IP.
• Cilium's default is allow all; default deny activates when the first policy is applied.
• Cilium policies are allow-lists: rules define what is allowed, the rest is blocked.
• Policy evaluation happens in the data plane by comparing identity, not label strings.
• Important identities: host, remote-node, world, and unreserved.

In the next episode 6, we will create the first CiliumNetworkPolicy — understand the CNP structure for ingress and egress, choose targets with label selectors, restrict ports and ranges, then apply and test policies using hubble observe. This is where the identity concept from this episode is really put to use.