distroless-friendly image

[codefromthecrypt]

hypertrace uses schema-registry for tasks including streaming jobs and also handling internal to pinot. Right now, schema registry is managed more like a unix process than a rooted java application like Kafka. This makes making distroless images (and more importantly re-using a base layer) more difficult as we have to track and cherry-pick the various places files are written to.

[andrewegel]

By "distroless-friendly image" I'm assuming you're speaking about something this medium article is advocating:

https://medium.com/@dwdraju/distroless-is-for-security-if-not-for-size-6eac789f695f

Because if I search "distroless-friendly image", then the top result is this issue, and the second is that medium article above.

I'm not opposed to the idea, but the medium article acknowledges that: "By avoiding unnecessary stuffs on the packaged docker images, the doors for any kind of attack from inside or outside is reduced. Distroless has no package manager like apk tools in alpine, apt in ubuntu.".

Let me break something down really quick - schema-registry (and in essence this docker container) requires (at minimum):

• Java (To run the service)
• Python3 (To run confluent-docker-utils to configure the service)
• Bash (to stitch everything together)
• There are likely other dependencies in between there, like OpenSSL.

This would mean we (as vendors of this image), would need to build the above software for the docker image if we chose to go that route. That's not too hard, but what happens when there is a CVE in that software we built?

And there in lies the reason why we have chosen Redhat's UBI8 as the base image: Because those Linux OS vendors (be it Debian, Redhat, CentOS, or Canonical) take care of patching CVEs in the software we consume, and all we (the vendors) would need to do is rebuild a docker image with (almost) no changes to the Dockerfile to get that update.

What I find ironic is the medium article above advocates that its better for "security", when in fact its not in terms of upstream software vendor patching: Theres no package manager to let us consume updated fixes from a software vendor. We would have to:

• Know about the CVE
• Find the upstream software
• Find the patch
• Backport the patch if needed
• Rebuild

I'm inclined to close this issues as "non-issue, won't fix", but I'm also not familiar with "disroless images" like Alpine, so I don't know if this concern has been addressed in some way.

I'll give this another opportunity for consideration if you:

• Find a distroless base image that has all of the above requirements (Java11, Python3, Bash, etc).
• That meet our CVE tracking/patching concerns

then I would consider this as a good feature request (Because smaller images is also another goal).