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 >> >
