After docker 1.10, docker history no longer shows intermediate layers of an image if you pulled it from somewhere else, rather than building locally.
This github issue discusses about this change, and also mentions that using docker save and docker load, you can make use of intermediate layers as caches.
Does this mean, if an image is built and is simply uploaded to a repository (i.e. no tar files), there is no way for someone who downloads the image to recover the intermediate layers?
What I specifically want to know is:
COPY sensitive_file .
RUN do_something_with ./sensitive_file
RUN rm ./sensitive_file
Is it okay to write Dockerfile like the above, and assume that (unless there is an unknown vulnerability in docker) this sensitive file will not be accessible by others?
I'm aware that there are other ways of handling credentials or sensitive files, such as setting up a local server and RUN wget file && use file && rm file, docker secret with swarm, or using docker vault. I'm not looking for different approaches to handle sensitive files; rather I am just interested if the above approach makes the file accessible or not. Thank you!
The image is still shipped as layers even though you don't have an image id for each layer. You can see that in docker image inspect $image_name under the .RootFS.Layers section.
Those layers are stored on the hard drive, and may be easily accessible depending on the storage driver being used. At least with overlay2, this is visible in the docker image inspect output under the .GraphDriver section.
Lastly, you can use docker save on any docker engine that has pulled a copy of the image from the registry to convert it back to a tar file that contains each layer as a tar file. So transferring an image by a registry does not eliminate this attack vector.