Information Security

Defending the digital infrastructure

carloscastilla - Fotolia

Get started Bring yourself up to speed with our introductory content.

What are cloud containers and how do they work?

Containers in cloud computing have evolved from a security buzzword. Deployment of the technology is an essential element of IT infrastructure protection.

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. Containers have seen increased 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.

How do cloud containers work?

Container technology has roots in partitioning and chroot process isolation developed as part of Linux. The modern forms of containers are expressed in application containerization such as Docker, and in system containerization, such as Linux Containers. Both enable an IT team to abstract application code from the underlying infrastructure to simplify version management and enable portability across various deployment environments.

Containers rely on virtual isolation to deploy and run applications that access a shared operating system kernel without the need for virtual machines. Containers hold components such as files, libraries and environment variables necessary to run desired software. The host OS constrains the container's access to physical resources so a single container cannot consume all of a host's physical resources.

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 containerized applications that reside on the same operating system.

Major cloud vendors have offered containers as a service products, including Amazon Elastic Container Service, AWS Fargate, Google Kubernetes Engine, Microsoft Azure Container Instances (ACI), Azure Kubernetes Service and IBM Cloud Kubernetes Service. Containers can also be deployed on public or private cloud infrastructure without the use of dedicated products from a cloud vendor.

There are still key questions that need answers, such as how exactly do containers differ from traditional hypervisor-based virtual machines. And just because they're so popular does it really mean they are better?

Cloud containers vs. VMs

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 being able to deploy two to three times as many containers on a server than virtual machines.

Cloud containers are also very portable -- once the container has been created, it can easily be deployed to different servers. From a software lifecycle perspective this is great, as containers can quickly be copied to create environments for development, testing, integration and production. 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 they become difficult to manage. Can you 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.

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. However, 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 enable most standard requirements to be met with minimal effort.

virtual machines vs. containers

Cloud container security

Once cloud containers became popular, one of the biggest concerns was how to keep them secure. Docker containers used to have 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 addressed this with a feature called Docker Content Trust ( 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 its website for securing containers; the important thing to remember is that just because containers are a newer type of technology, it doesn't mean that traditional security policies and procedures shouldn't be applied to them.

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.

Article 1 of 3

Next Steps

Learn more about Docker containers

Why experts say cloud containers are more than just a fad

Dive deeper into cloud containerization strategies

Get to know key terms for cloud containers

Dig Deeper on Cloud Network Security Trends and Tactics

Get More Information Security

Access to all of our back issues View All