Thanks for the shout out XQ! And thanks for bringing this up. Moving to a Distroless base for Go SDK images should reduce the vulnerability surface to whichever version of glibc we have packaged in .
I do have some concerns around if a user would like to extend the image (not having shells or package managers make image extensions harder) the important part for any custom Beam Go SDK image is the entry point is the container boot program. I hope to add clear documentation on at least one way of doing that before the hard Distroless switch. On Wed, Jan 24, 2024, 10:36 AM 8 Gianfortoni <8...@tokentransit.com> wrote: > Hi, > > Thanks for the tips. After talking with my team, I also realized that our > Dockerfile might not even be the same one used in your repository. > > Best, > 8 > > On Wed, Jan 24, 2024 at 12:58 PM 'XQ Hu' via Engineering < > e...@tokentransit.com> wrote: > >> FYI. The ongoing PR: https://github.com/apache/beam/pull/30011 will >> switch to the distroless images, which will have less vulnerabilities in >> the future. >> >> On Wed, Jan 24, 2024 at 12:32 PM Valentyn Tymofieiev <valen...@google.com> >> wrote: >> >>> > Does the beam project generally attempt to address as many of these >>> vulnerabilities? >>> >>> Beam does not retroactively patch released container images, but we use >>> the latest available docker base images during each Beam release. Many >>> vulnerabilities concern software packages preinstalled in the Docker base >>> layer (currently we use Debian bookworm). Such packages are not necessarily >>> used over the course of running a Beam pipeline, so some attack vectors are >>> not applicable but of course it would depend on a particular vulnerability. >>> >>> Note that Beam users can supply custom container images to use in their >>> pipeline. For example, one can create an image based on 'distroless' >>> distribution [1], which would significantly reduce the number of >>> preinstalled packages. For more information on customizing container >>> images, see [2] [3]. >>> >>> [1] ttps://github.com/GoogleContainerTools/distroless >>> [2] https://beam.apache.org/documentation/runtime/environments/ >>> [3] https://cloud.google.com/dataflow/docs/guides/build-container-image >>> >>> On Tue, Jan 23, 2024 at 1:30 PM 8 Gianfortoni <8...@tokentransit.com> >>> wrote: >>> >>>> Hi team, >>>> >>>> We recently starting using the Google Artifact Registry's container >>>> scanning, and have been able to fix almost all critical vulnerabilities >>>> across our codebase. The one exception is the docker container created when >>>> we deploy our dataflow beam jobs. >>>> >>>> The "critical" vulnerability reported is >>>> https://security-tracker.debian.org/tracker/CVE-2023-45853, and we are >>>> using Apache Beam golang v2.53.0. I cannot tell whether this is something >>>> that is even easily fixable in the docker setup or whether beam is even >>>> affected by this issue. >>>> >>>> Has anyone else run into this issue? Would a beam dataflow job actually >>>> be affected or is this more relevant for someone actually running servers >>>> on this particular version of debian? Should we just be ignoring this >>>> "critical" vulnerability since it is just in the docker container for a >>>> couple of batch jobs? Does the beam project generally attempt to address as >>>> many of these vulnerabilities? >>>> >>>> Best, >>>> 8 >>>> Token Transit >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Engineering" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to eng+unsubscr...@tokentransit.com. >> To view this discussion on the web visit >> https://groups.google.com/a/tokentransit.com/d/msgid/eng/CAO%2BjvV0vn1PZrCmJxhhci3ExL8zY3tKmeHYsDBtWhpxP44sh1A%40mail.gmail.com >> <https://groups.google.com/a/tokentransit.com/d/msgid/eng/CAO%2BjvV0vn1PZrCmJxhhci3ExL8zY3tKmeHYsDBtWhpxP44sh1A%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >
