CIS Docker Benchmark v1.7.0

4.1 Ensure that a user for the container has been created (Manual)
Profile Applicability:
Level 1 - Docker - Linux
Description:
Containers should run as a non-root user.
Rationale:
It is good practice to run the container as a non-root user, where possible. This can be done either via the USER directive in the Dockerfile or through gosu or similar where used as part of the CMD or ENTRYPOINT directives.
Impact:
Running as a non-root user can present challenges where you wish to bind mount volumes from the underlying host. In this case, care should be taken to ensure that the user running the contained process can read and write to the bound directory, according to their requirements.
Audit:
You should run the following command 

docker ps --quiet | xargs --max-args=1 -I{} docker exec {} cat /proc/1/status | grep '^Uid:' | awk '{print $3}' 

This should return the effective UID for each container and where it returns 0, it indicates that the container process is running as root.
Note that some services may start as the root user and then starts all other related processes as an unprivileged user.
Remediation:
You should ensure that the Dockerfile for each container image contains the information below: 

USER <username or ID>

In this case, the user name or ID refers to the user that was found in the container base image. If there is no specific user created in the container base image, then make use of the useradd command to add a specific user before the USER instruction in the Dockerfile. 
For example, add the below lines in the Dockerfile to create a user in the container: 

RUN useradd -d /home/username -m -s /bin/bash username USER username 

Note: If there are users in the image that are not needed, you should consider deleting them. After deleting those users, commit the image and then generate new instances of the containers.
Alternatively, if it is not possible to set the USER directive in the Dockerfile, a script running as part of the CMD or ENTRYPOINT sections of the Dockerfile should be used to ensure that the container process switches to a non-root user.
Default Value:
By default, containers are run with root privileges and also run as the root user inside the container. 

4.2 Ensure that containers use only trusted base images (Manual)
Profile Applicability:
Level 1 - Docker - Linux
Description:
You should ensure that container images you use are either written from scratch or are based on another established and trusted base image downloaded over a secure channel.
Rationale:
Official repositories contain Docker images curated and optimized by the Docker community or by their vendor. There is no guarantee that these images are safe and do not contain security vulnerabilities or malicious code. Caution should therefore be exercised when obtaining container images from Docker and third parties and running these images should be reviewed in line with organizational security policy.
Impact:
None.
Audit:
You should review what Docker images are present on the host by executing the command below: 

docker images 

This command lists all the container images that are currently available for use on the Docker host. You should then review the origin of each image and review its contents in line with your organization's security policy. 
You can use the command below to review the history of commits to the image. 

docker history <imageName>

Remediation:
The following procedures are useful for establishing trust for a specific image. 

Default Value:
Not Applicable. 

4.3 Ensure that unnecessary packages are not installed in the container (Manual)
Profile Applicability:
Level 1 - Docker - Linux
Description:
Containers should have as small a footprint as possible, and should not contain unnecessary software packages which could increase their attack surface.
Rationale:
Unnecessary software should not be installed into containers, as doing so increases their attack surface. Only packages strictly necessary for the correct operation of the application being deployed should be installed.
Impact:
None.
Audit:
List all the running instances of containers by executing the command below: 

docker ps --quiet 

For each container instance, execute the relevant command for listing all installed packages, e.g.: 

docker exec $INSTANCE_ID rpm -qa 

The command above lists the packages installed. You should review the list and ensure that everything installed is actually required.
Remediation:
You should not install anything within the container that is not required. You should consider using a minimal base image rather than the standard Centos, Debian, or Red Hat images if you can. Some of the options available include BusyBox and Alpine.
Not only can this trim your image size considerably, but there would also be fewer pieces of software which could contain vectors for attack.
Default Value:
Not Applicable. 

4.4 Ensure images are scanned and rebuilt to include security patches (Manual)
Profile Applicability:
Level 1 - Docker - Linux
Description:
Images should be scanned frequently for any vulnerabilities. You should rebuild all images to include these patches and then instantiate new containers from them.
Rationale:
Vulnerabilities are loopholes or bugs that can be exploited by hackers or malicious users, and security patches are updates to resolve these vulnerabilities. Image vulnerability scanning tools can be use to find vulnerabilities in images and then check for available patches to mitigate these. Patches update the system to a more recent code base which does not contain these problems, and being on a supported version of the code base is very important, as vendors do not tend to supply patches for older versions which have gone out of support. Security patches should be evaluated before applying and patching should be implemented in line with the organization's IT Security Policy.
Care should be taken with the results returned by vulnerability assessment tools, as some will simply return results based on software banners, and these may not be entirely accurate.
Impact:
None.
Audit:
List all the running instances of containers by executing the command below: 

docker ps --quiet 

For each container instance, use the package manager within the container (assuming there is one available) to check for the availability of security patches.
Alternatively, run image vulnerability assessment tools to scan all the images in your environment.
Remediation:
Images should be re-built ensuring that the latest version of the base images are used, to keep the operating system patch level at an appropriate level. Once the images have been re-built, containers should be re-started making use of the updated images.
Default Value:
By default, containers and images are not updated automatically to address missing operating system security patches. 

4.5 Ensure Content trust for Docker is Enabled (Manual)
Profile Applicability:
Level 2 - Docker - Linux
Description:
Content trust is disabled by default and should be enabled in line with organizational security policy.
Rationale:
Content trust provides the ability to use digital signatures for data sent to and received from remote Docker registries. These signatures allow client-side verification of the identity and the publisher of specific image tags and ensures the provenance of container images.
Impact:
In an environment where DOCKER_CONTENT_TRUST is set, you are required to follow trust procedures whilst working with the image related commands - build, create, pull, push and run. You can use the --disable-content-trust flag to run individual operations on tagged images without content trust on an as needed basis, but this defeats the purpose of enabling content trust and therefore should be avoided wherever possible.
Note: Content trust is currently only available for users of the public Docker Hub. It is currently not available for the Docker Trusted Registry or for private registries.
Audit:
You should execute the following command: 

echo $DOCKER_CONTENT_TRUST 

This should return a value of 1.
Remediation:
To enable content trust in a bash shell, you should enter the following command: 

export DOCKER_CONTENT_TRUST=1 

Alternatively, you could set this environment variable in your profile file so that content trust in enabled on every login.
Default Value:
By default, content trust is disabled. 

4.6 Ensure that HEALTHCHECK instructions have been added to container images (Manual)
Profile Applicability:
Level 1 - Docker - Linux
Description:
You should add the HEALTHCHECK instruction to your Docker container images in order to ensure that health checks are executed against running containers.
Rationale:
An important security control is that of availability. Adding the HEALTHCHECK instruction to your container image ensures that the Docker engine periodically checks the running container instances against that instruction to ensure that containers are still operational.
Based on the results of the health check, the Docker engine could terminate containers which are not responding correctly, and instantiate new ones.
Impact:
None.
Audit:
You should run the command below to ensure that Docker images have the appropriate HEALTHCHECK instruction configured. 

docker inspect --format='{{ .Config.Healthcheck }}' <IMAGE>

Remediation:
You should follow the Docker documentation and rebuild your container images to include the HEALTHCHECK instruction.
Default Value:
By default, HEALTHCHECK is not set. 

4.7 Ensure update instructions are not used alone in Dockerfiles (Manual)
Profile Applicability:
Level 1 - Docker - Linux
Description:
You should not use OS package manager update instructions such as apt-get update or yum update either alone or in a single line in any Dockerfiles used to generate images under review.
Rationale:
Adding update instructions in a single line on the Dockerfile will cause the update layer to be cached. When you then build any image later using the same instruction, this will cause the previously cached update layer to be used, potentially preventing any fresh updates from being applied to later builds.
Impact:
None
Audit:
Step 1: Run the command below to get the list of images: 

docker images 

Step 2: Run the command below against each image in the list above, looking for any update instructions which are incorporated in a single line: 

docker history <Image_ID>

Alternatively, if you have access to the Dockerfile for the image, you should verify that there are no update instructions configured as described above.
Remediation:
You should use update instructions together with install instructions and version pinning for packages while installing them. This will prevent caching and force the extraction of the required versions.
Alternatively, you could use the --no-cache flag during the docker build process to avoid using cached layers.
Default Value:
By default, Docker does not enforce any restrictions on using update instructions. 

4.8 Ensure setuid and setgid permissions are removed (Manual)
Profile Applicability:
Level 2 - Docker - Linux
Description:
Removing setuid and setgid permissions in the images can prevent privilege escalation attacks within containers.
Rationale:
setuid and setgid permissions can be used for privilege escalation. Whilst these permissions can on occasion be legitimately needed, you should consider removing them from packages which do not need them. This should be reviewed for each image.
Impact:
The above command would break all executables that depend on setuid or setgid permissions including legitimate ones. You should therefore be careful to modify the command to suit your requirements so that it does not reduce the permissions of legitimate programs excessively. Because of this, you should exercise a degree of caution and examine all processes carefully before making this type of modification in order to avoid outages.
Audit:
You should run the command below against each image to list the executables which have either setuid or setgid permissions: 

docker export  | tar -tv 2>/dev/null | grep -E '^[- rwx].*(s|S).*\s[0-9]' 

You should then review the list and ensure that all executables configured with these permissions actually require them.
Remediation:
You should allow setuid and setgid permissions only on executables which require them. You could remove these permissions at build time by adding the following command in your Dockerfile, preferably towards the end of the Dockerfile: 

RUN find / -perm /6000 -type f -exec chmod a-s {} \; || true 

Default Value:
Not Applicable 

4.9 Ensure that COPY is used instead of ADD in Dockerfiles (Manual)
Profile Applicability:
Level 1 - Docker - Linux
Description:
You should use the COPY instruction instead of the ADD instruction in the Dockerfile.
Rationale:
The COPY instruction simply copies files from the local host machine to the container file system. The ADD instruction could potentially retrieve files from remote URLs and perform operations such as unpacking them. The ADD instruction therefore introduces security risks. For example, malicious files may be directly accessed from URLs without scanning, or there may be vulnerabilities associated with decompressing them.
Impact:
Care needs to be taken in implementing this control if the application requires functionality that is part of the ADD instruction, for example, if you need to retrieve files from remote URLs.
Audit:
Run the command below to get the list of images: 

docker images 

Run the command below against each image in the list above and look for any ADD instructions: 

docker history <IMAGE ID>

Alternatively, if you have access to the Dockerfile for the image, you should verify that there are no ADD instructions.
Remediation:
You should use COPY rather than ADD instructions in Dockerfiles.
Default Value:
Not Applicable 

4.10 Ensure secrets are not stored in Dockerfiles (Manual)
Profile Applicability:
Level 1 - Docker - Linux
Description:
Do not store any secrets in Dockerfiles.
Rationale:
Docker images are not opaque and contain information about the commands used to build them. As such secrets should not be included in Dockerfiles used to build images as they will be visible to any users of the image.
Impact:
A proper secrets management process will be required for Docker image building.
Audit:
Run the below command to get the list of images: 

docker images 

Run the below command for each image in the list above, and look for any secrets: 

docker history <IMAGE ID>

Alternatively, if you have access to Dockerfile for the image, verify that there are no secrets as described above.
Remediation:
Do not store any kind of secrets within Dockerfiles. Where secrets are required during the build process, make use of a secrets management tool, such as the buildkit builder included with Docker.
Default Value:
By default, there are no restrictions on storing config secrets in the Dockerfiles. 

4.11 Ensure only verified packages are installed (Manual)
Profile Applicability:
Level 2 - Docker - Linux
Description:
You should verify the authenticity of packages before installing them into images.
Rationale:
Verifying authenticity of software packages is essential for building a secure container image. Packages with no known provenance could potentially be malicious or have vulnerabilities that could be exploited.
Impact:
None
Audit:
Run the command below to get the list of images: 

docker images 

Run the command below for each image in the list above, and check how the authenticity of the packages is being determined. This could be via the use of GPG keys or other secure package distribution mechanisms. 

docker history <IMAGE ID>

Alternatively, if you have access to Dockerfile for the image, verify that the authenticity of the packages is checked.
Remediation:
You should use a secure package distribution mechanism of your choice to ensure the authenticity of software packages.
Default Value:
Not Applicable 

4.12 Ensure all signed artifacts are validated (Manual)
Profile Applicability:
Level 1 - Docker - Linux
Description:
Validate artifacts signatures before uploading to the package registry.
Rationale:
Cryptographic signature is a tool to verify artifact authenticity. Every artifact is supposed to be signed by its creator in order to verify that it wasn't compromised until it got to the client. Validating artifact signature before delivering it is another level of protection, which checks that the signature hasn't been changed, which means that no one tried or succeeded in tampering with the artifact. That sets trust between the supplier and the client.
Audit:
Ensure every artifact in the package has been validated with its signature.
Remediation:
Validate every artifact with its signature. It is recommended to do so automatically.