Leveraging Calico policy recommender for Kubernetes clusters

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.

In this blog, we will discuss how to leverage the security policy recommender to rapidly create security policies to minimize the attack surface and improve the security posture.

Gathering application flow-data

Lets 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.

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 setup our Tiers and Policies as per Calico best practices.

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.

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.

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.

4. This staged policy is created initially in the default tier

5. But we can move this policy into our application tier (designated for coarse-grained, non-micro-segmented applications).

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.

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.

3. This creates a staged policy for this deployment based on the traffic flow from the last 15 minutes.

4. We repeat the steps for the rest of the deployments in the namespace.

5. And move these policies to the AppSec tier (designated for fine-grained, micro-segmented, policies).

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 to learn how to adopt a holistic approach to container and cloud-native application security and observability.