Closed ThorstenHans closed 1 year ago
This looks to be a false positive from the dockle tool. I would suggest logging an issue at https://github.com/goodwithtech/dockle instead.
We had recently switched over from the Ubuntu images hosted on Docker Hub to the Ubuntu image's hosted on Canonical's ACR: ubuntu.azurecr.io. That change resulted in the difference you're seeing. But when you look at the images, they are essentially the same with respect to the usage of the ADD
instruction.
> docker history ubuntu:focal
IMAGE CREATED CREATED BY SIZE COMMENT
680e5dfb52c7 3 weeks ago /bin/sh -c #(nop) CMD ["bash"] 0B
<missing> 3 weeks ago /bin/sh -c #(nop) ADD file:7633003155a105941ā¦ 72.8MB
> docker history ubuntu.azurecr.io/ubuntu:focal
IMAGE CREATED CREATED BY SIZE COMMENT
04441f7fff00 13 days ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0B
<missing> 13 days ago /bin/sh -c #(nop) ADD file:5dfb5928594745d5dā¦ 72.8MB
<missing> 13 days ago /bin/sh -c #(nop) LABEL org.opencontainers.ā¦ 0B
<missing> 13 days ago /bin/sh -c #(nop) LABEL org.opencontainers.ā¦ 0B
<missing> 13 days ago /bin/sh -c #(nop) ARG LAUNCHPAD_BUILD_ARCH 0B
<missing> 13 days ago /bin/sh -c #(nop) ARG RELEASE 0B
You can see in both images that they use the ADD
instruction. For whatever reason, the dockle tool doesn't produce a violation for the image from Docker Hub even though its first two layers are structured the same as the image from ubuntu.azurecr.io.
Looking at the dockle code, I see this relevant section:
That code is checking for the violation of CIS-DI-0009. You can see that they check the layer index and skip the check if it's the first layer. That makes sense since nearly all images use the ADD instruction to inject the initial file system. But I'm confused on how that works since it's checking for index 0 and the output of the history commands above show that index 0 is the CMD
instruction. So it's not clear to me why the image from Docker Hub also doesn't violate this check.
Regardless, the maintainers of the dockle tool should investigate this because looking at the image history shows there's really no consequential difference between the images hosted between Docker Hub and ubuntu.azurecr.io. So please log an issue with dockle.
Thanks @mthalman šš¼ for looking into this. I've created the corresponding issue in the dockle repository.
After discussing this with others I realized that I interpreted the history in the incorrect order. The Docker Hub image has the ADD
instruction as the first instruction which gets skipped according to dockle's logic. But for the image in the Ubuntu ACR, the first instruction is an ARG
. The ADD
instruction doesn't occur until several other instructions in the history. So that's not causing the check to be skipped in dockle's logic. This leads to the violation.
This is the Dockerfile used by the image from the Ubuntu ACR (from https://git.launchpad.net/cloud-images/+oci/ubuntu-base/tree/Dockerfile?h=focal-20.04):
FROM scratch
ARG RELEASE
ARG LAUNCHPAD_BUILD_ARCH
LABEL org.opencontainers.image.ref.name="ubuntu"
LABEL org.opencontainers.image.version=$RELEASE
ADD ubuntu-*-oci-$LAUNCHPAD_BUILD_ARCH-root.tar.gz /
CMD ["/bin/bash"]
As you can see, the ARG
instructions are listed first and the ADD
instruction depends on one of them. So it's not possible for the ADD
instruction to be listed first in the history. So dockle needs to account for this scenario by allowing for empty layers to be listed before the first ADD
instruction.
Closing this since this is something that dockle needs to account for, based on what I mentioned above.
Describe the Bug
.NET container images using one of the
focal
tags violateCIS-DI-009
benchmark rule. Non of the base images was violating this rule a couple of weeks ago.I went through all the container images down the path and recognized that the violation is already in
ubuntu.azurecr.io/ubuntu:focal
. That said, I was not able to find theDockerfile
used to createubuntu.azurecr.io/ubuntu:focal
šI use latest (
v.0.4.9
) of dockle to lint container images.Steps to Reproduce
This can easily be validated using the following steps:
Output of
docker version
Output of
docker info