[security] improve Docker file

[line-o]

Check additional policy boxes in docker-scout

• add SBOM
• add provenance
• run as nonroot

References

• our current docker-scout score: https://scout.docker.com/reports/org/existdb/images/host/hub.docker.com/repo/existdb%2Fexistdb/tag/latest/digest/sha256%3Ae6fe210d3e68cfbde9f9b4196575dee3ebc460981457daea374dee6e4b4760a0/policy

[line-o]

I am not able to find a configuration for the docker/setup-buildx-action that uses containerd storage for building. That is the only way to make SBOM and provenance export in multi-arch builds work (tested on my local machine).

ALSO NOTE: If you want to try this at home you will have to switch to containerd as well. Otherwise your build will fail with the same error:

[INFO] DOCKER> ERROR: failed to build: docker exporter does not currently support exporting manifest lists

--- update ---

Modifying the docker deamon and restarting docker seems to be the only viable option.

[duncdrum]

This is a breaking change. Why would you chown nonroot on a normal base image? That's what the nonroot tags are for. So consume :nonroot in FROM and also tag modify the pushed tag to signal a break from :latest images as they are now.

I find nonroot easier to read and self documenting instead of GID numbers

[line-o]

This is a breaking change.

I would like to know what exactly you see as a breaking change @duncdrum

Why would you chown nonroot on a normal base image?

I am not sure what you mean by that. We are using the distroless base image which creates a user nonroot. This user has a fixed UID and GID. Unfortunately - according to GoogleContainerTools/distroless#427 - we cannot use its name but have to resort to its numeric identifier.

Before this change the image we provided ran as root because we did not specify a USER

A Dockerfile with a base image without specifying a USER will run commands as the root user by default, which can pose security risks.

Docker Scout in which we enrolled today flagged it for the non-DEBUG builds and I considered this a security issue/ bug.

If we consider this a breaking change then now is the perfect moment to do it.

[duncdrum]

@line-o what do you mean where is the breakage? This potentially breaks every docker build that incorporates any of the tagged images, volume owner ship, logging aggregation, conf modifications, … all will have to deal with potential permissions denied errors.

There is no reason to break the existing tags. The use of root is not an oversight, but a convention that dates back to how this whole container thing started. There is a way to get around it, but that is by not breaking existing tags. Instead issue new ones that clearly state the kind of image, like distroless does it as well.

Yes the vanilla base image defines the user, but doesn't apply it anywhere, everything still works with root , use the nonroot image to actually have the user own stuff. I never experienced the problems in the link, https://hub.docker.com/r/duncdrum/existdb/tags?name=nonroot setting user to nonroot:nonroot works just fine for me.

see https://github.com/duncdrum/distroless-exist/actions/runs/28210943614/job/83571939672#step:16:71

[line-o]

I see that the switch to nonroot by default is controversial and will split it into a separate PR.

There is no reason to break the existing tags

The moving target like release do include breaking changes. Switching to nonroot is just another one.
Anyone interested in immutable containers should use a versioned image and the downstream projects I know of do exactly that.

[line-o]

@duncdrum I left the Docker images to run as root in order to further discuss this next

I also decided to not add SBOM and provenance all the time but added flags that can be activated.
These are now activated in CI for all images built by the job.

[line-o]

SBOM and provenance added to the image(s)

[INFO] DOCKER> docker --config /home/runner/work/exist/exist/exist-docker/target/docker/existdb/existdb/7.0.0-SNAPSHOT/docker buildx build --progress=plain --builder maven --platform linux/amd64 --tag existdb/existdb:7.0.0-SNAPSHOT --tag existdb/existdb:latest --sbom=true --provenance=true --file=/home/runner/work/exist/exist/exist-docker/target/docker/existdb/existdb/7.0.0-SNAPSHOT/tmp/docker-build/Dockerfile /home/runner/work/exist/exist/exist-docker/target/docker/existdb/existdb/7.0.0-SNAPSHOT/tmp/docker-build --load

[duncdrum]

This makes sense.