Prefer minimal base images
Often times, you might start projects with a generic Docker container image such as writing a Dockerfile with a FROM node, as your “default”.
However, when specifying the node image, you should take into consideration that the fully installed Debian Stretch distribution is the underlying image that is used to build it.
If your project doesn’t require any general system libraries or system utilities then it is better to avoid using a full blown operating system (OS) as a base image.
In Snyk’s State of open source security report – 2019, we found that many of the popular Docker containers that are featured on the Docker Hub website are bundling images that contain many known vulnerabilities.
For example, when you use a generic and popularly downloaded node image such as docker pull node, you are actually introducing an OS into your application that is known to have 580 vulnerabilities in its system libraries.
Taken from the open source security report 2019, as can be seen, each of the top ten Docker images we inspected on Docker Hub contained known vulnerabilities.
By preferring minimal images that bundle only the necessary system tools and libraries required to run your project, you are also minimizing the attack surface for attackers and ensuring that you ship a secure OS.
This tip is part of a complete 10 Docker image security best practices you should adopt. Thanks for reading and to Omer Levi Hevroni who worked with me on it.
The original blog post includes a high-resolution printable PDF like the snippet you see below. Check it out
Top comments (4)
Hi Jorge,
Thanks for chiming in :-)
I actually don't share the same thought about containers used only for dev. The growth of Docker and containers in general has been tremendous over the past 5 years and it is expected to further grow into 2020 in tens of percents.
Even if we were to think that containers are only used for development, you'd still be at a risk of using a malicious docker container from the registry, that would spin up on your development machine and who knows what it does. That's however a less-likely scenario, but points out the interest in keeping things secure, whether they are running locally or not.
I am curious - if not docker, how are you orchestrating and managing your services?
I work with a team of 13 devs for 3 years now. We had a not-dockerized architecture on AWS. It worked well. was expensive as hell. Since we started dockerizing everything, we created an environment of containers that work together as a charm. If we need to escalate, we just replicate the environment in another machine and add it to the load balancer. If we need a development environment, we just deploy the docker env. and are up to debug / test.
Also, after dockerizing everything, we don't depend on AWS anymore but for the RDS. We have more power, more flexibility and the cost reduced at least x5
I really don't know what you mean when you say Docker is not for production, but it is certainly not true, in my case at least.
Regards
You mean you are running a shared hosted environment?
Probably so. However if you take a look at Zeit's now. You could think of that as shared hosting environment too, and they support serving your apps through container technology.
You don't "need", but perhaps it solves you some problems.
Why a mess? if you have 20 difference projects, and each of their own configuration, why is that a message?
I'm not entirely sure on the point you are trying to make with regards to the validity of docker or not. To be clear though, I didn't specifically refer to the Docker engine technology but to container technology in general.
I'm also curious, if not docker, what Jorge is using for production.
Thanks.