Automated namespace isolation with Calico

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:

1. 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.
2. 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.
3. 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.

1. One is the “noisy neighbor” problem 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.
2. 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

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.

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.

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.