Package Delivery

BIRD and Iptables

Felix handles several jobs on the target systems. Of course, for real routing on the host, you need a BGP daemon. The developers chose BIRD, which is a tad more modern than Quagga and implements the BGP standard along with some extensions. Additionally, Felix configures the iptables packet filter with its built-in policy engine.

The Calico website explicitly advertises that Calico works with a variety of fleet virtualizers. Like almost everywhere in the hip IT world, the primary focus of the Calico project lately has been on Kubernetes. Kubernetes is given much more space in the Calico documentation than for deployment on other platforms, and the components in Calico speak a clear language that explicitly targets its use with Kubernetes.

Accordingly, Calico performs well in the Kubernetes context. In particular, it implements a Container Networking Interface (CNI) that allows containers to use network interfaces according to defined criteria.

Calico as a Profiler

A core aspect of Calico is establishing a connection between several communication partners. A second, very important complementary topic is security. Because Calico has no separation into overlay and underlay, even the basic encapsulation techniques for separating traffic of different origins are missing.

Everything takes the same paths over the same network interfaces. To secure the connection, the on-board toolset available in Linux must be used accordingly. Here, the developers have come up with something clever: Calico uses profiles (i.e., previously created standard configurations for certain security settings) that are deployed as needed according to circumstances (Figure 3).

Figure 3: Calico implements its security guidelines in profiles and cooperates directly with solutions like Kubernetes.

A simple example might be a Calico profile for a web server running in a container. Ports like 80 and 443 would be allowed, but no other ports would be open. The approach also reveals its full potential when Calico adheres to the security requirements of the orchestrator with which it works. For example, Kubernetes can automatically tell Calico what type of container is being deployed, and Calico then automatically selects the appropriate profile from this information.

Automatic Encryption

In the security context, Calico also offers a particularly interesting feature that is only available as a Technology Preview and has not yet been released by the developers for production: automatic transport encryption.

The Calico developers are very critical of those who do not use SSL within their setups and simply assume that their network is secure and protected against intruders – with good reason: It is becoming increasingly common for attackers to infiltrate networks and sniff traffic without notice for months; therefore, Calico has declared war on the concept of the local network as a secure domain.

The idea is, if IP and BGP can be used to control the path that packets take between hosts anyway, transport encryption can also be integrated transparently into this process. This practice reminds me of solutions like Istio, which implements similar features in the cloud for their containers. But in Calico's case, the function also extends to the physical Layer 3.

In such situations, you would no longer have to make sure your services can handle SSL and would still have continuous transport encryption on the network. Although still a dream of the future, sooner or later Calico will make the feature available in the production version.