I would prefer to split the alpine work from the CI improvements.

I would prefer to split the alpine work from the CI improvements.

Sure, I removed the CI improvements and only left alpine-specific changes. However, I did leave the fix for the build failure.

I meant that I want to just fix the build failure first. The. Do the alpine change separately.

I meant that I want to just fix the build failure first. The. Do the alpine change separately.

Ah okay, sure I'll create a new PR with just the build failure fix first.

Edit: Created PR #67

Can you rebase now?

I rebased my old PR (#63) to update the CircleCI config.

Thanks for this effort. The vulnerabilities here are not significant, but just having fewer helps in having more focus.

@SuperQ any other concerns/improvements for this pull request?

So, I'm not really sure what this gets us. Looking over the original issue, it's a vague "we do security better".

Building this as a separate tag is going to gain zero adoption as we're not likely to change any of the Prometheus ecosystem to use it. It just adds more things to maintain with no benefit.

Also, basically we don't care about busybox vulnerabilities in the Prometheus ecosystem. Prometheus uses statically linked Go binaries and makes no calls that require busybox. It's basically a convenience tool inside the container to make it simple to get a shell and do basic stuff.

Any vulnerability would require already being inside the container, which is already game over.

If there are no dependencies to Busybox, such as shell scripts, then would you consider having just the statically linked binary, CA and TZ data in the Prometheus container images? I can contribute here.

Minimizing the footprint would help the end-user organizations to focus on the real vulnerabilities. Organizations that do container scanning are easily overloaded by the amount of vulnerabilities. They might not have the capacity to see if each one of those is exploitable. Someone not knowing any better might see many Prometheus ecosystem images show up on their vulnerabilities radar and staying there for some time. This also becomes a problem for whoever runs their observability stack.

Yes, distroless container builds would be great. This would need to be integrated into our Prometheus Makefile.common.

Hey guys, thanks for the feedback and I have to agree that a distroless container build for prometheus would be better implementation. I have already gone ahead and created initial PR prometheus/prometheus#17680

Thanks for the work, especially the fixing of the pipeline. We now have an up-to-date upstream busybox image built.

But I think the consensus is that we want to go distroless as the best option for higher container security.