Calico Network Policy Comes to Kubernetes

Calico Network Policy on Kubernetes

As you may know, Calico was designed from the ground up to support rich, flexible, and secure network policy. We’ve been working to bring that policy to Kubernetes deployments, and the latest Calico Kubernetes plugin does just that, allowing namespace isolation at the network layer, and fine-grained security between your Kubernetes pods.

In tandem with this, we’d like to announce that Calico now supports acting in “policy-only” mode. This means you don’t need to use Calico networking to take advantage of Calico’s rich security policy enforcement.

Take a look at the demonstration video below to see Calico network policy in Kubernetes in action. The demo uses Calico’s policy-only mode to enforce network policy on a Kubernetes cluster running on the standard GCE cloud provider. Networking is still performed using GCE’s native routing, while Calico is simply enforcing security policy.

How Does it Work?

Declaring Policy

We make use of the annotation field on the v1.podTemplate API object to declare network policy. This allows us to declare policy in a concise, easily readable format, matching on arbitrary labels. For example, securing traffic to your backend pods is as easy as adding the following two lines to your backend pod manifest and adding the label “access=backend” to each pod that should be allowed access:

annotations:
  policy: "allow tcp from label access=backend to port 4001"

Remember you can use arbitrary labels in Calico policy – “access” is just what we chose for this example. Take a look at our GitHub page on declaring Kubernetes policy for a full set of supported policy statements.

Behind the Scenes

The Calico plugin reads the declared policy combined with the pod’s namespace and converts it to Calico policy primitives – profiles, tags, and rules. The policy is realized as iptables rules in the kernel of the Kubernetes node which hosts your pods. Programming ACLs to the kernel means we can take advantage of Linux’s battle-hardened iptables kernel support and eliminate the need for a user-space datapath, improving the security and performance of our network policy.

Note the use of namespace in the policy mapping. By including the Kubernetes namespace, Calico can enforce Kubernetes namespace isolation. This means pods in your development namespace won’t accidentally interfere with your production pods. Pretty cool!

What’s Next?

This is just the first step – we have a lot of exciting work ahead of us continuing to develop network policy in Kubernetes and ensuring that Calico’s policy implementation can easily be combined with any Kubernetes networking plug-in / cloud provider. We plan on adding richer tag semantics to Calico policy to better support label-selectors, augmenting the Kubernetes API for better policy declaration, and improving policy performance in high-scale Kubernetes clusters.