--- title: "Leveraging Calico policy recommender for Kubernetes clusters" source: "https://www.tigera.io/blog/leveraging-security-policy-recommender-to-tighten-your-clusters-security-posture/" --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # Leveraging Calico policy recommender for Kubernetes clusters By [Leon Barron](https://www.tigera.io/blog/author/leon-barron/) on Apr 20, 2023 • 5 min read In this blog post, we will discuss how to leverage Calico’s security policy recommender to rapidly create security policies to minimize the attack surface and improve the security posture. ## Background We’ve noticed that many of our customers are currently undergoing a significant transformation in their application architecture, transitioning from legacy vertical applications to distributed microservices running on Kubernetes. This shift brings along a range of benefits, such as improved scalability, resilience, and agility. However, it also creates a larger attack surface that needs to be managed effectively. To minimize the attack surface, it is crucial to have a clear understanding of how each microservice communicates microservices within, and outside, the cluster to implement robust network configuration and security policies. This can be challenging, especially when dealing with re-architected applications that can consist of hundreds of microservices. To make the life of the security and DevOps teams easier, there are a few things that can be done. Firstly, providing them with access to detailed information on how microservices communicate within and outside the cluster. Secondly, having automated policy recommendations to improve their configuration and security. Finally, providing visibility and audit reports to help identify vulnerabilities in the system and prevent potential breaches. ## Gathering application flow-data Let’s say a new application has been deployed into its own namespace in our Kubernetes cluster and we have not been given any information on what ports, protocols or endpoints this application communicates with. ![Kubernetes network map showing unknown app's external and internal dependencies](https://www.tigera.io/app/uploads/2023/04/image14.png) Here we can see a view of our application using Calico’s Dynamic Service and Threat Graph.  Without any additional configuration the Dynamic Service and Threat Graph instantly provides a clear flow-topology for each microservice. For example, in the image above, the dynamic service graph shows how the customer and summary services interact with other services.  - Customer -> Summary - Customer -> kube-system - Customer -> Public Internet - Summary -> kube-system - Summary -> Database In Kubernetes clusters, by default, without any policies in place, each microservice is allowed to communicate with each other, and with any external endpoints freely. These security gaps need to be plugged in an efficient way, and this is where Calico Policy Recommendation comes in. ## Securing the application by namespace isolation Before we jump into securing our new application, let us first look at how we set up our Tiers and Policies as per Calico best practices. ![Calico Policies Board showing tiers and policies for security, platform, application, appsec, and default. Illustrates the](https://www.tigera.io/app/uploads/2023/04/image2-1.png) **Security tier:** This tier contains a set of policies defined by the security teams to implement high-level security guardrails for the cluster. **Platform tier:** This tier contains a set of policies defined by the platform team to implement security controls for platform components such as kube-dns and ingress. **Application tier:** This tier contains a set of policies defined by the application team to implement coarse-grained security policies for namespaces. **AppSec tier:** This tier contains a set of policies defined by the application team to implement fine-grained, micro-segmented, security policies for namespaces. With a tiered architecture in place, and our flow reconnaissance from Dynamic Service and Threat graph, we are now able to tighten our security posture by only allowing necessary application flows and then locking everything else down. Looking at the application as a whole,  we want to discover what traffic is flowing into the namespace (ingress) and what traffic is flowing out of the namespace (egress), and then allow these ingress and egress flows with one namespaced Security Policy. 1. We first navigate to the Policy Board and click on the **Recommend a Policy.** ![Screenshot showing the "Recommend a Policy" button, highlighted in red](https://www.tigera.io/app/uploads/2023/04/image12.png) 2. We can then select the namespace from the drop-down menu, in our case this is the *yaobank* namespace, and click the **Recommend** button. **Note:** We can specify a Time-Range value in this wizard. In this example we are using a 15 minute window but, as a rule of thumb, the longer the better. ![Time Range set to 15 minutes ago, showing the "From" and "To" fields, and preset time ranges](https://www.tigera.io/app/uploads/2023/04/image8.png) 3. This will create a **staged policy** that will allow all incoming and outgoing flows seen in the last 15 minutes, to and from, the application namespace. ![The "yaobank-policy" is labeled "STAGED", indicating a staged policy for the "yaobank" namespace](https://www.tigera.io/app/uploads/2023/04/image11-1.png) 4. This staged policy is created initially in the default tier ![default" tier showing a "staged" yaobank-policy with 4 endpoints, illustrating initial policy creation](https://www.tigera.io/app/uploads/2023/04/image13.png) 5. But we can move this policy into our application tier (designated for coarse-grained, non-micro-segmented applications). ![A confirmation dialog asking to move the "yaobank-policy", implying a shift to a different application tier](https://www.tigera.io/app/uploads/2023/04/image3-2.png) Since the policy recommender tool creates**staged policies**, we are able to monitor for any unexpected drop actions that this policy would make without any impact to the application. Once we are happy with the results we can **enforce** the Security Policy. ![Screenshot of the "Enforce" button, highlighted in red, after "Stage" and "Preview" buttons](https://www.tigera.io/app/uploads/2023/04/image15.png) ![Application policy details showing allowed and denied traffic for different tenants](https://www.tigera.io/app/uploads/2023/04/image4-2.png) ## Advanced security enforcement We can now breathe a sigh of relief that we have a coarse-grained Security Policy that will secure traffic coming into and out of the application namespace. But we still have a blind-spot; traffic flowing from within the application namespace. This is where zero-trust and micro-segmentation can really become tricky and, depending on the size of the application, time-consuming. With the Calico Policy Recommender however, we just need to specify the deployments we wish to secure and the rest is automated. 1. Again we navigate to the Policy Board and click on the **Recommend a Policy** link. 2. And again we select the Namespace we are interested in but, this time, we also select the advanced options which will allow us to specify **deployments** within the namespace. ![Screenshot of advanced options, showing a deployment name field within the selected namespace](https://www.tigera.io/app/uploads/2023/04/image6.png) 3. This creates a staged policy for this deployment based on the traffic flow from the last 15 minutes. ![A staged policy deployment with scope set to "yaobank" namespace, applying to "customer" app, version "v1](https://www.tigera.io/app/uploads/2023/04/image5-2.png) 4. We repeat the steps for the rest of the deployments in the namespace. ![The image shows a UI to filter deployments. "Name" field shows "summary-748b977d44-", to be repeated for other deployments](https://www.tigera.io/app/uploads/2023/04/image10.png) ![Configuration options: time range, namespace "yaobank," and name "database-899b4f58f](https://www.tigera.io/app/uploads/2023/04/image9.png) 5. And move these policies to the AppSec tier (designated for fine-grained, micro-segmented, policies). ![AppSec tier (left) next to 'default' tier (right) showing policies moved to AppSec](https://www.tigera.io/app/uploads/2023/04/image7.png) ![Network policy traffic comparison: "appsec" vs. "default" policies](https://www.tigera.io/app/uploads/2023/04/image1-2.png) ## Conclusion Leveraging an automated security policy creation tool that is aware of ingress and egress traffic, at both a namespace and deployment level, is vital to realize a true Zero-Trust security stance for our Kubernetes applications. [Read our book](https://link.tigera.io/udWxu) to learn how to adopt a holistic approach to container and cloud-native application security and observability.   [Best Practices](https://www.tigera.io/tags/best-practices/)[How-To](https://www.tigera.io/tags/how-to/) ## Related posts [![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/) [![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/)