--- title: "Policy Sandwich" source: "https://www.tigera.io/blog/policy-sandwich/" --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # Policy Sandwich By [Christopher Liljenstolpe](https://www.tigera.io/blog/author/chris-liljenstolpe/) on Jul 16, 2018 • 5 min read I was doing some Kubernetes network policy training earlier this week for the Infosec team at a large retailer (hi, guys), and we started talking about the process of policy creation and the [tiering capabilities](https://www.tigera.io/app/uploads/2018/02/wp-tigera-organizational-alignment-cloud-native.pdf) available in Tigera’s solution set. Before I dive in, let’s do a quick review.  Tigera’s policy tiering solution is presented in our UI as a set of “swim lanes” where each lane is a policy tier.  As an example, see below.  In the UI, the order of precedence for tiers is left to right.  The leftmost tier will be evaluated (in a top to bottom order).  If any policy in that tier allows or denies the traffic, the evaluation will stop.  However, if a policy ‘passes’ the traffic, it will be evaluated by the next tier in the hierarchy, working rightward to the eventual last, or ‘default’ tier. Now, we’ve always talked about the higher priority tiers being more top-down, conceptual, and strategic in their scope.  This is where you would put the compliance and infosec policies that enforce broad corporate policy goals such as: - Data sovereignty requirements - PCI / SOX / HIPAA / GDPR / ITAR compliance - Broad controls about what protocols are allowed into or out of the environment (i.e. no use of external DNS servers, no FTP or Telnet, etc). As you work right-ward, the policies become more tactical, bottom-up, and concrete in their scope.  This is where you start seeing policies that control things such as: - Tenancy - Dev / QA / Prod - Data replication Eventually leading to the very concrete and bottom-up policies that define the actual allowed flows between the various microservices that make up the application environment. A corollary of what was mentioned before is that the policies to the left should infrequently change, becoming more dynamic as you move rightward across the swimlanes.  If you were to graph this, it would look like there would be two opposing exponential curves.  One that is climbing toward infinite to the left and zero on the right that maps the ‘strategic’ value of the policy, while the opposing curve, high on the right, and low on the left would represent the rate of mutation of the policies. There is a problem with this model, however.  Where do you put the reactionary, broad-scoped, or **break glass** policies that you need to respond to *incidents* or enable *contingency operations*? Just like you would never number your router ACLs 1. 2, 3, etc. but instead 10, 20, 30, etc. to leave room for the un-planned rules that need to be inserted, you should make similar arrangements in your policy tiers. Therefore, we come to the graph that I drew on the whiteboard earlier this week, and which I recreate (in neater form) for you below. ![The whiteboard graph, recreated neatly: Tactical/Strategic vs. Precedence, showing a bell curve and an exponential rate of](https://www.tigera.io/app/uploads/2018/07/precedence-graph-600x464.png) There are two superimposed graphs here.  If we overlay this on the UI snapshot above, the leftmost swim lane would be on the left axis of this graph, and the rightmost (or default) swim lane would be to the far right of this graph. In this model, the left-most swim lanes are left for contingency or incident operations.  They may hold *pre-positioned* policies that are well planned out and only require labels to be applied to external or internal endpoints to become active, for example: - A policy that quarantines any endpoint that has the label quarantine = true applied to it. - A policy that blocks all traffic sourcing from one or more address ranges that are labeled with a black hole = true Other policies may exist here that are part of your pre-planned out DR or contingency operations plans. As an aside, you do have those and practice them regularly, right?  Finally, other slots here are for the policies you don’t know you need yet, but you will discover the urgent need to write them some very early (03:00) morning. The middle lanes are reserved for the compliance, continuity and proactive infosec policies.  The rightmost lanes are reserved for operational and development driven policies. With that in mind, the blue curve measures the relative tactical / concrete / bottom-up to strategic / conceptual / top-down weight of a given policy, with the higher strategic content leading to a higher value.  The green curve measures the relative rate of change policies themselves.  *Not* how frequently they get used, but how frequently they get changed. I’m not saying that this is the only way to lay out a policy tier model, but it is one that draws on having to do way too many contingency operations over the course of my career, and knowing that there will always be an (unpleasant) surprise waiting around the corner. ————————————————- [**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/)