--- title: "Dry Run: Your Kubernetes network policies with Calico staged network policies" source: "https://www.tigera.io/blog/dry-run-your-kubernetes-network-policies-with-calico-staged-network-policies/" --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # Dry Run: Your Kubernetes network policies with Calico staged network policies By [Reza Ramezanpour](https://www.tigera.io/blog/author/rezar/) on Jul 15, 2025 • 6 min read Kubernetes Network Policies (KNP) are powerful resources that help secure and isolate workloads in a cluster. By defining what traffic is allowed to and from specific pods, KNPs provide the foundation for zero-trust networking and least-privilege access in cloud-native environments. But there’s a problem: KNPs are risky, and applying them without a clear game plan can be potentially disruptive. Without deep insight into existing traffic flows, applying a restrictive policy can instantly break connectivity killing live workloads, user sessions, or critical app dependencies. An even scarier scenario is when we implement policies that we think cover everything and workloads actually work, but after a restart or scaling operation we hit new problems. Kubernetes, with all of its features, has no built-in “dry run” mode for policies, and no first-class observability to show what would be blocked or allowed which is the right decision since Kubernetes is an orchestrator not an implementer. This forces platform teams into a difficult choice, deploy permissive or no policies and weaken security, or Risk service disruption while debugging restrictive ones. As a result, many teams delay implementing network policies entirely only to regret it after a zero-day exploit like Log4Shell, XZ backdoor, or other vulnerabilities that can impact production. ## Impact The fear of breaking something becomes the top reason why Kubernetes environments go unsegmented. You can’t enforce what you can’t test safely. For instance, let’s say you want to secure a workload deployed by another team. You don’t control how it was configured. You’re tasked with writing a network policy, but: - You don’t know what dependencies it has. - You don’t know what clients are connecting to it. - You don’t want to cause downtime by getting it wrong. This leads to situations where security takes a backseat to stability. Policies get delayed or shelved. And worst of all, the blast radius remains wide open. ## Resolution That’s why **[Calico Open Source v3.30](https://www.tigera.io/blog/introducing-calico-3-30-a-new-era-of-open-source-network-security-and-observability-for-kubernetes/) introduces Staged Network Policies**, a simple but powerful way to test policies safely, with zero risk to production traffic. A staged policy audits what would happen if it were enforced without taking action on packets. Here’s how it works: - You write a `StagedNetworkPolicy` just like a regular KNP. (More about this later!) - Calico evaluates it during traffic processing, but doesn’t block or allow traffic based on it. - Instead, all decisions made by the staged policy are logged and viewable in Whisker or Service Graph. The best part about Calico is its interoperability, this means you can use staged policies to even evaluate your [Kubernetes network policies](https://www.tigera.io/learn/guides/kubernetes-security/kubernetes-network-policy/). ## Let’s Set the Scene **Note:** If you would like to run the experiment in your own environment, [click here](https://github.com/frozenprocess/calico_live/tree/main/sessions). To better understand staged network policies, let’s go over a scenario. Imagine we’re trying to secure an app called [anp-demo-app](https://github.com/frozenprocess/anp-demo-app/tree/main/manifests), running in the `web-demo` namespace. We don’t have control over how it was deployed, or anything about its required communication channels, and we can’t risk any downtime. However, to secure our app we need to implement policies so let’s evaluate what happens when we apply some KNPs to our workload. ![ANP Demo App shows container connectivity to Internet, coredns, DNS, and Kubernetes API.](https://www.tigera.io/app/uploads/2025/07/Dry-Run-Your-Kubernetes-network-policies-with-Calico-staged-network-policies-1.png) With plain KNPs, we might write something like this. An explicit allow to match our workloads ingress and deny any egress, and a default deny to match every traffic other than what we explicitly allowed in that namespace: ``` `apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-http-ingress namespace: web-demo spec: podSelector: {} policyTypes: - Ingress - Egress ingress: - from: ports: - port: 80 --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-my-app namespace: web-demo spec: podSelector: {} policyTypes: - Ingress - Egress` ``` Apply that and boom! The app stops responding. Something got missed, and we can verify it by opening the customer facing page again. ![ANP Demo App displays container connectivity failures and one successful API server connection.](https://www.tigera.io/app/uploads/2025/07/Dry-Run-Your-Kubernetes-network-policies-with-Calico-staged-network-policies-2.png) As you can see, our application is now being blocked by our policies and for a production environment this means downtime. ## The Power of Staged Network Policies Now, let’s delete the Kubernetes Network Policy resources that we created earlier and try the safe way with Calico staged policies. Staged network policies are unique Calico resources and all you need to do to use them is to change the `apiVersion` and add a prefix to your current policies. In our case, we need to change the `apiVersion` from `networking.k8s.io/v1` to `projectcalico.org/v3` and change the resource `Kind` to `StagedKubernetesNetworkPolicy`. **Note:** We are using `StagedKubernetesNetworkPolicy` specifically to target Kubernetes-native network policies. This distinction is important because Calico defines its own custom resources, NetworkPolicy and GlobalNetworkPolicy, which share the same name as Kubernetes NetworkPolicy but offer advanced capabilities. Calico’s policies support powerful features such as: - **Global policy scope** for cluster-wide enforcement - **Granular traffic control** beyond namespace boundaries - **HostEndpoint targeting**, enabling enforcement on host-level components like network interfaces, sockets, and ipsets, capabilities that standard Kubernetes network policies cannot achieve. If you’d like to learn more about Calico network policies, [click here](https://docs.tigera.io/calico/latest/network-policy/get-started/calico-policy/calico-network-policy). Now let’s try the same thing using StagedKubernetesNetworkPolicy: ``` `apiVersion: projectcalico.org/v3 kind: StagedKubernetesNetworkPolicy metadata: name: allow-http-ingress namespace: web-demo spec: podSelector: {} policyTypes: - Ingress - Egress ingress: - from: ports: - port: 80 egress: [] --- apiVersion: projectcalico.org/v3 kind: StagedKubernetesNetworkPolicy metadata: name: deny-my-app namespace: web-demo spec: podSelector: {} policyTypes: - Ingress - Egress` ``` This time, the application stays up. Everything works as before. Why? Because Calico Staged policies don’t affect traffic it only audits enforcement. You might be wondering that is great but how can I verify my staged network policies are actually doing something? ## Where to Observe Staged Policies? Using [Whisker](https://app.arcade.software/share/MC2wAFYlW1RJxKdWzZBl), Calico’s observability UI, we can: - Filter traffic flows by **staged policy decisions**, - See which connections would have been **allowed or denied**, - Get visibility into **source, destination, namespace, labels, ports**, and more. This observability gives you complete confidence. Once the staged policy behaves exactly how you want, simply promote it to a real KNP or convert it to a Calico-native `NetworkPolicy` resource for advanced features. ## Outcome Security shouldn’t require courage. With Calico’s staged policies, it doesn’t. Staged network policies are unique Calico resources that allow you to safely try and troubleshoot your policies inside or outside a production environment. This unique feature allows you to: ✅ Validate policies in real time without affecting traffic ✅ Iterate and improve security posture with no guesswork ✅ Enable DevSecOps workflows that are fast, safe, and visible ✅ Build least-privilege access confidently and continuously [Check out Calico Staged Network Policy in action in this demo](https://app.arcade.software/share/lr0xe33dw8UdAyrzDEQH) [How-To](https://www.tigera.io/tags/how-to/)[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/)