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

Reply via email to