Rules for Configuring the Container Image and Build Files
Creating a Non-root User for the Container Image
In Dockerfile, create a non-root user for the container image. If possible, use a non-root user account to run the container. If a user has been defined in the container image, the container is run by the defined user by default. User namespace remapping is unnecessary.
No non-root users are created for Kbox. Determine whether to create a non-root user based on your site requirements. If you create a non-root user, compatibility issues may occur.
Scanning and Rebuilding Images to Include Security Patches
It is a good practice to scan images frequently to find vulnerabilities. Rebuild images so that patches can be installed in a timely manner and new containers can be created. Vulnerabilities are weaknesses that can be exploited. Security patches are updates that resolve vulnerabilities. You can use scan tools to find vulnerabilities within an image and then check for available patches to mitigate those issues. Patches update the system to the most recent code base, which is where vendors typically target their latest fixes. Before applying security patches, evaluate them and follow the best patching practices. In addition, it is recommended that the image vulnerability scan tools be able to perform binary analysis or hash-based verification, not only version string matching.
Prevention of Using the ADD Instruction in the Dockerfile to Operate Untrusted Files
The ADD instruction can retrieve files from remote URLs and automatically perform operations such as unpacking. Files obtained from a remote URL are untrusted and must be scanned to check whether the files are malicious or have vulnerabilities. If malicious files from a URL are added without being scanned or programs with vulnerabilities are decompressed, the system may be damaged. For example, important system files are replaced due to automatic decompression of malicious compressed packages. Therefore, using the ADD instruction to operate untrusted files remotely brings security risks.
Storing No Confidential Data in the Dockerfile
You can use Docker commands such as docker history or various tools and utilities to backtrack Dockerfile. Also, as a general practice, image publishers provide a Dockerfile to build the credibility for their images. Hence, the confidential data within the Dockerfile could be easily exposed and potentially exploited. Do not store any kind of confidential data within the Dockerfile. Check whether the built-in image software obtained from external systems has built-in accounts or keys to prevent backdoors.
Enabling Content Trust
Content trust allows Docker publishers to sign the content they publish, improving the trust distribution mechanism. When a user pulls an image from the registry, the user receives a certificate that contains the public key of the publisher, allowing the user to verify the integrity and authenticity of the image. When content trust is enabled, the Docker engine performs operations only on signed images and rejects images whose signatures or digests do not match. By default, content trust is disabled.
Adding Health Check to Container Images
After health check is added to your container images, the Docker engine periodically checks the running container instances to ensure that the instances are still working. Based on the reported health status, the Docker engine may then exit non-working containers and instantiate new ones.
Prohibition of Using the Update Instruction Alone in the Dockerfile
Adding the update instruction in a single line of the Dockerfile will cache the update layer. When you then build an image using the same instruction, the previously cached update layer will be used. This could potentially block fresh updates from being added to later builds.