Switch base image to distroless

[agologan]

This a conversation fueled by CVEs mainly.

Scanned the latest released with Trivy:

docker run --rm -it aquasec/trivy image ghcr.io/sosedoff/pgweb:0.15.0

And here's the overview:

ghcr.io/sosedoff/pgweb:0.15.0 (debian 11.9)
Total: 163 (UNKNOWN: 0, LOW: 91, MEDIUM: 28, HIGH: 40, CRITICAL: 4)

usr/bin/pgweb (gobinary)
Total: 5 (UNKNOWN: 0, LOW: 0, MEDIUM: 4, HIGH: 1, CRITICAL: 0)

Looking at the history of this project it was once alpine: bc4a907
Actually wanted to suggest it as a base image since it has decent developer experience compared to distroless, if you don't have to deal with musl specifically.

What follows is just a test I did on how hard it would be to make it distroless.
Not very, as it seems - though I don't know about those deps since I didn't need any in my testing.

Here are a few options for this conversation:

• switching back to alpine, decent devx, small, almost no CVEs
• switch to distroless, works as far as I can tell but it's a pain to build once you have to deal with deps
• publish multiple versions, requires manging multiple Dockerfiles but shouldn't be too hard
• upgrade base image to bookworm at least since some of the CVEs have already been resolved but are not scheduled to be backported
• do nothing 😋 interested parties can build their own variant fairly easily

[sosedoff]

What exactly are we trying to solve here? Security issues? It seems like most of those are stemming from the base image, but that's going to apply to anyone using said images.

I don't think Pgweb has enough test coverage to properly catch any issues related to OS (missing packages and tools). The project is also a bit slow moving at this point so switching the distro again will cause a bit of pain, at least on my end. I used binaries where possible and only fall back to docker/containers if i have to.

Im open to keep the conversation going though, as i get a bunch of mail accusing pgweb of being responsible for RCEs, but in reality its on users that should not expose such systems to public internet, especially with full access.

[agologan]

Sorry for not providing enough context.
Yes, I'm trying to reduce the number of CVEs associated with the container which mostly stem from the base image.
Most orgs including my own scan all containers and tend to avoid debian base images because the issues caused by extra packages distract from the actual application.

As for the packages, should've done my homework.
Only pg_dump (postresql/postgresql-client) is required for the dump db feature.

Built several versions here are the scan results depending on base images. (excluded the actual go/app list).

# distroless-debian12 (bookworm without postgres-client) (37.9MB)
Total: 13 (UNKNOWN: 0, LOW: 9, MEDIUM: 4, HIGH: 0, CRITICAL: 0)
# bookworm-slim (179MB)
Total: 118 (UNKNOWN: 0, LOW: 75, MEDIUM: 21, HIGH: 21, CRITICAL: 1)
# ubuntu:22.04 (204MB)
Total: 38 (UNKNOWN: 0, LOW: 23, MEDIUM: 15, HIGH: 0, CRITICAL: 0)
# alpine-3.19 (29.8MB)
Total: 6 (UNKNOWN: 0, LOW: 0, MEDIUM: 6, HIGH: 0, CRITICAL: 0)

Also bringing this up, because the history doesn't explain the switch from alpine to debian-slim.

[netroy]

I did not realize that this PR existed, and because I like to use distroless/static based images for all my Go projects, I updated the Dockerfile a few days ago, and have been running the 18MB docker image on my personal cluster without any new issues so far.
So I decided to commit the changes to send a PR, only to see that this PR already exists.
I'm not using "export to SQL", so the missing pg_dump is not an issue for me.

I can't tell the maintainers what base image to use, but If you chose to go with distroless/static or scratch at some point, and need help with that, I would be happy help 🙏🏽.

BTW, thanks for creating a bloat-free tool 🙇🏽 .

[agologan]

We've been running an alpine-based image since this PR due to the convenience factor.
Could advocate for any of the alternatives presented but it's up to the comfort level of the maintainer.
Closing this PR for now.