According to Docker Docs, a Dockerfile is a text document that contains all the instructions a user could call on the command line to assemble an image. These instructions include actions like installing software, copying files, setting environment variables, and defining how an application should run.
Wrongly implementing instructions in a Dockerfile might present vulnerabilities which attackers can exploit to gain root access to the underlying infrastructure, gain privileges by using exposed secrets, and so much more.
I have compile a list of common docker security issues using yaml. For each issue, I defined a regex rule which can be used statically analyze your dockerfile.
There are some limitations to using regex rules for static analysis, some of which include:
- Dockerfile syntax may evolve over time causing the current regex patterns to become outdated.
- Regex may not interprete the intended purpose of certain instructions.
- Regex patterns may struggle in understanding multiline and nested instructions found in Dockerfiles.
- They may lead to false positives or false negatives.
You can find the .yaml rules in this repository. I will appreciate your feedback and contributions.
Common Security Issues
1. Using the 'latest' tag for base images.
It is advicable to pin your docker image to a particular version instead of using the 'latest' tag which results to a different version at different points in time.
Using the latest tag doesn't gaurantee that you are using the most recent and stable version of an image. However, it might introduce breaking changes in the best worst case scenario or even security vulnerabilities in the worst worst case.
Always pin your images and dependencies to particular versions and update them regularly.
2. Running as Root
Secure system design follows the principle of least privilege. This simply states that a process should be able to access only the information and resources it needs to accomplish its legitimate purpose and nothing more.
Running processes as root in a Dockerfile can give access to code or other users to maliciously to gain full access to your container and host system. Not defining a user at all can also lead to unexpected behaviour that can lead to granting root access to non-root users or code.
To avoid this, always define a non-root user in your dockerfile that will be used to execute commands. This is done using the USER directive in your dockerfile.
3. Using Sudo to execute commands
Just as you shouldn't use the root user, you shouldn't use sudo to run commands either as it also violates the principle of least privilege.
When running as a user, also ensure the user is not in the sudoers file to avoid the complications that come from running as root.
4. Copying Unnecessary Files
Unnecessary files in your docker image can increase the size, complexity, and attack surface of your image. It can also slow down the build and run time of your docker container.
It is a Dockerfile best practice to create a subfolder that contains the files that need to be copied to the docker container image. Also, where possible, use a .dockerignore file to explicitly exclude files and directories. Avoid using wildcards like '.' when defining a COPY directive.
5. Exposed Secrets
Never store secrets or credentials in any form of docker instructions such as environment variables, args or hardcoded into any command.
You could make use of Docker Secrets to provide the values as environment variables.
6. Using Vulnerable Images
This kind of vulnerability is introduced from the hierarchy of layers used to build the container image. It provides a risk to supply chain attacks
Untrusted base images are the main source of such vulnerabilities and should be avoided at all cost. The source of the base image should be verified and the image should be updated regularly.
Top comments (0)