Project Calico, Flannel Join Forces for Policy-secured Networking
Traditional approaches to network management and security are ill-suited for the fluid nature of container and microservices-based architectures. Containers appear, disappear and are moved around to different compute nodes far too frequently to be assigned static IP addresses, much less be protected by firewalls and IP tables at the network’s perimeter.
With this in mind, two open source projects, CoreOS’ Flannel virtual networking technology, and the Project Calico, another network overlay technology with strong security controls, have joined forces to offer a single package, called Canal, that will offer policy-based secure networking for the container and microservices era.
“IP addresses are not special snowflakes”– Andrew Randall, Tigera.
A new San Francisco-based company has been formed, Tigera, that will manage both projects. Tigera is a spin-off of network solutions provider Metaswitch, and many of the San Francisco Metaswitch engineers who worked on Calico have moved over to Tigera. CoreOS is donating the Flannel codebase to Tigera.
Andrew Randall will serve as CEO of the new company, which has gotten an initial round of investment from New Enterprise Associates.
Both Flannel and Calico offer virtual networking, in that they can both create virtual IP-based networks, establishing an IP-based fabric for a set of virtual servers or containers to communicate with one another.
Virtual networking is catnip for users of cloud computing and cloud orchestration tools such as Kubernetes, in that the customer may only get a single IP address from a provider, and must build an entire system of microservices behind it. Virtual networking can also offer more flexibility as virtual IP addresses can be assigned and reassigned quickly, with a fabric controller keeping track of which node has which IP address at the moment.
In addition to virtual networking, Calico also offers policy-base security management for virtual networks. Using a set of labels, developers can define which services should be talking to other services. The controller will then enforce these policies for all the packets rolling across its network.
“Each microservice is sufficiently simple that developers can define, very easily, at a high level, what they expect that microservice to be talking with, and with what port,” explained Alex Pollitt, Project Calico evangelist, in a breakout session at the CoreOS Fest, taking place in Berlin this week.
The advantage of this approach, when combined with a virtual network, is that the fabric controller “can take high-level intent straight from the developer and render it directly into the network fabric automatically, and dynamically keep it updated in real-time so that the only packets that flow in a network are exactly the packets that the developer expects to flow.”
Security for #container/#microservices must be defined by "developer intent," not firewalls @lxpollitt #CoreOSFest pic.twitter.com/0sivdv8Ihn
— The New Stack (@thenewstack) May 10, 2016
This would help security insofar that it reduces the attack surface to the barest minimum needed to run the services.
There are many advantages of combining the two Flannel and Calico, Pollitt explained. Most importantly, the combined codebase provides a one-stop shop for an organization looking to jump into containers and/or microservices, as the two projects will be tightly integrated. Both rely on the etcd key-value store to hold operational data.
And those organizations using either Flannel or Calico will now get a larger set of capabilities as the two technologies are fused. Tigera will maintain both Calico and Flannel as separate projects, but will offer easy upgrade paths to moving Canal, Pollitt said.
Further boosting the potential power of Canal will be a close integration with the Kubernetes container orchestration engine. The next version of Kubernetes, version 1.3 due in June, will feature a beta of a network policy API. With a Canal CNI (container network interface) plug-in for Kuberentes in place, a developer can annotate the communications policies of each container using labels, which Kubernetes, when deploying the pod of containers, can enforce, no matter what network, or networks, they run on.
The current CoreOS distribution of Kubernetes includes an implementation of Canal that can be run on a single machine, through Vagrant, or on Amazon Web Services.
TNS research analyst Lawrence Hecht contributed to this report.
