Reduce vulnerabilities of docker images

[hellodword]

Related issues:

• Lots of vulnerabilities in Docker images #683
• Deployment vaultwarden (in cluster main) violates 'Process with UID 0' Policy #4358

Vaultwarden works well with a non-root user, but not by default.

Distroless images or similar solutions provide a smaller size and a minimized attack surface.

I have been learning about distroless images these days, and I created a distroless PoC. You can see it at https://github.com/hellodword/distroless-vaultwarden-test.

What do you think?

$ docker images --format "table {{.Repository}}:{{.Tag}}\t{{.Size}}"
vaultwarden/server:1.30.5                                     201MB
vaultwarden/server:1.30.5-alpine                              97.8MB
distroless-vaultwarden-test-vaultwarden:latest                93.7MB

$ trivy image --scanners vuln --ignore-unfixed vaultwarden/server:1.30.5
vaultwarden/server:1.30.5 (debian 12.5)
=======================================
Total: 84 (UNKNOWN: 0, LOW: 0, MEDIUM: 63, HIGH: 21, CRITICAL: 0)

$ trivy image --scanners vuln --ignore-unfixed vaultwarden/server:1.30.5-alpine
vaultwarden/server:1.30.5-alpine (alpine 3.19.1)
=======================================
Total: 19 (UNKNOWN: 0, LOW: 3, MEDIUM: 16, HIGH: 0, CRITICAL: 0)

$ trivy image --scanners vuln --ignore-unfixed distroless-vaultwarden-test-vaultwarden
distroless-vaultwarden-test-vaultwarden (debian 12.5)
=====================================================
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

[BlackDex]

Well comparing with Alpine 3.19 is not fair, as we already are switched to 3.20 for which the results are:
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)
So, that will match distroless.

I was planning to add an extra flavor based upon busybox, and then the musl based version.
The main reason for that is that it has a lot of tools available which almost match the GNU based tools and that should make it easy to run pre-start scripts the same as is done for the current Debian and Alpine images.

Also, your repo is empty and not accessible for the outside world.

[hellodword]

Sorry, I forgot to push the commit...

switched to 3.20

I didn't notice it, the results are pretty good.

the musl based version

The musl-based version always looks great. How about also adding a flavor to the glibc based version?

[BlackDex]

There is no real use-case for glibc actually in my opinion.
The main reason is that you then still need to copy all the libraries used for the specific databases supported and there dependencies too.

Now that does provide a better overview of which vulnerabilities there might be in there, since the fully static version kinda obscures that, but that is with all static build binaries.

Why would you like to have a glibc version of it?

[hellodword]

Why would you like to have a glibc version of it?

I might have been intimidated by issues I encountered in the past, such as DNS over TCP problems (which have since been resolved) and difficulties with static compilation. As a result, I've been avoiding using musl.

I think you're right. My avoidance has been more about personal preference than any substantial reason. I should give Alpine a try.