Security for Docker 1.12 became generally available for production environments at the end of July. There are some exciting enhancements in this release, and we at Twistlock are updating our own product to keep pace with Docker’s new capabilities.
The main aspects of Docker 1.12 that we think will be of high interest to enterprise users are orchestration and clustering, also known as swarm mode, and new networking capabilities. Implementing these functions has been greatly simplified now that they are a native part of the Docker engine.
Prior to Docker 1.12, if you wanted to build a multi-node, highly available cluster of hosts that could run containers, doing so typically required a relatively high level of skill as well as some sort of third-party cluster management solution. Twistlock supports Kubernetes and Mesos in addition to the now legacy Docker Swarm project that Docker had before the 1.12 release. Twistlock will continue to support all of those, but in release 1.12 Docker really simplified the process of clustering from what it was before.
Even transitioning from a custom-developed clustering solution to a new Docker Swarm is fairly easy. Let’s say today you are running your own environment, perhaps with your own cluster management solution or a third party one, and you want to migrate to using Docker’s swarm mode instead. You can use the exact same images that you already have for an application. You simply run those images on your Docker Swarm and give it the docker swarm init command to get it started. The good thing is that you never have to make any changes to the application itself. This clearly shows one of the advantages of containers, which is the portability and flexibility that they provide for applications.
How does this impact Docker users? Simply said, the value of security for Docker 1.12 is that you can go from a complex, high availability solution that may involve different third-party components to one that is using all in-box components , easily and quickly, just by upgrading to Docker 1.12 and running a few commands to set up your cluster.
Sophisticated Networking & Cluster Management
Another major feature that Docker 1.12 introduces is more sophisticated networking. In the past, Docker networking was fairly basic and didn’t offer much functionality, particularly in multi-host networking and multi-container cluster management. Docker 1.12 makes the networking model much closer to a software-defined network by allowing user-defined overlay networks. These networks can span across multiple hosts, which gives greater configuration control of what is connected to those networks. If you are experienced with VMware NSX, for example, you will see some feature parity and similarities with at least some of the conceptual capabilities that NSX provides.
Let me describe it in another way. Prior to release 1.12, Docker had a model in which networking was scoped to the individual host, meaning you could basically say that a given container was connected either to a host-only network or bridged across that host onto whatever network the host itself was connected to. If you had a physical server it would literally be bridged onto that physical network, or if you had a VM it would be bridged onto whatever VM that network was connected to. You didn’t have the ability to say, for example, I have five hosts that are clustered and I want to have one big shared virtual network that’s going to run my databases and another shared virtual network that is going to run my frontend servers and so forth. There was no way to do that natively with Docker until now. With security for Docker 1.12 that capability is not only available but it is pretty well integrated in the swarm networking features discussed above.
For our part, Twistlock is adding more advanced networking security features in our next release that really align well with protecting these more scalable deployments of containers. We already have machine-learning capabilities in our product to build behavior models for containers. Our next release will take into account the virtual networking behavior of the containers if they are connected to one of these new Docker networks.
More specifically, our modeling and learning capabilities now exist on three different levels:
- Static image analysis. This capability allows us to gather some core behavior characteristics about the containers, such as what ports would be exposed and what network the container is connected to.
- Automatic learning. In Twistlock’s advanced runtime feature, we automatically observe the behavior of a container after it has been deployed and build a behavioral model dynamically which governs what that container should be doing throughout its lifecycle.
- Advanced networking learning: With the new Docker networking features, our learning capabilities now take into account the overlay network that a container may be connected to, beyond the basic networking
For example, say you have a container that is going to run a Web server and talk to a particular backend database. When you deploy that application, we know that the Web server should listen on port 80 and the database should listen on port 3306. But with Twistlock 1.5 (our next release), we would also monitor what those containers do both with respect to system behaviors, but also with respect to these new virtual networks. We will be able to understand which other containers it connects to via the virtual network, how often they typically communicate, and in what fashion, etc. If we see lateral traffic to another container that outside the normal behavior pattern, we will flag it as an anomalous activity.
We have many other exciting features in Twistlock 1.5, such as app specific network modeling, which I will detail in a future blog post. For now, be rest assured that the Twistlock team is keeping on top of all the Docker innovations and new capabilities coming to the market. As Docker continues to do cool and exciting things around increasing networking and native clustering capabilities, Twistlock will continue to evolve our product so that our customers can take advantage of all of those great capabilities without sacrificing security.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Cloud Platform Discovery: Identifying All Your Cloud Native ServicesRead the Blog
Using Twistlock to Secure Workloads on Pivotal Cloud FoundryRead the Blog
Twistlock, Azure Container Instances, and AKS virtual nodesRead the Blog
Twistlock 18.11 Release NotesRead the Blog
5 Questions to Ask When Choosing a Cloud Native Security Platform for DevOpsRead the Blog