Use busybox from alpine

[liam-verta]

@SuperQ @discordianfish
I'll admit this is a little hacky, but it is sufficient.

Fixes #50

[SuperQ]

I'm wondering if we should make a new prometheus busybox:alpine, since this changes the libc.

It doesn't quite make sense to me to call it busybox:glibc if we're not actually using glibc here.

[discordianfish]

Looks like this will create an image from busybox:glibc, then copy over alpine busybox and musl which seems like fragile. Why do we still need to base this on the upstream busybox image if we replace it anyway? I'd rather to FROM scratch and copy in from alpine. But then, yes a new image tag.

[liam-verta]

@discordianfish @SuperQ
I'm trying another pass at this PR using a statically-linked busybox.

From the perspective of consumers of these images, the key features are:

• The busybox toolset
• The specified libc flavor

This is why I chose to continue to base this image on the same busybox:* images as before. Those images provide a specific libc flavor and minimal folder layout. We want to keep that.

Given that a particular libc flavor is present, it is convenient for busybox to link to those libraries, but that linkage is not a significant feature. The internal structure/linking of thebusybox toolset is an implementation detail.

Using a statically-linked busybox does have some effect, but it is not significant from a downstream user perspective. For example, static linking changes memory usage but probably not to a degree worth noting for the scenarios these tools are used in. See https://busybox.net/FAQ.html#tips_memory for discussion.

The size on of the busybox files is similar, with the statically linked alpine version being slightly smaller than the dynamic official executable:

• alpine:latest - /bin/busybox: 0.82 MB (841376 bytes)
• alpine:latest - /bin/busybox.static: 0.98 MB (1001288 bytes)
• busybox:glibc - /bin/busybox: 1.00 MB (1025504 bytes)
• busybox:uclibc - /bin/busybox: 1.13 MB (1157408 bytes)

Taking this change will improve the security profile of projects based on these images with minimal change to user facing features.

[SuperQ]

I don't think we should touch the existing package flavors. Rather, we should create a new image prom/busybox:alpine or something that is something we can transition to.

[liam-verta]

@SuperQ @discordianfish
Done. I made a new alpine-glibc and added a section to the readme.

[SuperQ]

Why not FROM scratch? If we're not going to use the busybox binary from this package, why use this as the image? All of the prometheus project binaries are static, we don't actually use glibc anymore.

Also, maybe we can simplify this to just pull the misc etc files from alpine as well, skip the debian layer as well.

[liam-verta]

I consume this image: https://hub.docker.com/r/prom/prometheus

I opened this PR to try to produce a more secure base image for that image to be based on so I (and every other consumer) don't have to repackage it for busybox security issues. I was trying to do this with the least set of changes in order to have the least risk of breakages and to respect the intent of the existing images.

As I noted above, I believe:

From the perspective of consumers of these images, the key features are:

• The busybox toolset
• The specified libc flavor

This PR provides the above with the least changes from the existing behavior.

What you're suggesting is I skip this and go make the case for prometheus scratch images. Fair enough.

[discordianfish]

Yeah I don't get why this isn't FROM scratch either. I would also assume that the final image will contain both the original busybox (in a hidden layer) as well as the new one.

[liam-verta]

@discordianfish @SuperQ
Another attempt at this, now from scratch. The final image is flat with no vestige of the non-static busybox. It also is stripped of libc-utils and apk.

I'm sure there is more that can be removed from this image, but perhaps this is good enough a first iteration?

[liam-verta]

Previous iterations were trying to not include musl-libc . In this iteration, I haven't remove it. If that is okay, then we can leave the default dynamic linked busybox.

Suggested change

	# Use the busybox.static to avoid dynamic library dependencies.
	RUN apk add busybox-static && \
	mv /bin/busybox.static /bin/busybox && \
	/bin/busybox --install -s /bin

[liam-verta]

@SuperQ @discordianfish
Ping?

[SuperQ]

This is copying everything, so, doing FROM scratch seems unnecessary. Our other images only copy over specific configuration files in order to make sure busybox is the only binary in the final image.

[liam-verta]

I'm not sure what you're asking for here.

[discordianfish]

I think what @SuperQ is suggesting is instead of removing the unneeded things in the base image and then copying everything here, we should use explicitly only COPY here what we need.
Can you only copy busybox here and then run /bin/busybox --install -s /bin in the final image?

[SuperQ]

Combine these steps to reduce layers.

[liam-verta]

We don't need to worry about these layers because the COPY on line 26 flattens all the build layers to a single layer in the final image.