search

docker-library / official-images

Primary source of truth for the Docker "Official Images" program
https://hub.docker.com/u/library
Apache License 2.0
6.47k stars 2.35k forks source link

Question about making official image a wrapper of existing images #14888

Closed fffonion closed 1 year ago

fffonion commented 1 year ago

Hi, We are developers of Kong and are maintaining both our own docker images (kong/kong) as well as publishing to official images repo (library/kong). In the past, we use two different set of Dockerfiles, build both docker images from same binary packages. However, this causes additional maintainance effort in diverge of Dockerfiles, tests and manual release checklist. As our own docker images are now well covered in our test pipeline, we are thinking of making the "official images" a wrapper of own images, like this PR (https://github.com/Kong/docker-kong/pull/657/files#diff-ecc2ebe6e33785340d50f6680fc6b571f6a210ddc5639b871e1e3ebfc639dd66) does. My question is, would this be considered a appropriate pattern to move forward? (And if not, what are your recommendations as solution?)

Thanks

tianon commented 1 year ago

Unfortunately, this is not going to be an acceptable pattern here.

You could have kong/kong be a copy of library/kong (either rebuilt or using something like crane, regctl, etc to copy the images directly).

(You could also deprecate one of the images and suggest that users convert their usages to the other.)

tianon commented 1 year ago

(Closing because there's nothing actionable for us here, but feel free to continue the discussion.)

fffonion commented 1 year ago

@tianon Thanks for the reply. Could you explain more on why this is not the acceptable approach? I would appreciate some more insights so that we can decide on next steps. We do pin the docker image to its sha256, and pin the git commit in this repo. So technically we still have the same secruity to prevent supply chain attack as before.

tianon commented 1 year ago

See https://github.com/docker-library/official-images#what-are-official-images, especially the fourth bullet point (proactive rebuilding is a core function of the program today) for the simplest explanation.

fffonion commented 1 year ago

@tianon I see the point now. In that case, can it be solved by adding an extra step to do say "apt-get update && apt-get upgrade -y -qq" in the "official image" dockerfile? I do understand the concern of actively rebuild to cover security fixes. But (correct me if i'm wrong) when considering supply chain security, it may worry end user if a tag is rebuilt and overwritten because of s security fix (should it get a new tag?).