Achieving Lightweight and Secure Container Images

[anthisfan]

Dear Community Members,

Hello.
I regularly use the fluent-bit image (https://hub.docker.com/r/fluent/fluent-bit/) for business purposes on k8s.
Thank you for your continuous support.

In the development environment, I utilize the fluent-bit:debug image, while in the production environment, I use the non-debug image.

Recently, I noticed that the fluent-bit binary included in the non-debug image is around 44MB and contains debug information.
By removing this information, the size of the fluent-bit binary can be reduced to approximately 9MB.
As a result, I expect not only a lightweight container image but also a more secure environment.

This is an extremely experimental and personal endeavor, but for example, by modifying the Dockerfile as follows and building it, we can remove the debug information. Although it's a build for x86_64, the respective results are as follows:

diff --git a/dockerfiles/Dockerfile b/dockerfiles/Dockerfile
index b1d505a15..26c07fbbb 100644
--- a/dockerfiles/Dockerfile
+++ b/dockerfiles/Dockerfile
@@ -81,6 +81,27 @@ RUN cmake -DFLB_RELEASE=On \
 RUN make -j "$(getconf _NPROCESSORS_ONLN)"
 RUN install bin/fluent-bit /fluent-bit/bin/
 
+FROM builder-base as production-builder
+WORKDIR /src/fluent-bit/build/
+RUN cmake -DFLB_RELEASE=On \
+    -DFLB_JEMALLOC=On \
+    -DFLB_TLS=On \
+    -DFLB_SHARED_LIB=Off \
+    -DFLB_EXAMPLES=Off \
+    -DFLB_HTTP_SERVER=On \
+    -DFLB_IN_EXEC=Off \
+    -DFLB_IN_SYSTEMD=On \
+    -DFLB_OUT_KAFKA=On \
+    -DFLB_OUT_PGSQL=On \
+    -DFLB_NIGHTLY_BUILD="$FLB_NIGHTLY_BUILD" \
+    -DFLB_LOG_NO_CONTROL_CHARS=On \
+    -DFLB_CHUNK_TRACE="$FLB_CHUNK_TRACE" \
+    ..
+
+RUN make -j "$(getconf _NPROCESSORS_ONLN)"
+RUN install bin/fluent-bit /fluent-bit/bin/
+RUN strip /fluent-bit/bin/fluent-bit
+
 # Configuration files
 COPY conf/fluent-bit.conf \
     conf/parsers.conf \
@@ -172,10 +193,10 @@ LABEL description="Fluent Bit multi-architecture container image" \
 COPY --from=deb-extractor /dpkg /
 
 # Copy certificates
-COPY --from=builder /etc/ssl/certs /etc/ssl/certs
+COPY --from=production-builder /etc/ssl/certs /etc/ssl/certs
 
 # Finally the binaries as most likely to change
-COPY --from=builder /fluent-bit /fluent-bit
+COPY --from=production-builder /fluent-bit /fluent-bit
 
 EXPOSE 2020

Container image size built using the unmodified Dockerfile

$ docker buildx build --target production --platform "linux/amd64" -t fluent-bit:default --load .
$ docker image ls fluent-bit:default
REPOSITORY   TAG       IMAGE ID       CREATED          SIZE
fluent-bit   default   41166986bd6f   37 minutes ago   99MB

Container image size built using the modified Dockerfile

$ docker buildx build --target production --platform "linux/amd64" -t fluent-bit:stripped --load .  
$ docker image ls fluent-bit:stripped
REPOSITORY   TAG        IMAGE ID       CREATED          SIZE
fluent-bit   stripped   e1764e884622   38 seconds ago   46.4MB

Here are the points I would like to discuss:

1. Please provide your opinion on the impact of removing debug information from the non-debug image.
2. I added the production-builder step to the Dockerfile,
   but if there is a smarter way to achieve the same process, please let me know :)
   (I am not used to this type of work and this may seem like a poor change...)

Thank you for reading this far.
Have a nice day.

[patrick-stephens]

Makes sense to me, I'd suggest submitting a PR so we can include it.
I would not use a whole separate build for production though, I'd suggest we just have a stage to strip the binary - that way we have the same binary in debug and production (just without debug info) in case there is some issue in the way it is built that changes behaviour plus it means any change to config has to be duplicated (which will probably not be done/missed) causing other deltas.

[anthisfan]

Thank you for your feedback.
I will create a PR in the near future, so please review it when the time comes :)

[anthisfan]

As there is a possibility that this could make debugging extremely difficult in a containerized operating environment, we will close this issue.
Thank you for your consideration.
#8821