Background

For those of you not acquainted with the latest trends in computer development, a docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application. This means a Docker contains code, runtime, system tools, system libraries, and settings.

In fact, a docker is a self-contained image that is easy to distribute. It’s also easy to move from development to test and to production. The movement process was key to the successful adoption of docker containers among developers.

With dockers, distributing applications is very easy and everyone can create and publish their own containers. There is even an official marketplace for docker containers (https://hub.docker.com/), which is managed by the open source community. Indeed, there are a vast number of official and unofficial ready for use docker containers, even for commonplace applications like databases and web servers.

Docker Security

A lot of security concerns have been raised about containers. Many of the security concerns are valid, but many misunderstandings occur because many people confuse containers and virtualization, thinking that they’re the same thing. However, virtualization involves the capability of segregating memory and CPU, whereas a docker shares the same resources.

Last month a security researcher found a way to “escape” the jail that docker creates and replace arbitrary programs in the host system. A malicious program or docker image can exploit a bug in the docker runtime (runC) to gain root privileges on the host running the container. This then allows ill-intentioned players unlimited access to the server as well as any other containers on that server.

The risks are quite clear.

What can I do? Be Very Careful.

Developers and Operations have to select docker images with extreme care. The way to exploit the aforementioned bug is through malicious and hidden programs that -before launching the real program- execute the exploitation sequence and inject an evil binary.

Most of the time images are built in-house for custom-made applications, but sometimes 3rd party images are uses for common tasks such as databases, caching (ex: Redis) and front-end (ex: haproxy). DevOps should avoid images from unknown/untrusted sources.

If you can, create your own images, even for common applications, starting from well-known and trusted sources, such as the operating system itself or from the application vendor.

At present, I am helping many of my customers to introduce secure building pipelines to their architecture. By embracing DevSecOps, and thus driving development and automation in a different way, you can improve the overall security of in-house applications. At the same time, you can ensure the code provided by suppliers is up to scratch. In this way, the use of dockers can indirectly help maintain code quality.

Use dockers by all means, but implement them carefully to avoid potential security pitfalls resulting from poor coding practice.

If you require specialist advice on building secure pipelines or security with docker, get in touch with me.