Especially if you create your own container image. The rules described above are only a part of a larger set but some of the most important ones. Being a test rat for the new features is not really what you would like to do.
In that case, it is always a good practice to use the local Docker registry and keep important images mirrored there.Īlso, check and keep in mind the versioning schema for the image – focusing on how alfa, beta, and test images are versioned. On the other hand, please note that there is a higher chance that some specific versions will be removed. If the version is more specific, then there is a lower risk that it will be changed or updated without notice. To avoid the described issues, it is better to specify the version of your base image: FROM ubuntu:18.04 Another threat is that the latest version may introduce new vulnerabilities that are not yet discovered. Just imagine that you are dependent on some package that has been removed in the latest version of the ubuntu image. It sounds pretty handy, but in some cases, it may break your build because the version may change between the builds. If you do not specify a proper version: FROM ubuntuĭocker will use the latest one. In general, that is true, but it may bring some new risks and issues to your image. You may think that the newest version of your base image will be the most secure one. USER test Use the specific tag for a base imageĪnother threat is not so obvious. But sometimes you may have to create one on your own: RUN groupadd -r test & useradd -r -s /bin/false -g test test In mysql, it is named mysql (what a surprise!). You can use the USER directive for this purpose: FROM myslqĪs you can see in the above example some images have an already defined user, that you can use. To minimize that threat, you have to use a dedicated user/group in the Docker image. So there is a potential risk that it gets root access on the Docker host. If you do not specify any, then it uses the root user inside the container. It should lower the size of the container dramatically as well.Īnother base rule that you should embrace are the privileges inside the container. It will, for sure, lower the number of known vulnerabilities in your container. If not, then you can use some smaller and simpler base images. So you have to decide if you really need that additional functionality. Please take a look at the graph below that shows how the number of those vulnerabilities grows. All of those issues are inherited automatically by your container – unless you mitigate each one in your custom layers. For example, the nginx image hosted on Docker Hub has 98 known vulnerabilities, and node has more than 800. The larger the base is, the more issues may occur.
Minimal imageįirst of all, if you want to start fast, you set some base images with plenty of features built-in. There are plenty of rules to make your container safer, and here we share the best practices to ensure that. But it is now your responsibility to make that image as secure as possible. If you create your own containers, then you have more control over the process and you have a clear vision of what is inside. You can build it, or you can use an existing one. There are two ways how you can get a container image you want to run. Let’s start with container configuration. Hardening workloads often is much harder than hardening the cluster itself. All in all, clusters without containers running does not make much sense. Focusing on Kubernetes security, we have to go through container security and their runtimes.