While the Go SDK is already default distroless, we probably should add an alias with _distroless for the Go SDK images to avoid questions like "why does Go not have a distroless image?" or avoids the incorrect assumption for users that want to ensure the property.
As for whether the distroless versions should be an additional tag, or a new "series", to me a new series winds up having the better legibility with the "latest" tag convention. If distroless were a versioned tag, we wouldn't be able to have a "latest" for the distroless series. I will note that i did receive at least one complaint from hard migrating Go to distroless, but they were quite understanding of the default security stance. And for Go there's usually nothing one needs from the container other than the bootloader, so a custom container is easy to make. On Tue, Nov 26, 2024, 7:12 AM Danny McCormick via dev <dev@beam.apache.org> wrote: > > should we / could we migrate the primary/default container to > distroless? Is this an intermediate step toward that? Or is it necessary to > maintain both and for how long? > > I think that this would be a hard migration to force on users, especially > for Python containers where there is a reasonably large gap between the > distroless + debian images we publish (I assume this is what you mean by > Hyrum's dead end?). I also do think each offers a real value prop, though, > independent of the migration cost - distroless is great for extra security > conscious users, debian is great for folks who want more things to just > work out of the box without thinking about dependencies/custom containers > too much. > > I do not think it will take much to maintain these, so I'm -1 on moving > towards a full migration/deprecation. I'd probably even be -1 on trying to > change the default, mostly because it's not obvious to me that distroless > is the better default for most users. > > On Tue, Nov 26, 2024 at 9:43 AM Kenneth Knowles <k...@apache.org> wrote: > >> +1 to the work and +1 to the use of a separate repo, given the framing >> that it is an optional variant that will have a sequence of releases in >> parallel to the primary containers. >> >> But have to ask: should we / could we migrate the primary/default >> container to distroless? Is this an intermediate step toward that? Or is it >> necessary to maintain both and for how long? (for a reason other than >> Hyrum's Dead-end, please) >> >> Kenn >> >> On Tue, Nov 26, 2024 at 9:26 AM Danny McCormick via dev < >> dev@beam.apache.org> wrote: >> >>> Thanks - I'm +1 to both doing this work and the naming convention. The >>> main naming alternative I can think of is using tags for distroless, aka >>> apache/beam_python3.9_sdk:2.61.0-distroless (and probably also >>> apache/beam_python3.9_sdk:latest-distroless), but I think that having >>> separate repos is probably a little bit cleaner for vulnerability tooling >>> and vulnerability-based policies. Overall, I don't think there's a huge >>> difference (and I've seen both approaches used), but I like the repo >>> approach a bit more. >>> >>> Thanks, >>> Danny >>> >>> On Mon, Nov 25, 2024 at 5:31 PM Damon Douglas <damondoug...@apache.org> >>> wrote: >>> >>>> Hello everyone, >>>> >>>> Work is currently underway >>>> <https://github.com/apache/beam/issues/32815> to build support for >>>> distroless >>>> container images <https://github.com/GoogleContainerTools/distroless>. >>>> The purpose of this message is to query any concerns over their naming >>>> convention, where simply "_distroless" is added as a suffix. Currently, as >>>> an example, for the Apache Beam Python 3.12 SDK, we publish >>>> apache/beam_python3.12_sdk >>>> <https://hub.docker.com/r/apache/beam_python3.12_sdk> and for Java 17, >>>> we publish apache/beam_java17_sdk >>>> <https://hub.docker.com/r/apache/beam_java17_sdk>. The distroless >>>> variants of these aforementioned will be >>>> apache/beam_python3.12_sdk_distroless and >>>> apache/beam_java17_sdk_distroless, respectively. Please let me know if you >>>> have any concerns with the following proposed distroless variants. Note >>>> that not all versions of Python and Java will be supported. >>>> >>>> apache/beam_python3.9_sdk_distroless >>>> apache/beam_python3.10_sdk_distroless >>>> apache/beam_python3.11_sdk_distroless >>>> apache/beam_python3.12_sdk_distroless >>>> apache/beam_java17_sdk_distroless >>>> apache/beam_java21_sdk_distroless >>>> >>>> Best, >>>> >>>> Damon >>>> >>>
