--- title: "Just Because It Says It’s an ID, Doesn’t Mean that It’s Reliable" source: "https://www.tigera.io/blog/just-because-it-says-it-is-an-id-it-doesnt-mean-that-its-reliable/" --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # Just Because It Says It’s an ID, Doesn’t Mean that It’s Reliable By [Christopher Liljenstolpe](https://www.tigera.io/blog/author/chris-liljenstolpe/) on Jul 23, 2018 • 4 min read For almost as long as we have networked computers, we have used the network location or address as their primary identity. Using network location might have made sense when there was a 1:1 mapping between a computer and the thing it was acting for (user, application, etc.) and when the environment was fairly static. Those computers ran the same software, sat connected to the same network switch, and maintained the same IP address for years. However, this was never really a primary identity. The address used as an identity had no actual relationship with the thing being identified other than by the accident of provisioning. It carried no real description or context. It was up to some user or system to imbue that secondary identity with meaning. That is inherently a manual process. The mapping that provides that meaning is both fallible and not amiable to rapid change. Times have changed, both of these assumptions (static environment and 1:1 mapping) are no longer valid. This is not a new revelation or development. They started to crumble more than a decade ago when VMs hit the scene, but the current evolution of containers and dynamic orchestration completely puts paid to those assumptions, let alone the oncoming serverless or Function as Service development. However, the developments that have brought the era of the secondary ID to an end also have brought the technological developments that allow us to create primary identities and use them in the definition of network security policies. Since we now have real-time control loops built into scaleable orchestrators and schedulers that are driven by metadata, such as in the Kubernetes environment, we can reliably use descriptive metadata as a primary identity. That metadata may describe the provenance of the entity, its build or release version, its vulnerability or trust state, the roles or personalities that the entity meets or fulfills, etc. Since these are descriptive, they are intrinsically reliable as a source of identification, or at least as reliable as the entity that applied those descriptive metadata labels. As we have discussed in many other blog posts, we use these metadata labels in Tigera’s solutions to apply policies and make log files meaningful, even after the secondary IDs like IP address have lost all meaning. An example of this is that in a container environment IP addresses are reused as containers are created and destroyed. Therefore, IP addresses can’t be used as a vehicle for policy, as the policy would have to be changed every time an IP address changed (which is constantly in a container environment). Similarly, a log entry where the identity is keyed to the IP address becomes useless as soon as the IP address is reused. A corollary to this is the concept of multiple disparate signals that are linked back to the same ID increases the reliability of the overall signal, especially when the signal is used to determine trust.  Let’s take, for example, a policy that matches simply on the destination port of a given flow. That is a single signal that I would match to an ID. If we assume that parts of the infrastructure may be compromised (a key concept in the Zero Trust model), making a trust decision (i.e., should a given flow be allowed) based just on that data, there isn’t much trust that can be assigned. However, let’s say that we have a set of metadata labels that are meaningful. This set of metadata labels is not only to a layer 3 & 4 match, but also to a layer 7 method (such as HTTP get of a given URI) and TLS certificate. A much more substantial level of trust can be achieved with multiple disparate signals from metadata labels, coming from different parts of the application and infrastructure, all agreeing with the same primary ID. In the end, trust and ID are inexorably linked. ————————————————- [**Free Online Training**](https://www.tigera.io/events/) Access Live and On-Demand Kubernetes Tutorials [**Calico Enterprise – Free Trial**](https://www.calicocloud.io/home) Solve Common Kubernetes Roadblocks and Advance Your Enterprise Adoption [Open Source](https://www.tigera.io/tags/open-source/)[Products](https://www.tigera.io/tags/products/) ## Related posts [![Meet Mylo: An AI-native way to work with Calico](https://www.tigera.io/app/uploads/2026/09/Meet-Mylo-An-AI-native-way-to-work-with-Calico.png)](https://www.tigera.io/blog/meet-mylo-an-ai-native-way-to-work-with-calico/) #### [Meet Mylo: An AI-native way to work with Calico](https://www.tigera.io/blog/meet-mylo-an-ai-native-way-to-work-with-calico/) By [Phil DiCorpo](https://www.tigera.io/blog/author/phil-dicorpo/) on Sep 3, 2026 A library of Calico tools and skills — delivered through the Calico MCP Server What if your hardest network question took ten minutes instead of ten days? Anyone who has operated Kubernetes networking at scale... [Read more](https://www.tigera.io/blog/meet-mylo-an-ai-native-way-to-work-with-calico/) [![The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/app/uploads/2026/08/The-Safest-Place-to-Run-an-AI-Agent-Is-On-a-Cluster-That-Doesnt-Trust-It.png)](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) #### [The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Aug 27, 2026 Every organization running AI agents has already made a hosting decision. Most made it by accident. The sales team switched on the agent built into their CRM. Engineering is piloting a coding agent in a... [Read more](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) [![AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/app/uploads/2026/08/AI-Red-Team-Agents-Automate-Attacks-on-your-AI-Agents.-Runtime-Policies-Automate-their-Defense.png)](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/) #### [AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Aug 24, 2026 The AI red teaming market grew up fast this year. OpenAI bought Promptfoo, Cisco and Microsoft shipped automated attack suites, and a seed-stage startup publicly compromised 50 of 55 live customer service bots. These platforms... [Read more](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/)