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