Best practices for container image security

The following 12 best practices are critical in helping you create and maintain secure container images:

1. Use minimal base image: This reduces image size and also reduces the number of libraries/utilities that may have vulnerabilities or may be used for malicious purposes.
2. Use base image from trusted source and check signatures/digests: What level of confidence do you have that the container is what it says it is and is safe?
3. Reference base image by a specific version tag, not "latest": You need to know the specific version you are using, for component tracking and rebuilding of images. The "latest" image is a moving target, so the orchestrator could pull a new image with unintended consequences.
4. Install the minimum required packages: This reduces image size and also reduces the number of packages/components that may have vulnerabilities or may be used for malicious purposes.
5. Don't perform "apt upgrade" or "yum upgrade" equivalents: These impact the creation of immutable, consistent builds.
6. Specify a user other than root to run the container (ideally as USER ${UID} for Red Hat OpenShift mustRunAsNonRoot compatibility): Aim for minimal privilege. Containers run as root by default, and this is a risk, especially if the container is run with privilege. Use a non-root user to avoid this.
7. Include a healthcheck: An important security control is that of availability. Adding the HEALTHCHECK instruction to your container image ensures that the container engine periodically checks the running container instances against that instruction to ensure that the containers are still operational. (Note: Kubernetes can be used to perform the healthcheck.)
8. Don't write any secrets, passwords, or keys into Dockerfiles (including not as ARG or ENV): You’ll be storing sensitive information in plain text. Consider who will be able to see these details and potentially use them.
9. Use the COPY command (rather than ADD) where possible: ADD automatically extracts archives that could have malicious content (plus other reasons).
10. Don't open port 22 or include SSH unless specifically required: This provides a potential attack vector, and SSH isn’t required to monitor the container. (For more information, see If you run SSHD in your Docker containers, you're doing it wrong!). Docker and Kubernetes/OpenShift enable you to exec into a container.
11. Remove (where possible) any suid or sgid permissions: These are two special permissions that can be set on executable files: set user ID (suid) and set group ID (sgid). These permissions allow the file being executed to be executed with the privileges of the owner or the group.
12. Configure containers to work under OpenShift restricted SCC: For compatibility, ensure that any required directories have chmod g=u & chgrp -R 0 applied and that the HOME environment variable is supplied.

Also, bear in mind...

Container images should be scanned during development to ensure that container configuration is as secure as possible and in line with best practices.

In addition to checking that the Dockerfile/containerfile is configured in line with best practices, you should perform the following checks against the image filesystem:

• Check for OS and non-OS packages with vulnerabilities (and also check the age of the vulnerability feeds).
• Are there any unknown (non-official) application dependency feeds (such as NPM or Ruby) being used?
• Is the distribution used for the container not one of a defined list (such as: alpine, busybox, centos, ubuntu, debian, fedora, or ol)? If so, there could be issues with provenance.

Finally, images that are being used within the environment should be continuously scanned against updated vulnerability databases to ensure that new vulnerabilities are managed.