June 24, 2015
The recently published Docker Security Best Practices report has given the technology industry a new foothold for discussing container security. With recent breaches, security is top of mind for IT professionals, who move quickly to protect themselves and clients from attack. The fact is that securing infrastructure will always be a challenge, but when examining the issue it is essential to think about containers in a broader sense, instead of narrowing down to Docker.
1. Different Container Implementations
Containers have been part of open source Linux code for decades now. The reason they have gained popularity recently is largely due to the improvements in the Linux Kernel namespaces and control groups capabilities, which allow the isolation of specific processes, which can be wrapped up in a container so that they are portable and easier to manage. By putting the emphasis on the packaging and orchestration capabilities of containers, Docker brought container technology to a much broader audience and deservedly captured the attention of developers and media.
However, there are a lot of benefits to containers that are not currently being discussed. Namely scalability, elasticity, and operational efficiency, all of which vary depending on the way an organization runs containers. This also affects security, so putting all containers under the same denominator is not the right way to go about it.
2. The Difference between second-layer and bare-metal containers
The most common use of Docker by cloud hosting providers is as a second container layer to the server stack on top of your infrastructure. This means adding one more layer of complexity to your server stack. One alternative to this is bare-metal containers, which run directly on top of your host server hardware. So, technically, bare-metal containers are one layer underneath Docker containers – just like VMs, only much more lightweight. Running a container-based infrastructure does not necessary make your stack more or less secure by itself, but having one less layer in your server stack does make your infrastructure less complex.
If you are running containers on bare metal, you are removing an entire layer of your stack – the Hypervisor layer – which acts as a container host and adds security concerns and complexity that you should otherwise monitor. Removing the virtual machine layer creates a smaller surface area of risk for breaches.
To back that up we look at the CVE (Common Vulnerabilities and Exposures), a collective of publicly known information security standards and as of today, the number of CVEs for Docker is six, while there’s only one CVE listed for LXC. Of course this may be due to the wider adoption of Docker than LXC, but then again, the latter has been around much longer than the former, which has been actively in use only for the last year and a half.
3. Container Management
If you want to use containers nowadays, be it Docker or LXC ones, you also need to think about management.
Docker handles management on its own and provides developers with a broad range of features. These, however, might contain hidden vulnerability holes waiting to be discovered.
LXC does not have such a wide set of management capabilities built in – management is your own responsibility and you need to ensure that you are doing it in a secure manner. The better you build and maintain your stack, audit it and keep it up to date, the more secure it is.
Security has no simple answer; it is a process. The question is which container technology works best for the business or developer in question and if they can make the environment secure. Different stacks and companies need different layers and levels of security. It is all about risk management and tradeoffs between security and functionality. It is a well-known fact that the more secure a system is, the harder your day-to-day work gets. Regardless of which software you are going to use, the challenge will always be making your infrastructure secure enough to react adequately to today’s threats and answer rapidly to the threat models of tomorrow. Being able to understand the pros and cons of each container implementation is just the first step of the process.
Did you like this article?
Get more delivered to your inbox just like it!