Open agologan opened 4 months ago
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.
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
.
This a conversation fueled by CVEs mainly.
Scanned the latest released with Trivy:
And here's the overview:
Looking at the history of this project it was once
alpine
: bc4a90774c4b807b8cf58cb92e23a18797bdc323 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 withmusl
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:
alpine
, decent devx, small, almost no CVEsdistroless
, works as far as I can tell but it's a pain to build once you have to deal with depsbookworm
at least since some of the CVEs have already been resolved but are not scheduled to be backported