Do you want to use Docker securely?
Here is your checklist.
Let’s get started
Everything about images
1. Prefer trustworthy images
If you don’t build your own images, you can quickly fall victim to a supply chain attack. You should not run images that do not come from an official, verified source in your environment / server. If possible, only use images that are backed by an active developer group with problem solvers or companies.
Confusion on image tags and misconceptions: Most people use the :latest tag to select the latest Docker image. This is not true. You can build a Docker image and use any tag you want, e.g. :old-version. You can overwrite old tags and not use : latest. Read the docs to see how the developer uses the tags.
2. Use minimal and unprivileged images
You can do even more wrong when choosing the image.
Use a minimal base OS such as Alpine Linux, which does not include many of the tools of a normal desktop distribution. The advantage of this is that the attack surface is reduced, and the hacker has fewer opportunities to exploit the software in the Docker container. The image sizes are also smaller, which speeds up installation.
3. Take versioning and rollbacks seriously
You should use container versioning as you would with real software.
You should not arbitrarily push a release to different tags, but rather adhere to semantic versioning. Users who use the system in production are then more careful when they install a new main version.
Secure installation
4. Use root-free installations
Docker is not normal software that you can easily run without root rights. The company offers a root-free version, Docker Rootless, which is a viable option for your operation.
The rootless version limits some options. Normally, no non-root programme may open a port between 1 and 1024 because the system reserves these for the well-defined services. Furthermore, some features are not available in the root-free version.
5. No socket expose or multiple instances
The Docker socket is necessary for some programmes, such as Portainer or Jenkins. The sockets use it to control the starting and stopping of containers on the machine.
What is super practical is also a great danger.
An untrusted container has power over all other containers if it has access to the socket.
6. Secure foundation
An updated, hardened operating system is the basis for the secure use of Docker.
What does updated and hardened mean anyway?
The aim is to provide all programmes and components of the operating system in the container with all security patches. New features or new hardware or performance are not the goal here (or in some cases contradict security).
Every operating system should be neutered to such an extent that it can only run the desired software. Any other software can only be an aid for criminals.
Enforce restrictions
7. Restrict resources such as RAM and CPU
You can restrict the resources of a container on your Docker host.
Your system (Linux) usually has X GB of RAM and a RAM file (swap) on the hard drive that serves as emergency RAM.
An attacker attacks and makes the container so resource-hungry that all other programmes on the host cannot / can hardly work. You should therefore limit the RAM.
I have already seen images that do not handle memory properly and consume more and more memory without releasing the memory after work – ” no garbage collection”. You can prevent a system overload by setting a limit.
8. Reduce restarts to 5 per minute
If all images are running well, then nobody needs a safety net.
Unfortunately, a container may no longer start at all due to a misconfiguration or a main update. In combination with the “restart: always” command, the container ends up in an eternal boot loop.
Therefore, limit the container to 5 starts in 60 seconds. Then the system gives up. Ideally, you still have the old image (and a volume snapshot) ready to go back to the old code status.
9. Give read-only rights to volumes
You can restrict these volumes with read-only rights. Not every container needs full rights to every folder on your host file system.
Patching, patching, patching
10. Patch Docker containers like a normal system
Imagine the Docker container is a separate computer. When you build it, you can import and use all kinds of dependencies that mutate into a malware. You need to make sure that the latest security patches are installed in the container.
11. Use scanners for Docker images
Clever developers know the problem with dependencies and have therefore developed a scanner that shows you the CVEs.
This means you don’t have to manually search for vulnerabilities. The scanners do not replace a pentest, but are a must for active development.
12. Do not publish credentials freely to the outside world
The file system in Docker can be confusing. Double check that you are not presenting the password file (.env) to the world in plain text. Instead, it is best to change it with chmod when building the Docker image. All content should have the correct permissions.
Please do not forget ..
13. Create backups of volumes
It is a very, very stupid idea to store the data in a container. The storage is gone as soon as the container is no longer running.
That’s why you need to define Docker volumes (automatic directories) or separate directories for storing data. You must specify this when starting the container.
14. Structure is important!
I hardly ever use the Docker run command anymore.
The Docker Compose is one possible way of proceeding in a structured manner. A productive CLI command with all security features is very long and should therefore be saved (persisted) in a compose file.
You have a better overview and can commit changes to a Git repo. Any change to the compose file can destroy the function. A repo is your safety net.
15. Consider whether load balancing makes sense
Docker is great, but not a solution for all problems.
A Docker container can only be as strong as the host itself. Therefore, use a container management system like Kubernetes. These systems are rubbish if you only have one machine. The system comes with modules for load balancing. A load balancer distributes the load evenly across the various containers.
