--- title: "Automated namespace isolation with Calico" source: "https://www.tigera.io/blog/automated-namespace-isolation-with-calico/" --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # Automated namespace isolation with Calico By [Phil DiCorpo](https://www.tigera.io/blog/author/phil-dicorpo/) on Aug 09, 2023 • 6 min read Calico has recently introduced a powerful new policy recommendation engine that enables DevOps, SREs, and Kubernetes operators to automatically generate Calico policies to implement namespace isolation and improve the security posture of their clusters. This new recommendation engine is unique for three reasons: - **Calico’s policy recommendations work continuously in the background** over a user-configurable time period. This ensures that less frequent traffic flows are also accounted for in recommended policies. - **Policy recommendations leverage Calico’s policy tiers**. Tiers enforce an order of precedence on how Calico policies are evaluated and enforced. The recommended policies are placed in their own tier and Calico ensures each generated rule does not conflict with other policies you have implemented. - **Recommended policies are `StagedNetworkPolicies`**, allowing admins and operators to audit the behavior of these security policies before actively enforcing them. In this blog, we’ll dive into each of these areas in more detail and provide an in-depth overview of how policy recommendations work and how it can improve the security posture of your cluster. Before we get started, let’s quickly talk about namespace isolation and why it’s so important. ## Why is namespace isolation important? Namespaces are a foundational concept within Kubernetes. They help divide your cluster into logical units and provide a way to support multi-tenancy, where each “tenant” is a different project or application that may be owned and maintained by different development teams. Kubernetes has a number of features that allow you to segment resources and implement role-based access controls (RBAC) based on namespaces. This ensures that Dev Team A cannot inadvertently make changes to an application owned by Dev Team B. However, Kubernetes does nothing to control how these namespaces communicate with each other inside the cluster and with endpoints external to a cluster. By default, any workload can communicate with any other workload within a cluster. This is a problem for two reasons. - One is the [“noisy neighbor” problem](https://learn.microsoft.com/en-us/azure/architecture/antipatterns/noisy-neighbor/noisy-neighbor) that is inherent to any multi-tenant architecture. This is where an application bug could impact the availability or performance of other applications. Namespaces solve for some of these problems (e.g. setting resource limits), but does nothing to limit unrestricted communication that could inadvertently DoS an unsuspecting application. - The second has to do with the security posture of a Kubernetes cluster. Bad things do happen when you least expect it, and in the event of a breach, an attacker’s ability to “laterally move” around the cluster and perform recon is unrestricted. It’s likely that you’re already taking other measures to improve the security posture of your cluster like scanning images and code, or addressing misconfigurations. But unless you’re taking a least privileged approach to restricting workload communication, you may be leaving your applications vulnerable to unknown exploits and zero-day attacks. This is where Calico and policy recommendations can help you achieve complete namespace isolation. Let’s dive in and take a closer look … ## An “easy button” for namespace isolation and microsegmentation ![Screenshot of a website dashboard displaying various metrics and navigation options for user management and analytics](https://www.tigera.io/app/uploads/2023/08/Automated-namespace-isolation-with-Calico-1.gif) ### How does it work? Policy recommendations engine works by analyzing the flow logs that are generated by Calico for all of the workload communication in your cluster. Each log entry is rich with Kubernetes metadata such as namespaces, deployments, and services – in addition to information about ports, protocols, and domains associated with each flow. Once the engine is enabled, analysis of these logs occur according to a configurable **Process Interval** and **Stabilization Period**. The Process Interval setting determines how frequently the engine checks for new flow logs and makes updates to policies, and the Stabilization Period tells the engine how long to wait after the last update before marking a recommended policy as “Ready.” These settings give operators control over how the engine works, and can be modified to ensure that recommended policies can account for less frequent connections in your cluster – whether they occur over days or weeks. ![A table showing network policy rules, their namespaces, and allowed bytes, updated every 4 hours](https://www.tigera.io/app/uploads/2023/08/Automated-namespace-isolation-with-Calico-2.png) *Above: Recommended policy for the cartservice namespace* Each namespace is automatically discovered within your Kubernetes cluster and a `StagedNetworkPolicy` is generated by the engine. Staged policies are identical to Calico policies, except that they do not actively enforce the Allow or Deny rules. This gives you the ability to continue to audit the behavior of the policy for as long as you need to before actively enforcing it. Staged policies generate metrics and are included in flow logs in the exact same way as regular Calico policies. ### Namespace isolation policy tier After a recommended policy is in the “Ready” state, you are able to take one of two actions. The first is moving the policy to your Policy Board, where it is placed in its own tier called **namespace-isolation**. ![Policies Board showing a 'namespace-isolation' tier, illustrating how policies can be moved to their own tier after being in](https://www.tigera.io/app/uploads/2023/08/Automated-namespace-isolation-with-Calico-3.png) *Above: Recommended policies after being moved to the **namespace-isloation** tier* Quick Reminder: Policy tiers are unique to Calico and help enforce an order of precedence for policy evaluation which can be tied to Kubernetes RBAC, enabling different stakeholders and teams to manage the policies within a tier. This ensures that an application developer cannot define a policy in a lower tier that circumvents one defined by the security team in a higher tier. For Policy Recommendations, tiers also help us ensure the recommended policies will not conflict with other policies you may have already implemented. For example, if you’ve already used Calico policy to authorize egress access for certain namespaces to specific domains in the **platform** tier, the engine will automatically exclude those rules in recommended policies. Once a recommended policy has been moved to the Policy Board, you can work with it like any other Calico policy. You can continue to audit its behavior as a staged policy, edit and preview changes, or actively enforce it. Aside from moving a recommendation to the Policies Board, you also have the option to dismiss a policy recommendation for situations where you may not want to implement isolation for namespace. ## Conclusion Policy Recommendations is a powerful new tool for getting started with namespace isolation and improving the security posture of your cluster with Calico. In just a few clicks, you can go from a Kubernetes cluster with a “default allow” to one where each namespace has been automatically isolated and secured. Staged policies allow you to audit the behavior of these recommended policies for however long you need before actively enforcing them, and policy tiers ensure that recommended policies will not conflict with any others you may have implemented. If you are interested in learning more about automated namespace isolation to help improve the security posture of your cluster, signup at calicocloud.io for a [free trial](https://link.tigera.io/ueOp4). [Best Practices](https://www.tigera.io/tags/best-practices/)[Products](https://www.tigera.io/tags/products/) ## Related posts [![Gemini Never Left the Sandbox. The Sandbox Had a Door.](https://www.tigera.io/app/uploads/2026/10/gemini-featured.png)](https://www.tigera.io/blog/gemini-never-left-the-sandbox-the-sandbox-had-a-door/) #### [Gemini Never Left the Sandbox. The Sandbox Had a Door.](https://www.tigera.io/blog/gemini-never-left-the-sandbox-the-sandbox-had-a-door/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Oct 7, 2026 In short, in May 2026 a Gemini model under evaluation by the AI security firm Irregular reached the systems of three real companies, and the incident has been reported as a breakout. By Google’s own... [Read more](https://www.tigera.io/blog/gemini-never-left-the-sandbox-the-sandbox-had-a-door/) [![EU Cyber Resilience Act: Europe Just Put Your AI Agents on a 24-Hour Clock](https://www.tigera.io/app/uploads/2026/10/EU-Cyber-Resilience-Act-AI-Agents-featured.png)](https://www.tigera.io/blog/eu-cyber-resilience-act-europe-just-put-your-ai-agents-on-a-24-hour-clock/) #### [EU Cyber Resilience Act: Europe Just Put Your AI Agents on a 24-Hour Clock](https://www.tigera.io/blog/eu-cyber-resilience-act-europe-just-put-your-ai-agents-on-a-24-hour-clock/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Oct 5, 2026 In short, the EU Cyber Resilience Act (CRA) puts binding cybersecurity requirements on any software sold as a product in the EU, and it does not carve out AI agents. Since 11th September 2026, any... [Read more](https://www.tigera.io/blog/eu-cyber-resilience-act-europe-just-put-your-ai-agents-on-a-24-hour-clock/) [![The Clearinghouse For AI Agents Has A Blind Spot](https://www.tigera.io/app/uploads/2026/09/Lynx-Clearinghouse-Blog.png)](https://www.tigera.io/blog/clearinghouse/) #### [The Clearinghouse For AI Agents Has A Blind Spot](https://www.tigera.io/blog/clearinghouse/) By [Dillon Barry](https://www.tigera.io/blog/author/dillon-barry/) on Sep 23, 2026 Jamin Ball’s recent piece, “Systems of Record Won the SaaS Era — Clearinghouses Will Win the Agents Era,” is the cleanest articulation I’ve seen of where the durable moat goes next. His argument is simple... [Read more](https://www.tigera.io/blog/clearinghouse/)