How to make a Docker container as secure as possible?
- How can image hardening help with security?
- What is image hardening?
- How would you harden your image?
- How do you securely pass secrets to your container?
- What are the conventional ways of passing secrets to your container?
- Can you safely pass secrets to your container by using build arguments?
- Strategy: Library
- Method: Literature study
To understand what the hardening of a Docker image is, we first should address what exactly Docker images and containers are and what it means to harden something.
Going by a quick and simple explanation a Docker image is more or less an instruction manual, telling your system how to create your Docker container. To get an image you can either get an image and use it as is (from docker hub) or make your own, by basing it of of another so called "base image". After you got your image you can create a Docker container that can run your application inside of it. By doing this you always have a production ready version of your application that is also easy to deploy and distribute.1
Then what does hardening something mean? Hardening (in computing) usually refers to the process of making a system more secure by reducing vulnerabilities, depending on how many functions the system serves. The more functions a system has the more vulnerabilities one may come across. So to mitigate vulnerabilities you want to remove as much unnecessary software or so called security risks to mitigate vulnerabilities. This also includes things like: changing default passwords, getting rid of unnecessary logins, and disabling or removing unnecessary services.2
Now then how would you harden your images? I have compiled a list of the most commonly talked about ways to better secure your Docker images in the following paragraphs.
Minimal base image
Starting of with using minimal base images. Most people starting of with Docker will use something like node as their quick and easy way to make sure all the right packages can be installed that their applications can be build for production and run with npm. This however ends up exposing your application to a load of vulnerabilities and you can compare it to using a full blown operating system. By doing this you end up adding unnecessary security risks from the start. By using a minimal base image that can only do the bare minimum to get your application up and running will minimize the attack surface for attackers. To give an example of a commonly used minimal base image that also has many variants and flavors of what you need are Alpine images. Those images are a super light weight flavor of Linux and are a great starting point. However if you really want the best of the best you can use images that don't even have a shell and can only execute things like binary files. When getting into this territory you still need to build your image and you don't want to add unnecessary packages to build your application. This is when you get into Multi-stage builds which is the next topic.
Multi-stage builds
Multi stage builds essentially exist out of a build stage which first uses an image that has the necessary tools and libraries to run the needed commands. Then after your build stage is done you pull another image this time much smaller that only can start your application containing only the necessary build files from the previous image. This is the optimal way of minimizing your (final) Docker image. This not only makes