6.1 Ensure that image sprawl is avoided

Information

You should not keep a large number of container images on the same host. Use only tagged images as appropriate.

Rationale:

Tagged images are useful if you need to fall back from the 'latest' version to a specific version of an image in production. Images with unused or old tags may contain vulnerabilities that might be exploited if instantiated.

Impact:

docker system prune -a removes all exited containers as well as all images and volumes that are not referenced by running containers. If any images are removed, this would result in needing to reload the images to the host.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

You should keep only the images that you actually need and establish a workflow to remove old or stale images from the host. Additionally, you should use features such as pull-by-digest to get specific images from the registry.
You can follow the steps below to find unused images on the system so they can be deleted.
Step 1 Make a list of all image IDs that are currently instantiated by executing the command below:

docker images --quiet | xargs docker inspect --format '{{ .Id }}: Image={{ .Config.Image }}'

Step 2: List all the images present on the system by executing the command below:

docker images

Step 3: Compare the list of image IDs created from Step 1 and Step 2 to find out images which are currently not being instantiated.
Step 4: Decide if you want to keep the images that are not currently in use. If they are not needed, delete them by executing the following command:

docker rmi <IMAGE ID>

Alternatively, the docker system prune command can be used to remove dangling images which are not tagged or, if necessary, all images that are not currently used by a running container when used with the -a option.

Default Value:

Images and layered filesystems remain accessible on the host until the administrator removes all tags that refer to those images or layers.

See Also

https://workbench.cisecurity.org/files/3353