In this article, i will write down Docker image best practices. Micro service is so popular now a days and where the services are deployed in docker container using any of these orchestration tools like Docker swarm, Kubernates.

As per snyk.io, the official Node.js image ships 580 vulnerable system libraries, followed by the others each of which ship at least 30 publicly known vulnerabilities. (Refer here)

Below are the suggested best practices by https://snyk.io

Prefer minimal base images

  • Choose images with fewer OS libraries and tools lower the risk and attack surface of the container
  • Prefer alpine-based images over full-blown system OS images

Least privileged user

  • Create a dedicated user and group on the image, with minimal permissions to run the application; use the same user to run this process. For example, Node.js image which has a built-in node generic user:
FROM node:10-alpine
USER node
CMD node index.js

Sign and verify images to mitigate MITM attacks

It is critical to make sure the image we’re pulling is the one pushed by the publisher, and that no one has tampered with it.

  • Sign your images with the help of Notary
  • Verify the trust and authenticity of the images you pull

Find, fix and monitor for open source vulnerabilities

Scan your docker images for known vulnerabilities and integrate it as part of your continuous integration. Snyk is an open source tool that scans for security vulnerabilities in open source application libraries and docker images.

OR

Download CIS benchmark tool for Docker from official Docker repo

git clone https://github.com/docker/docker-bench-security.git

and run the benchmark tool

sh docker-bench-security.sh

You can find the Documentation here. Now wait for some time to get the script executes completely. It gives you  which all configuration got Passed and failed. Fix all  the configuration errors.

docker-bench-security

Don’t leak sensitive information to docker images

It’s easy to accidentally leak secrets, tokens, and keys into images when building them. Please, follow these guidelines:

  • Use multi-stage builds
  • Use the Docker secrets feature to mount sensitive files without caching them
  • Use a .dockerignore file to avoid a hazardous COPY instruction, which pulls in sensitive files that are part of the build context

Use fixed tags for immutability

Docker image owners can push new versions to the same tags, which may result in inconsistent images during builds, and makes it hard to track if a vulnerability has been fixed.

  • A verbose image tag with which to pin both version and operating system, for example: FROM node:8-alpine.
  • An image hash to pin the exact contact, for example: FROM node:

Use COPY instead of ADD

Arbitrary URLs specified for ADD could result in MITM attacks, or sources of malicious data. In addition, ADD implicitly unpacks local archives which may not be expected and result in path traversal and Zip Slip vulnerabilities. Use COPY, unless ADD is specifically required.

Use labels for metadata

Labels with metadata for images provide useful information for users. Include security details as well. Use and communicate a Responsible Security Disclosure policy by adopting a SECURITY.TXT policy file and providing this information in your images labels.

Use multi-stage builds for small secure images

Use multi-stage builds in order to produce smaller and cleaner images, thus minimising the attack surface for bundled docker image dependencies.

Use a linter

Enforce Dockerfile best practices automatically by using a static code analysis tool such as hadolint linter, that will detect and alert for issues found in a Dockerfile.

Reference: snyk.io