This checklist will help you prevent certain deploy-errors or even outages in the future when working with Docker or Dockerfiles. To help you get started, we have also included a template.
Starting FROM the top
The benefit of Docker is that images can be built on top of each other, expanding the functionality of the container.
Your first line usually states `FROM <IMAGE NAME>` , where `<IMAGE NAME>` is an image name as found in a Docker repository.
It is crucial to either add a tag (i.e. `FROM <IMAGE NAME>:<TAG>`), or a digest there (i.e. `FROM <IMAGE NAME>@<DIGEST>`). Otherwise, the default `latest` tag is being applied, and certain breaking changes may make it into your current Dockerfile. It is to be noted that the digest method is far more specific on the image to be used than the mere tag (which may be updated).
If you download it, you need to verify the signature
In some cases, data and even executables are downloaded in a Dockerfile via either wget or curl. The risk in this approach is that your external resource may change, or get compromised. This is why you should keep a local signature file of the file you aimed to download (small in size), and verify that the file(s) you downloaded match the given signature. This ensures stability in future builds.
If the files are signed by the third party, you can use `gpg –verify` to verify the integrity. If the author does not have a signed package, at least keep a hash you expect and compare it against the file you just downloaded.
“Keep the image small” strategies
While you may be choosing your Linux distribution based on your desktop Linux experience (e.g. Ubuntu or Fedora), it is advisable to use a smaller base-image. Here are some of the smallest images out there:
All the other images are at least 10x the size.
Package manager cleanups
For non-trivial containers, you are not getting around running something like
`apt update && apt install <SOME LIBRARY>`.
This will create a cache and a list of resources which unnecessarily reside on your system, and use up space.
For the apt package manager, the files in the folder `/var/lib/apt/lists` can be removed at the end.
Do multistage builds
One of the uses for Docker images is to build a software project in a reproducible environment. The requirements to build are likely much larger than the requirements to execute. Hence, use multi-stage builds to ensure that the final image does not have any extra packages which are not needed.
This also fits in the category of “keeping the images small”, but it also has implications beyond. Remember that every additional package on your system is one more potential security risk.
Setting a non-root user as default user when running the image
By default, the root user is executing all commands (including the CMD directive) in a Docker container. For installing packages, setting the user to root inside the Dockerfile may make sense, but by the end, the USER directive should switch to a different user on the system.
This should also be done, even if the parent image is already setting this user to a non-root user. By explicitly always having a USER directive at the end of your Dockerfile, you remove the reliance on upstream settings to ensure that this security critical setting is set.
Have a HEALTHCHECK directive
Understanding what it means for your application to run and be in a “healthy” state ensures that errors are caught early. We recommend using the HEALTHCHECK directive of Dockerfiles to assist your monitoring system in assessing the overall health of your microservice-driven application. The only thing to keep in mind is to keep those checks computationally cheap, as they are regularly executed.
Mount /var/log as a volume
The general spot on a Linux based system where logs are being stored is /var/log. These logs should be captured by your monitoring and analysis systems, as they capture important information which can help with security analysis.
Scan existing Dockerfiles and configurations
Already created a Dockerfile and are not sure if it has been configured correctly? Check out and use our open source CLI tool:
Final Template suggestion
Feel free to use this template when you create your Docker files.
Visit CoGuard's blog for more great articles: https://www.coguard.io/blog
Email us anytime: firstname.lastname@example.org