--- title: "An insider’s view into Tigera Secure design decisions (part 1)" source: "https://www.tigera.io/blog/an-insiders-view-into-project-calicos-design-decisions-part-1/" --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # An insider’s view into Tigera Secure design decisions (part 1) By [Cody McCain](https://www.tigera.io/blog/author/cody/) on May 24, 2018 • 5 min read In this 3-part blog series I’ll be discussing - Tigera Secure design decisions - Federating policy across fault domains - Creating a unified policy domain between legacy and cloud-native environments This first blog in the series will provide an insider’s view into Tigera Secure and our design decisions in implementing the technology. Enforcing policy that governs network security and connectivity for legacy and cloud-native apps is core to what we do here at Tigera – so much so that we sometimes take for granted the design decisions that created a framework that protects millions of workloads daily. In this series of posts, I am going to pull back the curtain and share with you a deeper look into the core design decisions that went into Tigera Secure  that have enabled network security and connectivity to be applied reliably in so many contexts. Before diving in, I wanted to share a quick insight. I have always found it intriguing how others perceive the world around them and learn new things – having four young children at home, and I am granted a front row seat to this discovery daily. Likewise, coming to a new programming language or paradigm, we are forced to quickly learn what to focus on immediately and what to save for later, after we have absorbed and learned by experience. I have also taught several Kubernetes and related courses over the last two years which have given me the opportunity to learn from students about their initial perception of this new ecosystem. Many of the students come from a traditional software development environment where delivering software into production is a very tedious and hands-on process. When asking the students to share what they enjoy most about this new distributed computing paradigm compared to what they are forced to do in their current systems, I often hear how they like describing the desired outcome rather than managing the operations and logic that it would take to achieve a result. The reality is distributed computing is hard and deploying software that is assembled with microservices in the traditional world is non-scalable. However, Kubernetes has lowered the barrier of entry into this new way of deploying and managing software by hiding its complexity behind a declarative API. A declarative configuration enables less work for the practitioner and yet yields a more reliable result. Another feature students rave about is labels. Labels provide flexibility for selecting and targeting platform primitives when applying behavior to them or when using them for derivative configurations. This simple primitive makes it easy to target and describe the configuration of multiple concerns within a system. These are just two of the traits that ease the adoption of network policy in Tigera Secure. In this post, I will discuss why we took a declarative approach to policies. As beginning computer programmers, we learn the difference between imperative and declarative programming. Imperative programming is a style of programming where a set of statements sequentially change the state of something until a goal is reached. In this style, we tell the computer how to accomplish a task. Declarative programming, on the other hand, is a style of programming where the elements of a computation or the goal of what must be accomplished are described. Instead of describing how to accomplish a task, we describe what we would like accomplished. Large cloud-native and distributed computing platforms have a lot of moving parts, which consequently means lots of changing states. An imperative approach to any configuration, including policy, would require the end user to understand the ins and outs of the state machines that govern these systems. That level of knowledge is impractical and would eliminate any gains from abstracting away policy implementation. This is the primary reason configuration is declarative within Tigera Secure. The onus is placed on Tigera Secure userbase to understand the interaction between the policy engine and the other moving parts of the distributed system. Another requirement for a policy engine is well-understood behavior. Imperative statements are a point in time action and therefore, they are dependent on the current state and time at which they are executed. Looking at an imperative statement without all of the environment/state/time context makes it impossible to understand what it does. Since a declarative approach describes outcomes and not methods, this can be easily digested by a reviewer with little working knowledge of the underlying moving parts. Finally, as organizations continue to decompose their monoliths into microservices, it becomes increasingly important to also decompose policies into micropolicies (see my recent blog on [micropolicies](https://www.tigera.io/blog/network-micropolicies/) for more information).  A declarative policy can be more easily traversed and composed because the intermixing and order of the rules is handled by the policy engine, not imperative instructions from the end user. So, by keeping policies declarative, we keep the onus on the Tigera team for getting state management right, ease the learning curve and enable both policy creators and auditors to quickly comprehend the intent of a policy, and enable composition and precedence of policy without worrying about implementation side effects. In the next blog, I will peel the onion further on our design decisions. In the meantime, I invite you to learn more about Tigera’s [Secure is here](https://docs.tigera.io/).   [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/)