Container Image and Build Configuration Checklist
Quick checklist for Container Image and Build Configuration Checklist, Importance of each checks are mentioned side by side.
Atomic app per container [HIGH]
Idea is to consider application and container having same lifecycle. So only single app should go with a unit container. Refrain to use tools like supervisor and bash script spinning several apps.
Rootless containers [HIGH]
Ensure application run via a non root user
Don’t bind to a specific UID [MEDIUM]
Refrain usage of specific UID for user as it will cause permission issue in binding
Always use /tmp for temporary data [MEDIUM]
Using /tmp as temporary data will refrain us from leading into file and user permission issue
Make executables owned by root and not writable [HIGH]
Any executable in the containers should be owned by root, which will refrain it from becoming world writable. This will non-root user running application will not able to modify existing binary and exploit more attacks.
Optimise for the build cache [HIGH]
Optimising build cache can accelerate build time and layer sanity. Most frequent changing layer should be placed in bottom to increase cacheability.
Remove unnecessary tools [HIGH]
Remove unnecessary tools like netcat, telnet, nmap etc. This will push attackers to find another way to achieve things which these tools can help them very easily
Build the smallest image possible [MEDIUM]
Build smallest image by removing unwanted files and modules, which may required at the time of build but not at the time of execution of the binary. Multi Stage Build is one the approach to achieve this.
Scan images for vulnerabilities [HIGH]
Local scan or scan on repository push to identify CVE vulnerabilities
Multistage builds, to reduce Risk Surface [MEDIUM]
Leverage Multi stage build to ensure minimal dependencies in final container image, which will eventually reduce the surface area of risk.
Use minimal base container (Distroless) [MEDIUM]
Distroless images contain only application and its runtime dependencies. They do not contain package managers, shells or any other programs we would expect to find in a standard Linux distribution. It again help us in reducing the risk areas.
Use trusted base images [HIGH]
Base images should be written from scratch or are based on another established and trusted base image downloaded over a secure channel.
Exposed ports for flagging and documentation [MEDIUM]
Use Export in dockerfile for information and documentation of Network port for container in execution.
No hardcoded secret or credentials in the Dockerfile [HIGH]
No sensitive information or files should be the part of Dokcerfile. Even including it and removing between layer should be refrained as it might be available in intermediate layers
Prefer COPY, RUN over ADD [HIGH]
ADD instruction could potentially retrieve files from remote URLs and perform operations such as unpacking them. The ADD instruction therefore introduces security risks.
Reduced Build context and leverage dockerignore HIGH
Leverage .dockerignore and reduce are of build context so that it should cover sensitive or confidential information. Exclude files and directory which are not necessary for the docker build
Layer Sanity [MEDIUM]
Layer sanity is practice of writing dockerfile to make it more cacheable by combining multiple Dockerfile instruction and putting instruction which are likely to change at lower. Also taking care of removing some file sing command like rm, it might be not available in final docker image but it can be found in intermediate layer and can be easily accessible.
Leverage Metadata labels & Linting [MEDIUM]
Ensure metadata label which will help us in image management
Include health / liveness checks [HIGH]
Configure health checks to be executed against running containers, to enhance reliability
Ensure setuid and setgid permissions are removed [HIGH]
setuid and setgid permissions can be used for privilege escalation. Whilst these permissions can on occasion be legitimately needed, we should consider removing them from packages which do not need them.
