Containers in Cloud Computing

At the moment, cloud containers are a hot topic in the IT world in general, and security in particular. The world's top technology companies, including Microsoft, Google and Facebook, all use them. Although it's still early days, containers are seeing increasing use in production environments. Containers promise a streamlined, easy-to-deploy and secure method of implementing specific infrastructure requirements, and they also offer an alternative to virtual machines.

The key thing to recognize with cloud containers is that they are designed to virtualize a single application -- e.g., you have a MySQL container and that's all it does, provide a virtual instance of that application. Containers create an isolation boundary at the application level rather than at the server level. This isolation means that if anything goes wrong in that single container (e.g., excessive consumption of resources by a process) it only affects that individual container and not the whole VM or whole server. It also stops compatibility problems between applications that reside on the same operating system (OS). So far, cloud containers have predominantly been the domain of Linux-based servers, but Microsoft Windows Server 2016 will introduce Windows Server containers and Hyper-V containers (and, of course, integrate them into Microsoft Azure). But still there are key questions that need answers, such as how exactly are containers different to traditional hypervisor-based virtual machines. And just because they're so popular does it really mean they are better?

The key differentiator with containers is the minimalist nature of their deployment. Unlike virtual machines, they don't need a full OS to be installed within the container, and they don't need a virtual copy of the host server's hardware. Containers are able to operate with the minimum amount of resources to perform the task they were designed for; this can mean just a few pieces of software, libraries and the basics of an OS. This results in two or three times as many containers being able to be deployed on a server than virtual machines.
Cloud containers are also very portable -- once the container has been created, it can be deployed to different servers very easily. From a software lifecycle perspective this is great, as containers can be copied to create development, test, integration and live environments very quickly, and do not require the usual configuration. From a software- and security-testing perspective this has a large advantage, because it ensures that the underlying OS is not causing a difference in the test results.
One downside of containers is the problem of splitting your virtualization into lots of smaller chunks. When there are just a few containers involved, it's an advantage because you know exactly what configuration you're deploying and where. However, if you fully invest in containers it's quite possible to soon have so many containers that it becomes difficult to manage. Do you have the ability to deploy patches to hundreds of different containers? If a specific library needs updating inside a container because of a security concern, do you have an easy way to do this? Problems of container management are a common complaint, even with container management systems such as Docker. Virtual machines are generally considered easy to manage, primarily because there are significantly fewer VMs compared to containers.
Containers are deployed in one of two ways: either by creating an image to run in a container or by downloading a pre-created image, such as from Docker Hub. Although Docker is by far the largest and most popular container platform, with plenty of large companies using its solution, there are alternatives, such as LXD and Rocket (and the upcoming Microsoft products mentioned earlier). However, at this time, Docker has become synonymous with containerization. Originally built on a technology called LXC, Docker has become the predominant force in the world of containers. The library of pre-created images in Docker Hub is large, and should allow most standard requirements to be met with minimal effort.

Advantages of containerization

Containerization gained prominence with the open source Docker, which developed a method to give containers better portability -- allowing them to be moved among any system that shares the host OS type without requiring code changes. With Docker containers, there are no guest OS environment variables or library dependencies to manage.
Proponents of containerization point to gains in efficiency for memory, CPU and storage as key benefits of this approach, compared with traditional virtualization. Because containers do not have the overhead required by VMs -- separate OS instances -- it is possible to support many more containers on the same infrastructure. As such, containerization improves performance because there is just one OS taking care of hardware calls.

A major factor in the interest in containers is they can be created much faster than hypervisor-based instances. This makes for a much more agile environment and facilitates new approaches, such as microservices and continuous integration and delivery.

Disadvantages of containerization

A potential drawback of containerization is lack of isolation from the host OS. Because containers share a host OS, security threats have easier access to the entire system when compared with hypervisor-based virtualization. One approach to addressing this security concern has been to create containers from within an OS running on a VM. This approach ensures if a security breach occurs at the container level, the attacker can only gain access to that VM's OS, not other VMs or the physical host.
Another minor disadvantage of containerization is each container must use the same OS as the base OS, whereas hypervisor instances can each run unique OSes. For example, a container created on a Linux-based host could not run an instance of the Windows Server operating system or applications designed to run on Windows Server.

Cloud container security

Once cloud containers became popular, one of the biggest concerns was how to keep them secure. Until quite recently, Docker containers had to run as a privileged user on the underlying OS, which meant that if key parts of the container were compromised, root or administrator access could potentially be obtained on the underlying OS, or vice versa. Docker now supports what is called user namespaces, allowing containers to be run as specific users. There is of course the issue of security of images downloaded from Docker Hub; by downloading an image (which other users have created), the security of the container could not necessarily be guaranteed. Docker has addressed this with a feature called Docker Content Trust (introduced in version 1.8), which verifies the publisher of the image. The images can also be scanned for vulnerabilities. This goes some way toward providing assurance, but their verification processes may not be thorough enough if you are using containers for particularly sensitive applications. In this case, it would be sensible to create the image yourself to ensure your security policies have been enforced.

Containers for sensitive production applications should be treated in the same way as any other deployment when it comes to security. Inside the container is software that may have vulnerabilities; although this might not grant access to the underlying OS of the server, there still may be issues such as denial of service that could disable a MySQL container and therefore knock a website offline. It's also important not to forget the security of the server hosting the containers. Docker itself has some great advice on their website for securing containers; the important thing to remember is just that containers are a newer type of technology, it doesn't mean that traditional security policies and procedures shouldn't be applied to them.

Conclusion

There aren't many organizations that won't benefit from introducing cloud containers to their infrastructure. Their portability, both internally and in the cloud, coupled with their low cost, makes them a great alternative to full-blown virtual machines. However, it will be the case that in most companies there is a case for both containers and virtual machines. Both have their strong points and their weaknesses, and can complement each other rather than compete.