Security Inside Docker Containers

image for article

In this article we’re going to talk about security inside Docker containers. Here at Konstankino LLC we heavily utilize Docker and would like to shed some light on security and explain why it is especially important when it comes to containers as microservices.

Assuming you have a well-defined functionality that you would like to abstract and encapsulate inside your container, it is relatively easy to do. Choose a base Operating System that your container will inherit from, install dependencies, package your files and now you have new shiny container that you can deploy and use. That is not necessarily the case if we start thinking about security.

Since containers reuse and share a lot of functionality in your host OS and multiple containers can be deployed on a single host machine, it is very important to put proper proactive security measures and make sure your containers expose only what they need to expose and your container’s files are hardened.

When we say files, we mean not only the files of your application, that you may have as part of your container, we also mean files that are still used by docker process to properly run and serve your service - thin layer between your host and your application. Those are system files that form a container itself. For instance, your container still has files /etc/passwd and /etc/group and probably uses some additional configuration files, such as nginx.conf for example. Those files (as well as some directories) must be hardened and proper permissions must be set. Should you think some specific file should never change inside your container - please make it immutable.

Next, think about ports that your container exposes. This heavily relies on where and how you want to deploy your containers, and some cloud provides already have this as an explicit step in the container deployment process. But you always should think about ports that your service/container exposes and make sure it does not violate organization policies. For instance, if someone tells me I need to SSH into the production container - I think something is really broken. You should avoid doing that.

Now, it’s time to talk about OS utilities that you probably should remove from all your production containers. Those are any compilers that you may think about or any binaries that were installed by default as part of the underlying layers of your container. For example, do you really need gcc compiler once you built all the dependencies? Once you have ImageMagick binary compiled and installed in your container, do you really need all the developer dependencies for it or for any other dependency? Do you really need git binary? Or a better one, do you really need sudo or su inside your container?

With this one line command you can find all binaries that have setuserid or setgroupid bit.

$ find / \( -perm -02000 -o -perm -04000 \) -ls

All the setXid (or setuserid, setgroupid) binaries, are very dangerous and if your container has them installed - it is a good time to consider removing them.

Once you have removed all the files and binaries that you don’t need - you have dramatically improved your general container security and decreased a surface of attack should anyone get inside your container and try to mess with your data.

Hardening Docker containers sometimes can be not a simple task since it requires knowing what your service suppose to do and what dependencies it has.

Hopefully this article gives you some ideas so that you know what you should think about before you deploy your Docker containers for production use.

If you need more assistance, we are ready to help you with your project.