You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pulsar.apache.org by Alexander Hall <ah...@teknoluxion.com.INVALID> on 2024/03/01 17:16:47 UTC
Re: [DISCUSS] PIP-324: Alpine Docker images
According to Red Hat their latest tagged release for UBI9.3, 9.3-1552, has four moderate CVE's (https://catalog.redhat.com/software/containers/ubi9/ubi/615bcf606feffc5384e8452e). There is also the option of basing the Pulsar image on the UBI9-minimal image (https://catalog.redhat.com/software/containers/ubi9/ubi-minimal/615bd9b4075b022acc111bf5). That may have a better security footprint.
Thank You,
Alex Hall
<ah...@teknoluxion.com>
-----Original Message-----
From: Matteo Merli <ma...@gmail.com>
Sent: Thursday, February 15, 2024 12:55 PM
To: dev@pulsar.apache.org
Subject: ''Re: Re: [DISCUSS] PIP-324: Alpine Docker images
[You don't often get email from matteo.merli@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
Hi Alex,
the situation for UBI9 doesn't look much different from Ubuntu:
registry.access.redhat.com/ubi9/ubi (redhat 9.3)
Total: 166 (UNKNOWN: 0, LOW: 138, MEDIUM: 28, HIGH: 0, CRITICAL: 0)
Full list: https://gist.github.com/merlimat/ba96b91ea49709bb218ddc3906bb9e95
--
Matteo Merli
<ma...@gmail.com>
On Thu, Feb 15, 2024 at 9:10 AM Alexander Hall <ah...@teknoluxion.com.invalid> wrote:
> Reviving a previous tangent from this discussion. Using UBI9 as a base
> is also a great option. Some end-users use that as a base and copy the
> files from the pulsar and pulsar-all containers as an upstream source.
>
> -Alex H
>
> -----Original Message-----
> From: Matteo Merli <ma...@gmail.com>
> Sent: Wednesday, February 14, 2024 2:01 PM
> To: david.christle@discordapp.com.invalid
> Cc: dev@pulsar.apache.org
> Subject: ''Re: Re: [DISCUSS] PIP-324: Alpine Docker images
>
> [You don't often get email from *REDACTED*. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Reviving the discussion thread.
>
>
> > For Netty, I think netty-transport-native-epoll is only built
> > against glibc (
>
> https://nett/
> y.io%2Fwiki%2Fnative-transports.html%23using-the-linux-native-transpor
> t&data=05%7C02%7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4
> f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473628082%
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=kJQqQ5o6ZnuIlqO6Chq0P0Z6axc6Ji
> WSP%2F5Qd7bN7xw%3D&reserved=0
> ).
> > Is there a workaround ?
>
> Yes, there is a workaround for Netty. It works perfectly fine by
> including the GLibc compatibility library. Same for Kinesis producer (side note:
> Kinesis SDK is the worst train wreck I've seen in many many years:
> it's a
> C++ binary that it spawned from Java and communicates through a pipe...
> anyway it works fine with the GLibc compatibility lib).
>
> > Other than that, there is the DNS caching issue Lari mentioned.
>
> I think the DNS issue was already solved a few releases ago. In any
> case, it wouldn't affect Pulsar/BK since we use the Netty DNS client.
> In the same way, I believe that JDK also doesn't use the glibc provided DNS client:
> that's why we configure the DNS cache directly in the JVM configuration.
>
> >> - Using a smaller base image like Alpine can save space. The
> >> relative
> size of the JRE image for Alpine is about 45% smaller than the
> equivalent Ubuntu slim image.
> >> - The Ubuntu image has a few tens of CVEs in it, as reported by an
> automated container CVE scan tool, compared to 0 in Alpine.
> > These seem reasonable, but the true magnitude of benefit is likely
> > lower
> in practice. The pulsar-all images are 2.7GB in size, so saving 166MB
> on the base + JRE install translates to just a 6% smaller image.
> Unless we expect other installed packages part of pulsar-all to gain
> additional space savings on Alpine, this difference seems very marginal in practice.
>
> `pulsar-all` is ready for separate discussion (I actually think we
> should discontinue that image).
>
> For `pulsar` image:
> * apache/pulsar:3.2.0 (which already does not include Presto anymore):
> 919 MB
> * alpine image wip: 505 MB
>
> There are additional ways we should explore to further reduce the
> image size (eg: removing unused JDK modules, Python packages, etc...)
>
> > Security-wise, I took a cursory look at the CVEs, and many of them
> > are in
> libraries that aren’t used in a Pulsar deployment/are difficult to
> envision a practical exploit scenario. Automated scanning tool results
> should be taken with a grain of salt - they generate a lot of alerts,
> and many public container images throw off these CVE alerts nowadays.
> The counterargument is that only a fraction of the libraries indicated
> are even loaded at runtime, only some fraction of those end up
> potentially being exploitable, and only a smaller fraction have no
> fix/workaround. This isn’t to say reducing the vulnerability surface
> by using an image with less cruft in it is not a worthwhile endeavor —
> I do think we should try to tackle it
> -- but I’m simply trying to be realistic about what our actual gains
> will be from switching to Alpine.
>
> Even though the CVEs might not be a "real" security issue, or not be
> exploitable in the context of Pulsar, it is really not how any
> security team would look at it. From their perspective, it becomes
> unmanageable to check and understand every single CVE to assess the
> potential specific threat.
>
> This is a real problem that is causing a lot of headaches to have
> Pulsar distribution taken seriously from a security posture perspective.
>
> Just have a glance at the security CVE issues in our last Pulsar
> release, released just a few days ago:
>
> apachepulsar/pulsar:3.2.0 (ubuntu 22.04)
> Total: 243 (UNKNOWN: 0, LOW: 146, MEDIUM: 93, HIGH: 4, CRITICAL: 0)
>
> Compare with Pulsar image based on Alpine:
>
> merlimat/pulsar:3.3.0-SNAPSHOT-f2a91a1 (alpine 3.19.1)
> Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)
>
> Full list here:
> https://gist/
> .github.com%2Fmerlimat%2Fee7534992b21cae0b04c8c63f64456ff&data=05%7C02
> %7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb8
> 92218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473633950%7CUnknown%7CTW
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C0%7C%7C%7C&sdata=y3NzrPg14CBnD2nsr1Devtc5w2Ki0EPKeigKRT5piMI%
> 3D&reserved=0 The above are all issues coming from Ubuntu base image.
>
> > It’s also worth mentioning we’d be moving away from other large
> open-source big data projects in a way. Spark [2], Flink [3], Kafka
> [4], Elasticsearch [5], and Trino [6] are based on Temurin/Ubuntu/ubi.
> In my brief search, I didn’t find familiar names of tools in the big
> data ecosystem with official images based on Alpine.
> > Distroless would also remove almost everything from our base images,
> minimizing space, reducing the vulnerability surface, and by
> extension, reducing the CVE alerts from automated tooling. Apache
> Druid [7] has used Distroless for a while in their official images. We
> could achieve the same aims without any risk from musl/glibc, DNS
> quirks, or other hiccups that Alpine may have.
>
>
> Regarding the OpenJDK distribution, the team from Amazon Corretto,
> publishes well tested and supported Alpine packages. See
> https://aws/.
> amazon.com%2Fcorretto&data=05%7C02%7Cahall%40teknoluxion.com%7C079cd39
> e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0%7C0%7
> C638436165473638107%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2FTa7LLrx
> LHOwdHOIjP%2BIiFON%2FEjQdTH0cTZFtFaQkgA%3D&reserved=0
>
> I have created a WIP/draft PR to show the potential changes:
> https://gith/
> ub.com%2Fapache%2Fpulsar%2Fpull%2F22054&data=05%7C02%7Cahall%40teknolu
> xion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e27223a
> 522b9791%7C0%7C0%7C638436165473641886%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7
> C&sdata=6eKLufeZ%2BsqcKJNp01PUYLYQKBLOSHGsDtbN831QQzM%3D&reserved=0
>
> The image already passes all the integration tests and has been tested
> for few weeks in a test cluster.
>
> I have pushed a Docker image for preview purposes:
> merlimat/pulsar/3.3.0-SNAPSHOT-f2a91a1
>
>
> https://hub/.
> docker.com%2Flayers%2Fmerlimat%2Fpulsar%2F3.3.0-SNAPSHOT-f2a91a1%2Fima
> ges%2Fsha256-2d94832618bf30c02baa269bdf943c8f37aa5430258b7b4018f37ed12
> 0abb17a%3Fcontext%3Dexplore&data=05%7C02%7Cahall%40teknoluxion.com%7C0
> 79cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0
> %7C0%7C638436165473645634%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=B6z5
> xdq%2FF%2BLLasB7MM1OrqupF3vqullwEjZzOQT7ekQ%3D&reserved=0
>
> Thanks,
> Matteo
>
> --
> Matteo Merli
> <ma...@gmail.com>
>
>
> On Wed, Dec 20, 2023 at 12:49 PM David Christle
> <da...@discordapp.com.invalid> wrote:
>
> > Are we sure the move to Alpine is worth the extensive performance
> > testing and the risk of issues? Sticking with a popular glibc image
> > like Temurin, Ubuntu/Debian, or ubi-minimal (mentioned also in this
> > discussion) seems like a better path to me, without the risk of
> > glibc vs musl issues. Using Distroless seems like another good
> > potential option, as it would achieve the same aims as the Alpine
> > move, with less
> potential risk.
> >
> > The DNS issues seen with Alpine are worth paying strong attention to.
> > Someone running a Pulsar deployment using the images could have a
> > very difficult time debugging library/glibc vs musl/DNS issues, due
> > to their low-level nature. A fix for the DNS issue only landed less
> > than a year ago [1]. Unless we have a compelling reason for Alpine,
> > it may be safer to wait for more adoption/testing before choosing it
> > for the
> official Pulsar images.
> >
> > The two main arguments in the PIP are:
> >
> > - Using a smaller base image like Alpine can save space. The
> > relative size of the JRE image for Alpine is about 45% smaller than
> > the equivalent Ubuntu slim image.
> >
> > - The Ubuntu image has a few tens of CVEs in it, as reported by an
> > automated container CVE scan tool, compared to 0 in Alpine.
> >
> >
> > These seem reasonable, but the true magnitude of benefit is likely
> > lower in practice. The pulsar-all images are 2.7GB in size, so
> > saving 166MB on the base + JRE install translates to just a 6% smaller image.
> > Unless we expect other installed packages part of pulsar-all to gain
> > additional space savings on Alpine, this difference seems very
> > marginal
> in practice.
> >
> > Security-wise, I took a cursory look at the CVEs, and many of them
> > are in libraries that aren’t used in a Pulsar deployment/are
> > difficult to envision a practical exploit scenario. Automated
> > scanning tool results should be taken with a grain of salt - they
> > generate a lot of alerts, and many public container images throw off these CVE alerts nowadays.
> > The counterargument is that only a fraction of the libraries
> > indicated are even loaded at runtime, only some fraction of those
> > end up potentially being exploitable, and only a smaller fraction
> > have no fix/workaround. This isn’t to say reducing the vulnerability
> > surface by using an image with less cruft in it is not a worthwhile
> > endeavor — I do think we should try to tackle it -- but I’m simply
> > trying to be realistic about what our actual gains will be from switching to Alpine.
> >
> > It’s also worth mentioning we’d be moving away from other large
> > open-source big data projects in a way. Spark [2], Flink [3], Kafka
> > [4], Elasticsearch [5], and Trino [6] are based on Temurin/Ubuntu/ubi.
> > In my brief search, I didn’t find familiar names of tools in the big
> > data ecosystem with official images based on Alpine.
> >
> > Distroless would also remove almost everything from our base images,
> > minimizing space, reducing the vulnerability surface, and by
> > extension, reducing the CVE alerts from automated tooling. Apache
> > Druid [7] has used Distroless for a while in their official images.
> > We could achieve the same aims without any risk from musl/glibc, DNS
> > quirks, or other hiccups that Alpine may have.
> >
> > Regards,
> > David
> >
> >
> > [1]
> > https://gi/
> > tlab.alpinelinux.org%2Falpine%2Ftsc%2F-%2Fissues%2F43%23note_295556&
> > data=05%7C02%7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4
> > f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0%7C0%7C63843616547365006
> > 8%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> > I6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=tvzXRU7tQWR8TkRjzKEk0PtW
> > TJj8aenzYqjDGWSok3E%3D&reserved=0
> > [2] Apache Spark - Temurin -
> > https://gi/
> > thub.com%2Fapache%2Fflink-docker%2Ftree%2Fmaster%2F1.18&data=05%7C02
> > %7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcce
> > b892218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473654182%7CUnknown%
> > 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> > JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=AUS85hOOnewk88bm7J4zDsr5F1cACzcj6ULv
> > 2%2BGGEzk%3D&reserved=0
> > [3] Apache Flink - Temurin -
> > https://gi/
> > thub.com%2Fapache%2Fflink-docker%2Ftree%2Fmaster%2F1.18&data=05%7C02
> > %7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcce
> > b892218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473658191%7CUnknown%
> > 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> > JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=L%2BUzvHzoENFmwQUeAgv0lFZlpDKIAncFu7
> > %2FA3YeQPeQ%3D&reserved=0 [4] KIP-975: Docker Image for Apache Kafka
> > - Temurin -
> >
> https://cwik/
> i.apache.org%2Fconfluence%2Fdisplay%2FKAFKA%2FKIP-975%253A%2BDocker%2B
> Image%2Bfor%2BApache%2BKafka&data=05%7C02%7Cahall%40teknoluxion.com%7C
> 079cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C
> 0%7C0%7C638436165473662148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=090
> vsrQjkBCqK%2FVoPpVbBQ9Uo4LcmxSJY1dOzsuEwCw%3D&reserved=0
> > [5] Elasticsearch - Ubuntu & ubi-minimal -
> >
> https://gith/
> ub.com%2Felastic%2Felasticsearch%2Fblob%2Fbdde29720a9e37224a90e5f186ab
> bcbc73ff9351%2Fdistribution%2Fdocker%2FREADME.md&data=05%7C02%7Cahall%
> 40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6
> f9e27223a522b9791%7C0%7C0%7C638436165473666193%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 0%7C%7C%7C&sdata=jKPpyOs5ZgrqHE5i%2FscNIDp3c8f8iXHjqsjcSgodmwQ%3D&rese
> rved=0 [6] Trino - ubi, after moving from Ubuntu -
> >
> https://hub/.
> docker.com%2Flayers%2Ftrinodb%2Ftrino%2F435%2Fimages%2Fsha256-9540a785
> c31c4ba9ad099ad99ae06ccd5ccca506e39b7d557effe1482309e05d&data=05%7C02%
> 7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb89
> 2218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473669894%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> n0%3D%7C0%7C%7C%7C&sdata=kS9hu%2FXVA4fHP3dL23LBQ1yY5rzIvPZ40V73UBbN7cA
> %3D&reserved=0
> > [7] Apache Druid - Distroless -
> >
> https://gith/
> ub.com%2Fapache%2Fdruid%2Fblob%2Fe373f6269251655f5be93ce895aee8dee8cc6
> 7dd%2Fdistribution%2Fdocker%2FDockerfile%23L4&data=05%7C02%7Cahall%40t
> eknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e
> 27223a522b9791%7C0%7C0%7C638436165473676661%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> C%7C%7C&sdata=xqjkAQD0%2FQM%2BQ%2BWc1Gfs6KQ%2FOm1RsGeKfaYijvc2ogg%3D&r
> eserved=0
> >
> >
> > On 2023/12/13 17:06:12 Matteo Merli wrote:
> > > I don't think the compatibility for downstream users is going to
> > > be a big
> > > problem:
> > > 1. Most users don't need to modify the Pulsar image in
> > > significant way 2. If they do, they won't be using the "latest"
> > > tag, but rather a
> > specific
> > > version
> > > 3. Users who are dependent on the Ubuntu base image can stay on
> > > the
> > > 3.0 LTS release branch for the entire LTS lifespan
> > >
> > > I would avoid supporting 2 images at the same time because it
> > > would make
> > it
> > > very hard to properly test them both.
> > >
> > >
> > > --
> > > Matteo Merli
> > > <mm...@apache.org>
> > >
> > >
> > > On Tue, Dec 12, 2023 at 8:57 PM Zixuan Liu <zi...@apache.org> wrote:
> > >
> > > > +1.
> > > >
> > > > It is a good idea to use the Alpine image to run the Pulsar, as
> > > > it is
> > more
> > > > secure.
> > > >
> > > > However, switching images may affect downstream users, and I am
> > wondering
> > > > if it is possible to provide multiple docker tags:
> > > > - latest: using the Ubuntu image
> > > > - alpine: using the Alpine image
> > > >
> > > > Thanks,
> > > > Zixuan
> > > >
> > > > Yunze Xu <xy...@apache.org> 于2023年12月13日周三 12:24写道：
> > > >
> > > > > +1 to me. The Alpine Linux is much more light-weight than Ubuntu.
> > > > >
> > > > > Thanks,
> > > > > Yunze
> > > > >
> > > > > On Wed, Dec 13, 2023 at 3:00 AM Matteo Merli
> > > > > <mm...@apache.org>
> > wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I've created a new proposal to switch Pulsar base docker
> > > > > > images
> > from
> > > > > Ubuntu
> > > > > > to Alpine Linux.
> > > > > >
> > > > > > Details and motivation in the PIP:
> > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A
> > > > > > %2F%2Fgithub.com%2Fapache%2Fpulsar%2Fpull%2F21716&data=05%7C
> > > > > > 02%7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f5
> > > > > > 3d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0%7C0%7C63843616547
> > > > > > 3681456%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> > > > > > V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=B0
> > > > > > vOlZVAdBUQV3qdkxAIJe5G4OLQsnCAkntD1tsSEVk%3D&reserved=0
> > > > > >
> > > > > > Matteo
> > > > > >
> > > > > > --
> > > > > > Matteo Merli
> > > > > > <mm...@apache.org>
> > > > >
> > > >
> > >
>
Re: [DISCUSS] PIP-324: Alpine Docker images
Posted by Matteo Merli <ma...@gmail.com>.
Since the discussion has been open for a while now, I will proceed to a
vote.
Thanks everyone for bringing out all the perspectives here.
Matteo
--
Matteo Merli
<ma...@gmail.com>
On Fri, Mar 1, 2024 at 10:17 AM Alexander Hall
<ah...@teknoluxion.com.invalid> wrote:
> Matteo,
>
> Yes, I'm seeing a similar number of vulnerabilities with Stackrox. It's
> important to point out that most of the vulnerabilities are of a low
> severity, with 22 of them being moderate. Neither Trivy nor Stackrox found
> any vulnerabilities of an important or critical severity. That's a good
> thing.
>
> (TOTAL-COMPONENTS: 41, TOTAL-VULNERABILITIES: 165, LOW: 143, MODERATE: 22,
> IMPORTANT: 0, CRITICAL: 0)
> https://gist.github.com/compuguy/984697f779ec2be2e71f9b3c89db39ae
>
> Thanks,
>
> Alex Hall
> <ah...@teknoluxion.com>
>
> -----Original Message-----
> From: Matteo Merli <ma...@gmail.com>
> Sent: Friday, March 1, 2024 12:31 PM
> To: dev@pulsar.apache.org
> Subject: Re: [DISCUSS] PIP-324: Alpine Docker images
>
> [You don't often get email from *REDACTED*. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi Alexander,
>
> it doesn't look to be only 4 issues in that image:
>
>
> https://catalog.redhat.com/software/containers/ubi9/ubi/615bcf606feffc5384e8452e
> points to this Docker image
>
>
> registry.access.redhat.com/ubi9/ubi@sha256:1fafb0905264413501df60d90a92ca32df8a2011cbfb4876ddff5ceb20c8f165
> (redhat 9.3)
> Total: 172 (UNKNOWN: 0, LOW: 144, MEDIUM: 28, HIGH: 0, CRITICAL: 0)
>
> Full list:
> https://gist.github.com/merlimat/a4fcea7336cab83ad64dcf01d9b15a1c
> --
> Matteo Merli
> <ma...@gmail.com>
>
>
> On Fri, Mar 1, 2024 at 9:19 AM Alexander Hall
> <ah...@teknoluxion.com.invalid>
> wrote:
>
> > According to Red Hat their latest tagged release for UBI9.3, 9.3-1552,
> has
> > four moderate CVE's (
> >
> https://catalog.redhat.com/software/containers/ubi9/ubi/615bcf606feffc5384e8452e
> ).
> > There is also the option of basing the Pulsar image on the UBI9-minimal
> > image (
> >
> https://catalog.redhat.com/software/containers/ubi9/ubi-minimal/615bd9b4075b022acc111bf5
> ).
> > That may have a better security footprint.
> >
> > Thank You,
> >
> > Alex Hall
> > <ah...@teknoluxion.com>
> >
> > -----Original Message-----
> > From: Matteo Merli <ma...@gmail.com>
> > Sent: Thursday, February 15, 2024 12:55 PM
> > To: dev@pulsar.apache.org
> > Subject: ''Re: Re: [DISCUSS] PIP-324: Alpine Docker images
> >
> > [You don't often get email from *REDACTED*. Learn why this is
> > important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > Hi Alex,
> >
> > the situation for UBI9 doesn't look much different from Ubuntu:
> >
> > registry.access.redhat.com/ubi9/ubi (redhat 9.3)
> > Total: 166 (UNKNOWN: 0, LOW: 138, MEDIUM: 28, HIGH: 0, CRITICAL: 0)
> >
> > Full list:
> > https://gist.github.com/merlimat/ba96b91ea49709bb218ddc3906bb9e95>
> >
> > --
> > Matteo Merli
> > <ma...@gmail.com>
> >
> >
> > On Thu, Feb 15, 2024 at 9:10 AM Alexander Hall
> > <ah...@teknoluxion.com.invalid> wrote:
> >
> > > Reviving a previous tangent from this discussion. Using UBI9 as a base
> > > is also a great option. Some end-users use that as a base and copy the
> > > files from the pulsar and pulsar-all containers as an upstream source.
> > >
> > > -Alex H
> > >
> > > -----Original Message-----
> > > From: Matteo Merli <ma...@gmail.com>
> > > Sent: Wednesday, February 14, 2024 2:01 PM
> > > To: david.christle@discordapp.com.invalid
> > > Cc: dev@pulsar.apache.org
> > > Subject: ''Re: Re: [DISCUSS] PIP-324: Alpine Docker images
> > >
> > > [You don't often get email from *REDACTED*. Learn why this is
> > > important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > Reviving the discussion thread.
> > >
> > >
> > > > For Netty, I think netty-transport-native-epoll is only built
> > > > against glibc (
> > >
> > > https://nett/
> > > y.io%2Fwiki%2Fnative-transports.html%23using-the-linux-native-transpor
> > > t&data=05%7C02%7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4
> > > f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473628082%
> > > 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> > > 1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=kJQqQ5o6ZnuIlqO6Chq0P0Z6axc6Ji
> > > WSP%2F5Qd7bN7xw%3D&reserved=0
> > > ).
> > > > Is there a workaround ?
> > >
> > > Yes, there is a workaround for Netty. It works perfectly fine by
> > > including the GLibc compatibility library. Same for Kinesis producer
> > (side note:
> > > Kinesis SDK is the worst train wreck I've seen in many many years:
> > > it's a
> > > C++ binary that it spawned from Java and communicates through a pipe...
> > > anyway it works fine with the GLibc compatibility lib).
> > >
> > > > Other than that, there is the DNS caching issue Lari mentioned.
> > >
> > > I think the DNS issue was already solved a few releases ago. In any
> > > case, it wouldn't affect Pulsar/BK since we use the Netty DNS client.
> > > In the same way, I believe that JDK also doesn't use the glibc provided
> > DNS client:
> > > that's why we configure the DNS cache directly in the JVM
> configuration.
> > >
> > > >> - Using a smaller base image like Alpine can save space. The
> > > >> relative
> > > size of the JRE image for Alpine is about 45% smaller than the
> > > equivalent Ubuntu slim image.
> > > >> - The Ubuntu image has a few tens of CVEs in it, as reported by an
> > > automated container CVE scan tool, compared to 0 in Alpine.
> > > > These seem reasonable, but the true magnitude of benefit is likely
> > > > lower
> > > in practice. The pulsar-all images are 2.7GB in size, so saving 166MB
> > > on the base + JRE install translates to just a 6% smaller image.
> > > Unless we expect other installed packages part of pulsar-all to gain
> > > additional space savings on Alpine, this difference seems very marginal
> > in practice.
> > >
> > > `pulsar-all` is ready for separate discussion (I actually think we
> > > should discontinue that image).
> > >
> > > For `pulsar` image:
> > > * apache/pulsar:3.2.0 (which already does not include Presto anymore):
> > > 919 MB
> > > * alpine image wip: 505 MB
> > >
> > > There are additional ways we should explore to further reduce the
> > > image size (eg: removing unused JDK modules, Python packages, etc...)
> > >
> > > > Security-wise, I took a cursory look at the CVEs, and many of them
> > > > are in
> > > libraries that aren’t used in a Pulsar deployment/are difficult to
> > > envision a practical exploit scenario. Automated scanning tool results
> > > should be taken with a grain of salt - they generate a lot of alerts,
> > > and many public container images throw off these CVE alerts nowadays.
> > > The counterargument is that only a fraction of the libraries indicated
> > > are even loaded at runtime, only some fraction of those end up
> > > potentially being exploitable, and only a smaller fraction have no
> > > fix/workaround. This isn’t to say reducing the vulnerability surface
> > > by using an image with less cruft in it is not a worthwhile endeavor —
> > > I do think we should try to tackle it
> > > -- but I’m simply trying to be realistic about what our actual gains
> > > will be from switching to Alpine.
> > >
> > > Even though the CVEs might not be a "real" security issue, or not be
> > > exploitable in the context of Pulsar, it is really not how any
> > > security team would look at it. From their perspective, it becomes
> > > unmanageable to check and understand every single CVE to assess the
> > > potential specific threat.
> > >
> > > This is a real problem that is causing a lot of headaches to have
> > > Pulsar distribution taken seriously from a security posture
> perspective.
> > >
> > > Just have a glance at the security CVE issues in our last Pulsar
> > > release, released just a few days ago:
> > >
> > > apachepulsar/pulsar:3.2.0 (ubuntu 22.04)
> > > Total: 243 (UNKNOWN: 0, LOW: 146, MEDIUM: 93, HIGH: 4, CRITICAL: 0)
> > >
> > > Compare with Pulsar image based on Alpine:
> > >
> > > merlimat/pulsar:3.3.0-SNAPSHOT-f2a91a1 (alpine 3.19.1)
> > > Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)
> > >
> > > Full list here:
> > > https://gist/
> > > .github.com%2Fmerlimat%2Fee7534992b21cae0b04c8c63f64456ff&data=05%7C02
> > > %7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb8
> > > 92218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473633950%7CUnknown%7CTW
> > > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> > > Mn0%3D%7C0%7C%7C%7C&sdata=y3NzrPg14CBnD2nsr1Devtc5w2Ki0EPKeigKRT5piMI%
> > > 3D&reserved=0 The above are all issues coming from Ubuntu base image.
> > >
> > > > It’s also worth mentioning we’d be moving away from other large
> > > open-source big data projects in a way. Spark [2], Flink [3], Kafka
> > > [4], Elasticsearch [5], and Trino [6] are based on Temurin/Ubuntu/ubi.
> > > In my brief search, I didn’t find familiar names of tools in the big
> > > data ecosystem with official images based on Alpine.
> > > > Distroless would also remove almost everything from our base images,
> > > minimizing space, reducing the vulnerability surface, and by
> > > extension, reducing the CVE alerts from automated tooling. Apache
> > > Druid [7] has used Distroless for a while in their official images. We
> > > could achieve the same aims without any risk from musl/glibc, DNS
> > > quirks, or other hiccups that Alpine may have.
> > >
> > >
> > > Regarding the OpenJDK distribution, the team from Amazon Corretto,
> > > publishes well tested and supported Alpine packages. See
> > > https://aws/.
> > > amazon.com%2Fcorretto&data=05%7C02%7Cahall%40teknoluxion.com%7C079cd39
> > > e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0%7C0%7
> > > C638436165473638107%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> > > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2FTa7LLrx
> > > LHOwdHOIjP%2BIiFON%2FEjQdTH0cTZFtFaQkgA%3D&reserved=0
> > >
> > > I have created a WIP/draft PR to show the potential changes:
> > > https://gith/
> > > ub.com%2Fapache%2Fpulsar%2Fpull%2F22054&data=05%7C02%7Cahall%40teknolu
> > > xion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e27223a
> > > 522b9791%7C0%7C0%7C638436165473641886%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> > > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7
> > > C&sdata=6eKLufeZ%2BsqcKJNp01PUYLYQKBLOSHGsDtbN831QQzM%3D&reserved=0
> > >
> > > The image already passes all the integration tests and has been tested
> > > for few weeks in a test cluster.
> > >
> > > I have pushed a Docker image for preview purposes:
> > > merlimat/pulsar/3.3.0-SNAPSHOT-f2a91a1
> > >
> > >
> > > https://hub/.
> > > docker.com%2Flayers%2Fmerlimat%2Fpulsar%2F3.3.0-SNAPSHOT-f2a91a1%2Fima
> > > ges%2Fsha256-2d94832618bf30c02baa269bdf943c8f37aa5430258b7b4018f37ed12
> > > 0abb17a%3Fcontext%3Dexplore&data=05%7C02%7Cahall%40teknoluxion.com%7C0
> > > 79cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0
> > > %7C0%7C638436165473645634%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> > > LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=B6z5
> > > xdq%2FF%2BLLasB7MM1OrqupF3vqullwEjZzOQT7ekQ%3D&reserved=0
> > >
> > > Thanks,
> > > Matteo
> > >
> > > --
> > > Matteo Merli
> > > <ma...@gmail.com>
> > >
> > >
> > > On Wed, Dec 20, 2023 at 12:49 PM David Christle
> > > <da...@discordapp.com.invalid> wrote:
> > >
> > > > Are we sure the move to Alpine is worth the extensive performance
> > > > testing and the risk of issues? Sticking with a popular glibc image
> > > > like Temurin, Ubuntu/Debian, or ubi-minimal (mentioned also in this
> > > > discussion) seems like a better path to me, without the risk of
> > > > glibc vs musl issues. Using Distroless seems like another good
> > > > potential option, as it would achieve the same aims as the Alpine
> > > > move, with less
> > > potential risk.
> > > >
> > > > The DNS issues seen with Alpine are worth paying strong attention to.
> > > > Someone running a Pulsar deployment using the images could have a
> > > > very difficult time debugging library/glibc vs musl/DNS issues, due
> > > > to their low-level nature. A fix for the DNS issue only landed less
> > > > than a year ago [1]. Unless we have a compelling reason for Alpine,
> > > > it may be safer to wait for more adoption/testing before choosing it
> > > > for the
> > > official Pulsar images.
> > > >
> > > > The two main arguments in the PIP are:
> > > >
> > > > - Using a smaller base image like Alpine can save space. The
> > > > relative size of the JRE image for Alpine is about 45% smaller than
> > > > the equivalent Ubuntu slim image.
> > > >
> > > > - The Ubuntu image has a few tens of CVEs in it, as reported by an
> > > > automated container CVE scan tool, compared to 0 in Alpine.
> > > >
> > > >
> > > > These seem reasonable, but the true magnitude of benefit is likely
> > > > lower in practice. The pulsar-all images are 2.7GB in size, so
> > > > saving 166MB on the base + JRE install translates to just a 6%
> smaller
> > image.
> > > > Unless we expect other installed packages part of pulsar-all to gain
> > > > additional space savings on Alpine, this difference seems very
> > > > marginal
> > > in practice.
> > > >
> > > > Security-wise, I took a cursory look at the CVEs, and many of them
> > > > are in libraries that aren’t used in a Pulsar deployment/are
> > > > difficult to envision a practical exploit scenario. Automated
> > > > scanning tool results should be taken with a grain of salt - they
> > > > generate a lot of alerts, and many public container images throw off
> > these CVE alerts nowadays.
> > > > The counterargument is that only a fraction of the libraries
> > > > indicated are even loaded at runtime, only some fraction of those
> > > > end up potentially being exploitable, and only a smaller fraction
> > > > have no fix/workaround. This isn’t to say reducing the vulnerability
> > > > surface by using an image with less cruft in it is not a worthwhile
> > > > endeavor — I do think we should try to tackle it -- but I’m simply
> > > > trying to be realistic about what our actual gains will be from
> > switching to Alpine.
> > > >
> > > > It’s also worth mentioning we’d be moving away from other large
> > > > open-source big data projects in a way. Spark [2], Flink [3], Kafka
> > > > [4], Elasticsearch [5], and Trino [6] are based on
> Temurin/Ubuntu/ubi.
> > > > In my brief search, I didn’t find familiar names of tools in the big
> > > > data ecosystem with official images based on Alpine.
> > > >
> > > > Distroless would also remove almost everything from our base images,
> > > > minimizing space, reducing the vulnerability surface, and by
> > > > extension, reducing the CVE alerts from automated tooling. Apache
> > > > Druid [7] has used Distroless for a while in their official images.
> > > > We could achieve the same aims without any risk from musl/glibc, DNS
> > > > quirks, or other hiccups that Alpine may have.
> > > >
> > > > Regards,
> > > > David
> > > >
> > > >
> > > > [1]
> > > > https://gi/
> > > > tlab.alpinelinux.org%2Falpine%2Ftsc%2F-%2Fissues%2F43%23note_295556&
> > > > data=05%7C02%7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4
> > > > f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0%7C0%7C63843616547365006
> > > > 8%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> > > > I6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=tvzXRU7tQWR8TkRjzKEk0PtW
> > > > TJj8aenzYqjDGWSok3E%3D&reserved=0
> > > > [2] Apache Spark - Temurin -
> > > > https://gi/
> > > > thub.com%2Fapache%2Fflink-docker%2Ftree%2Fmaster%2F1.18&data=05%7C02
> > > > %7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcce
> > > > b892218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473654182%7CUnknown%
> > > > 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> > > > JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=AUS85hOOnewk88bm7J4zDsr5F1cACzcj6ULv
> > > > 2%2BGGEzk%3D&reserved=0
> > > > [3] Apache Flink - Temurin -
> > > > https://gi/
> > > > thub.com%2Fapache%2Fflink-docker%2Ftree%2Fmaster%2F1.18&data=05%7C02
> > > > %7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcce
> > > > b892218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473658191%7CUnknown%
> > > > 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> > > > JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=L%2BUzvHzoENFmwQUeAgv0lFZlpDKIAncFu7
> > > > %2FA3YeQPeQ%3D&reserved=0 [4] KIP-975: Docker Image for Apache Kafka
> > > > - Temurin -
> > > >
> > > https://cwik/
> > > i.apache.org%2Fconfluence%2Fdisplay%2FKAFKA%2FKIP-975%253A%2BDocker%2B
> > > Image%2Bfor%2BApache%2BKafka&data=05%7C02%7Cahall%40teknoluxion.com%7C
> > > 079cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C
> > > 0%7C0%7C638436165473662148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> > > iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=090
> > > vsrQjkBCqK%2FVoPpVbBQ9Uo4LcmxSJY1dOzsuEwCw%3D&reserved=0
> > > > [5] Elasticsearch - Ubuntu & ubi-minimal -
> > > >
> > > https://gith/
> > > ub.com%2Felastic%2Felasticsearch%2Fblob%2Fbdde29720a9e37224a90e5f186ab
> > > bcbc73ff9351%2Fdistribution%2Fdocker%2FREADME.md&data=05%7C02%7Cahall%
> > > 40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6
> > > f9e27223a522b9791%7C0%7C0%7C638436165473666193%7CUnknown%7CTWFpbGZsb3d
> > > 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> > > 0%7C%7C%7C&sdata=jKPpyOs5ZgrqHE5i%2FscNIDp3c8f8iXHjqsjcSgodmwQ%3D&rese
> > > rved=0 [6] Trino - ubi, after moving from Ubuntu -
> > > >
> > > https://hub/.
> > > docker.com%2Flayers%2Ftrinodb%2Ftrino%2F435%2Fimages%2Fsha256-9540a785
> > > c31c4ba9ad099ad99ae06ccd5ccca506e39b7d557effe1482309e05d&data=05%7C02%
> > > 7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb89
> > > 2218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473669894%7CUnknown%7CTWF
> > > pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> > > n0%3D%7C0%7C%7C%7C&sdata=kS9hu%2FXVA4fHP3dL23LBQ1yY5rzIvPZ40V73UBbN7cA
> > > %3D&reserved=0
> > > > [7] Apache Druid - Distroless -
> > > >
> > > https://gith/
> > > ub.com%2Fapache%2Fdruid%2Fblob%2Fe373f6269251655f5be93ce895aee8dee8cc6
> > > 7dd%2Fdistribution%2Fdocker%2FDockerfile%23L4&data=05%7C02%7Cahall%40t
> > > eknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e
> > > 27223a522b9791%7C0%7C0%7C638436165473676661%7CUnknown%7CTWFpbGZsb3d8ey
> > > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> > > C%7C%7C&sdata=xqjkAQD0%2FQM%2BQ%2BWc1Gfs6KQ%2FOm1RsGeKfaYijvc2ogg%3D&r
> > > eserved=0
> > > >
> > > >
> > > > On 2023/12/13 17:06:12 Matteo Merli wrote:
> > > > > I don't think the compatibility for downstream users is going to
> > > > > be a big
> > > > > problem:
> > > > > 1. Most users don't need to modify the Pulsar image in
> > > > > significant way 2. If they do, they won't be using the "latest"
> > > > > tag, but rather a
> > > > specific
> > > > > version
> > > > > 3. Users who are dependent on the Ubuntu base image can stay on
> > > > > the
> > > > > 3.0 LTS release branch for the entire LTS lifespan
> > > > >
> > > > > I would avoid supporting 2 images at the same time because it
> > > > > would make
> > > > it
> > > > > very hard to properly test them both.
> > > > >
> > > > >
> > > > > --
> > > > > Matteo Merli
> > > > > <mm...@apache.org>
> > > > >
> > > > >
> > > > > On Tue, Dec 12, 2023 at 8:57 PM Zixuan Liu <zi...@apache.org>
> wrote:
> > > > >
> > > > > > +1.
> > > > > >
> > > > > > It is a good idea to use the Alpine image to run the Pulsar, as
> > > > > > it is
> > > > more
> > > > > > secure.
> > > > > >
> > > > > > However, switching images may affect downstream users, and I am
> > > > wondering
> > > > > > if it is possible to provide multiple docker tags:
> > > > > > - latest: using the Ubuntu image
> > > > > > - alpine: using the Alpine image
> > > > > >
> > > > > > Thanks,
> > > > > > Zixuan
> > > > > >
> > > > > > Yunze Xu <xy...@apache.org> 于2023年12月13日周三 12:24写道：
> > > > > >
> > > > > > > +1 to me. The Alpine Linux is much more light-weight than
> Ubuntu.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Yunze
> > > > > > >
> > > > > > > On Wed, Dec 13, 2023 at 3:00 AM Matteo Merli
> > > > > > > <mm...@apache.org>
> > > > wrote:
> > > > > > > >
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > I've created a new proposal to switch Pulsar base docker
> > > > > > > > images
> > > > from
> > > > > > > Ubuntu
> > > > > > > > to Alpine Linux.
> > > > > > > >
> > > > > > > > Details and motivation in the PIP:
> > > > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A
> > > > > > > > %2F%2Fgithub.com%2Fapache%2Fpulsar%2Fpull%2F21716&data=05%7C
> > > > > > > > 02%7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f5
> > > > > > > > 3d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0%7C0%7C63843616547
> > > > > > > > 3681456%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> > > > > > > > V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=B0
> > > > > > > > vOlZVAdBUQV3qdkxAIJe5G4OLQsnCAkntD1tsSEVk%3D&reserved=0
> > > > > > > >
> > > > > > > > Matteo
> > > > > > > >
> > > > > > > > --
> > > > > > > > Matteo Merli
> > > > > > > > <mm...@apache.org>
> > > > > > >
> > > > > >
> > > > >
> > >
> >
>
Re: [DISCUSS] PIP-324: Alpine Docker images
Posted by Alexander Hall <ah...@teknoluxion.com.INVALID>.
Matteo,
Yes, I'm seeing a similar number of vulnerabilities with Stackrox. It's important to point out that most of the vulnerabilities are of a low severity, with 22 of them being moderate. Neither Trivy nor Stackrox found any vulnerabilities of an important or critical severity. That's a good thing.
(TOTAL-COMPONENTS: 41, TOTAL-VULNERABILITIES: 165, LOW: 143, MODERATE: 22, IMPORTANT: 0, CRITICAL: 0)
https://gist.github.com/compuguy/984697f779ec2be2e71f9b3c89db39ae
Thanks,
Alex Hall
<ah...@teknoluxion.com>
-----Original Message-----
From: Matteo Merli <ma...@gmail.com>
Sent: Friday, March 1, 2024 12:31 PM
To: dev@pulsar.apache.org
Subject: Re: [DISCUSS] PIP-324: Alpine Docker images
[You don't often get email from *REDACTED*. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
Hi Alexander,
it doesn't look to be only 4 issues in that image:
https://catalog.redhat.com/software/containers/ubi9/ubi/615bcf606feffc5384e8452e
points to this Docker image
registry.access.redhat.com/ubi9/ubi@sha256:1fafb0905264413501df60d90a92ca32df8a2011cbfb4876ddff5ceb20c8f165
(redhat 9.3)
Total: 172 (UNKNOWN: 0, LOW: 144, MEDIUM: 28, HIGH: 0, CRITICAL: 0)
Full list: https://gist.github.com/merlimat/a4fcea7336cab83ad64dcf01d9b15a1c
--
Matteo Merli
<ma...@gmail.com>
On Fri, Mar 1, 2024 at 9:19 AM Alexander Hall <ah...@teknoluxion.com.invalid>
wrote:
> According to Red Hat their latest tagged release for UBI9.3, 9.3-1552, has
> four moderate CVE's (
> https://catalog.redhat.com/software/containers/ubi9/ubi/615bcf606feffc5384e8452e).
> There is also the option of basing the Pulsar image on the UBI9-minimal
> image (
> https://catalog.redhat.com/software/containers/ubi9/ubi-minimal/615bd9b4075b022acc111bf5).
> That may have a better security footprint.
>
> Thank You,
>
> Alex Hall
> <ah...@teknoluxion.com>
>
> -----Original Message-----
> From: Matteo Merli <ma...@gmail.com>
> Sent: Thursday, February 15, 2024 12:55 PM
> To: dev@pulsar.apache.org
> Subject: ''Re: Re: [DISCUSS] PIP-324: Alpine Docker images
>
> [You don't often get email from *REDACTED*. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi Alex,
>
> the situation for UBI9 doesn't look much different from Ubuntu:
>
> registry.access.redhat.com/ubi9/ubi (redhat 9.3)
> Total: 166 (UNKNOWN: 0, LOW: 138, MEDIUM: 28, HIGH: 0, CRITICAL: 0)
>
> Full list:
> https://gist.github.com/merlimat/ba96b91ea49709bb218ddc3906bb9e95>
>
> --
> Matteo Merli
> <ma...@gmail.com>
>
>
> On Thu, Feb 15, 2024 at 9:10 AM Alexander Hall
> <ah...@teknoluxion.com.invalid> wrote:
>
> > Reviving a previous tangent from this discussion. Using UBI9 as a base
> > is also a great option. Some end-users use that as a base and copy the
> > files from the pulsar and pulsar-all containers as an upstream source.
> >
> > -Alex H
> >
> > -----Original Message-----
> > From: Matteo Merli <ma...@gmail.com>
> > Sent: Wednesday, February 14, 2024 2:01 PM
> > To: david.christle@discordapp.com.invalid
> > Cc: dev@pulsar.apache.org
> > Subject: ''Re: Re: [DISCUSS] PIP-324: Alpine Docker images
> >
> > [You don't often get email from *REDACTED*. Learn why this is
> > important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > Reviving the discussion thread.
> >
> >
> > > For Netty, I think netty-transport-native-epoll is only built
> > > against glibc (
> >
> > https://nett/
> > y.io%2Fwiki%2Fnative-transports.html%23using-the-linux-native-transpor
> > t&data=05%7C02%7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4
> > f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473628082%
> > 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> > 1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=kJQqQ5o6ZnuIlqO6Chq0P0Z6axc6Ji
> > WSP%2F5Qd7bN7xw%3D&reserved=0
> > ).
> > > Is there a workaround ?
> >
> > Yes, there is a workaround for Netty. It works perfectly fine by
> > including the GLibc compatibility library. Same for Kinesis producer
> (side note:
> > Kinesis SDK is the worst train wreck I've seen in many many years:
> > it's a
> > C++ binary that it spawned from Java and communicates through a pipe...
> > anyway it works fine with the GLibc compatibility lib).
> >
> > > Other than that, there is the DNS caching issue Lari mentioned.
> >
> > I think the DNS issue was already solved a few releases ago. In any
> > case, it wouldn't affect Pulsar/BK since we use the Netty DNS client.
> > In the same way, I believe that JDK also doesn't use the glibc provided
> DNS client:
> > that's why we configure the DNS cache directly in the JVM configuration.
> >
> > >> - Using a smaller base image like Alpine can save space. The
> > >> relative
> > size of the JRE image for Alpine is about 45% smaller than the
> > equivalent Ubuntu slim image.
> > >> - The Ubuntu image has a few tens of CVEs in it, as reported by an
> > automated container CVE scan tool, compared to 0 in Alpine.
> > > These seem reasonable, but the true magnitude of benefit is likely
> > > lower
> > in practice. The pulsar-all images are 2.7GB in size, so saving 166MB
> > on the base + JRE install translates to just a 6% smaller image.
> > Unless we expect other installed packages part of pulsar-all to gain
> > additional space savings on Alpine, this difference seems very marginal
> in practice.
> >
> > `pulsar-all` is ready for separate discussion (I actually think we
> > should discontinue that image).
> >
> > For `pulsar` image:
> > * apache/pulsar:3.2.0 (which already does not include Presto anymore):
> > 919 MB
> > * alpine image wip: 505 MB
> >
> > There are additional ways we should explore to further reduce the
> > image size (eg: removing unused JDK modules, Python packages, etc...)
> >
> > > Security-wise, I took a cursory look at the CVEs, and many of them
> > > are in
> > libraries that aren’t used in a Pulsar deployment/are difficult to
> > envision a practical exploit scenario. Automated scanning tool results
> > should be taken with a grain of salt - they generate a lot of alerts,
> > and many public container images throw off these CVE alerts nowadays.
> > The counterargument is that only a fraction of the libraries indicated
> > are even loaded at runtime, only some fraction of those end up
> > potentially being exploitable, and only a smaller fraction have no
> > fix/workaround. This isn’t to say reducing the vulnerability surface
> > by using an image with less cruft in it is not a worthwhile endeavor —
> > I do think we should try to tackle it
> > -- but I’m simply trying to be realistic about what our actual gains
> > will be from switching to Alpine.
> >
> > Even though the CVEs might not be a "real" security issue, or not be
> > exploitable in the context of Pulsar, it is really not how any
> > security team would look at it. From their perspective, it becomes
> > unmanageable to check and understand every single CVE to assess the
> > potential specific threat.
> >
> > This is a real problem that is causing a lot of headaches to have
> > Pulsar distribution taken seriously from a security posture perspective.
> >
> > Just have a glance at the security CVE issues in our last Pulsar
> > release, released just a few days ago:
> >
> > apachepulsar/pulsar:3.2.0 (ubuntu 22.04)
> > Total: 243 (UNKNOWN: 0, LOW: 146, MEDIUM: 93, HIGH: 4, CRITICAL: 0)
> >
> > Compare with Pulsar image based on Alpine:
> >
> > merlimat/pulsar:3.3.0-SNAPSHOT-f2a91a1 (alpine 3.19.1)
> > Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)
> >
> > Full list here:
> > https://gist/
> > .github.com%2Fmerlimat%2Fee7534992b21cae0b04c8c63f64456ff&data=05%7C02
> > %7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb8
> > 92218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473633950%7CUnknown%7CTW
> > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> > Mn0%3D%7C0%7C%7C%7C&sdata=y3NzrPg14CBnD2nsr1Devtc5w2Ki0EPKeigKRT5piMI%
> > 3D&reserved=0 The above are all issues coming from Ubuntu base image.
> >
> > > It’s also worth mentioning we’d be moving away from other large
> > open-source big data projects in a way. Spark [2], Flink [3], Kafka
> > [4], Elasticsearch [5], and Trino [6] are based on Temurin/Ubuntu/ubi.
> > In my brief search, I didn’t find familiar names of tools in the big
> > data ecosystem with official images based on Alpine.
> > > Distroless would also remove almost everything from our base images,
> > minimizing space, reducing the vulnerability surface, and by
> > extension, reducing the CVE alerts from automated tooling. Apache
> > Druid [7] has used Distroless for a while in their official images. We
> > could achieve the same aims without any risk from musl/glibc, DNS
> > quirks, or other hiccups that Alpine may have.
> >
> >
> > Regarding the OpenJDK distribution, the team from Amazon Corretto,
> > publishes well tested and supported Alpine packages. See
> > https://aws/.
> > amazon.com%2Fcorretto&data=05%7C02%7Cahall%40teknoluxion.com%7C079cd39
> > e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0%7C0%7
> > C638436165473638107%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2FTa7LLrx
> > LHOwdHOIjP%2BIiFON%2FEjQdTH0cTZFtFaQkgA%3D&reserved=0
> >
> > I have created a WIP/draft PR to show the potential changes:
> > https://gith/
> > ub.com%2Fapache%2Fpulsar%2Fpull%2F22054&data=05%7C02%7Cahall%40teknolu
> > xion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e27223a
> > 522b9791%7C0%7C0%7C638436165473641886%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7
> > C&sdata=6eKLufeZ%2BsqcKJNp01PUYLYQKBLOSHGsDtbN831QQzM%3D&reserved=0
> >
> > The image already passes all the integration tests and has been tested
> > for few weeks in a test cluster.
> >
> > I have pushed a Docker image for preview purposes:
> > merlimat/pulsar/3.3.0-SNAPSHOT-f2a91a1
> >
> >
> > https://hub/.
> > docker.com%2Flayers%2Fmerlimat%2Fpulsar%2F3.3.0-SNAPSHOT-f2a91a1%2Fima
> > ges%2Fsha256-2d94832618bf30c02baa269bdf943c8f37aa5430258b7b4018f37ed12
> > 0abb17a%3Fcontext%3Dexplore&data=05%7C02%7Cahall%40teknoluxion.com%7C0
> > 79cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0
> > %7C0%7C638436165473645634%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> > LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=B6z5
> > xdq%2FF%2BLLasB7MM1OrqupF3vqullwEjZzOQT7ekQ%3D&reserved=0
> >
> > Thanks,
> > Matteo
> >
> > --
> > Matteo Merli
> > <ma...@gmail.com>
> >
> >
> > On Wed, Dec 20, 2023 at 12:49 PM David Christle
> > <da...@discordapp.com.invalid> wrote:
> >
> > > Are we sure the move to Alpine is worth the extensive performance
> > > testing and the risk of issues? Sticking with a popular glibc image
> > > like Temurin, Ubuntu/Debian, or ubi-minimal (mentioned also in this
> > > discussion) seems like a better path to me, without the risk of
> > > glibc vs musl issues. Using Distroless seems like another good
> > > potential option, as it would achieve the same aims as the Alpine
> > > move, with less
> > potential risk.
> > >
> > > The DNS issues seen with Alpine are worth paying strong attention to.
> > > Someone running a Pulsar deployment using the images could have a
> > > very difficult time debugging library/glibc vs musl/DNS issues, due
> > > to their low-level nature. A fix for the DNS issue only landed less
> > > than a year ago [1]. Unless we have a compelling reason for Alpine,
> > > it may be safer to wait for more adoption/testing before choosing it
> > > for the
> > official Pulsar images.
> > >
> > > The two main arguments in the PIP are:
> > >
> > > - Using a smaller base image like Alpine can save space. The
> > > relative size of the JRE image for Alpine is about 45% smaller than
> > > the equivalent Ubuntu slim image.
> > >
> > > - The Ubuntu image has a few tens of CVEs in it, as reported by an
> > > automated container CVE scan tool, compared to 0 in Alpine.
> > >
> > >
> > > These seem reasonable, but the true magnitude of benefit is likely
> > > lower in practice. The pulsar-all images are 2.7GB in size, so
> > > saving 166MB on the base + JRE install translates to just a 6% smaller
> image.
> > > Unless we expect other installed packages part of pulsar-all to gain
> > > additional space savings on Alpine, this difference seems very
> > > marginal
> > in practice.
> > >
> > > Security-wise, I took a cursory look at the CVEs, and many of them
> > > are in libraries that aren’t used in a Pulsar deployment/are
> > > difficult to envision a practical exploit scenario. Automated
> > > scanning tool results should be taken with a grain of salt - they
> > > generate a lot of alerts, and many public container images throw off
> these CVE alerts nowadays.
> > > The counterargument is that only a fraction of the libraries
> > > indicated are even loaded at runtime, only some fraction of those
> > > end up potentially being exploitable, and only a smaller fraction
> > > have no fix/workaround. This isn’t to say reducing the vulnerability
> > > surface by using an image with less cruft in it is not a worthwhile
> > > endeavor — I do think we should try to tackle it -- but I’m simply
> > > trying to be realistic about what our actual gains will be from
> switching to Alpine.
> > >
> > > It’s also worth mentioning we’d be moving away from other large
> > > open-source big data projects in a way. Spark [2], Flink [3], Kafka
> > > [4], Elasticsearch [5], and Trino [6] are based on Temurin/Ubuntu/ubi.
> > > In my brief search, I didn’t find familiar names of tools in the big
> > > data ecosystem with official images based on Alpine.
> > >
> > > Distroless would also remove almost everything from our base images,
> > > minimizing space, reducing the vulnerability surface, and by
> > > extension, reducing the CVE alerts from automated tooling. Apache
> > > Druid [7] has used Distroless for a while in their official images.
> > > We could achieve the same aims without any risk from musl/glibc, DNS
> > > quirks, or other hiccups that Alpine may have.
> > >
> > > Regards,
> > > David
> > >
> > >
> > > [1]
> > > https://gi/
> > > tlab.alpinelinux.org%2Falpine%2Ftsc%2F-%2Fissues%2F43%23note_295556&
> > > data=05%7C02%7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4
> > > f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0%7C0%7C63843616547365006
> > > 8%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> > > I6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=tvzXRU7tQWR8TkRjzKEk0PtW
> > > TJj8aenzYqjDGWSok3E%3D&reserved=0
> > > [2] Apache Spark - Temurin -
> > > https://gi/
> > > thub.com%2Fapache%2Fflink-docker%2Ftree%2Fmaster%2F1.18&data=05%7C02
> > > %7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcce
> > > b892218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473654182%7CUnknown%
> > > 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> > > JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=AUS85hOOnewk88bm7J4zDsr5F1cACzcj6ULv
> > > 2%2BGGEzk%3D&reserved=0
> > > [3] Apache Flink - Temurin -
> > > https://gi/
> > > thub.com%2Fapache%2Fflink-docker%2Ftree%2Fmaster%2F1.18&data=05%7C02
> > > %7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcce
> > > b892218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473658191%7CUnknown%
> > > 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> > > JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=L%2BUzvHzoENFmwQUeAgv0lFZlpDKIAncFu7
> > > %2FA3YeQPeQ%3D&reserved=0 [4] KIP-975: Docker Image for Apache Kafka
> > > - Temurin -
> > >
> > https://cwik/
> > i.apache.org%2Fconfluence%2Fdisplay%2FKAFKA%2FKIP-975%253A%2BDocker%2B
> > Image%2Bfor%2BApache%2BKafka&data=05%7C02%7Cahall%40teknoluxion.com%7C
> > 079cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C
> > 0%7C0%7C638436165473662148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> > iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=090
> > vsrQjkBCqK%2FVoPpVbBQ9Uo4LcmxSJY1dOzsuEwCw%3D&reserved=0
> > > [5] Elasticsearch - Ubuntu & ubi-minimal -
> > >
> > https://gith/
> > ub.com%2Felastic%2Felasticsearch%2Fblob%2Fbdde29720a9e37224a90e5f186ab
> > bcbc73ff9351%2Fdistribution%2Fdocker%2FREADME.md&data=05%7C02%7Cahall%
> > 40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6
> > f9e27223a522b9791%7C0%7C0%7C638436165473666193%7CUnknown%7CTWFpbGZsb3d
> > 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> > 0%7C%7C%7C&sdata=jKPpyOs5ZgrqHE5i%2FscNIDp3c8f8iXHjqsjcSgodmwQ%3D&rese
> > rved=0 [6] Trino - ubi, after moving from Ubuntu -
> > >
> > https://hub/.
> > docker.com%2Flayers%2Ftrinodb%2Ftrino%2F435%2Fimages%2Fsha256-9540a785
> > c31c4ba9ad099ad99ae06ccd5ccca506e39b7d557effe1482309e05d&data=05%7C02%
> > 7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb89
> > 2218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473669894%7CUnknown%7CTWF
> > pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> > n0%3D%7C0%7C%7C%7C&sdata=kS9hu%2FXVA4fHP3dL23LBQ1yY5rzIvPZ40V73UBbN7cA
> > %3D&reserved=0
> > > [7] Apache Druid - Distroless -
> > >
> > https://gith/
> > ub.com%2Fapache%2Fdruid%2Fblob%2Fe373f6269251655f5be93ce895aee8dee8cc6
> > 7dd%2Fdistribution%2Fdocker%2FDockerfile%23L4&data=05%7C02%7Cahall%40t
> > eknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e
> > 27223a522b9791%7C0%7C0%7C638436165473676661%7CUnknown%7CTWFpbGZsb3d8ey
> > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> > C%7C%7C&sdata=xqjkAQD0%2FQM%2BQ%2BWc1Gfs6KQ%2FOm1RsGeKfaYijvc2ogg%3D&r
> > eserved=0
> > >
> > >
> > > On 2023/12/13 17:06:12 Matteo Merli wrote:
> > > > I don't think the compatibility for downstream users is going to
> > > > be a big
> > > > problem:
> > > > 1. Most users don't need to modify the Pulsar image in
> > > > significant way 2. If they do, they won't be using the "latest"
> > > > tag, but rather a
> > > specific
> > > > version
> > > > 3. Users who are dependent on the Ubuntu base image can stay on
> > > > the
> > > > 3.0 LTS release branch for the entire LTS lifespan
> > > >
> > > > I would avoid supporting 2 images at the same time because it
> > > > would make
> > > it
> > > > very hard to properly test them both.
> > > >
> > > >
> > > > --
> > > > Matteo Merli
> > > > <mm...@apache.org>
> > > >
> > > >
> > > > On Tue, Dec 12, 2023 at 8:57 PM Zixuan Liu <zi...@apache.org> wrote:
> > > >
> > > > > +1.
> > > > >
> > > > > It is a good idea to use the Alpine image to run the Pulsar, as
> > > > > it is
> > > more
> > > > > secure.
> > > > >
> > > > > However, switching images may affect downstream users, and I am
> > > wondering
> > > > > if it is possible to provide multiple docker tags:
> > > > > - latest: using the Ubuntu image
> > > > > - alpine: using the Alpine image
> > > > >
> > > > > Thanks,
> > > > > Zixuan
> > > > >
> > > > > Yunze Xu <xy...@apache.org> 于2023年12月13日周三 12:24写道：
> > > > >
> > > > > > +1 to me. The Alpine Linux is much more light-weight than Ubuntu.
> > > > > >
> > > > > > Thanks,
> > > > > > Yunze
> > > > > >
> > > > > > On Wed, Dec 13, 2023 at 3:00 AM Matteo Merli
> > > > > > <mm...@apache.org>
> > > wrote:
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > I've created a new proposal to switch Pulsar base docker
> > > > > > > images
> > > from
> > > > > > Ubuntu
> > > > > > > to Alpine Linux.
> > > > > > >
> > > > > > > Details and motivation in the PIP:
> > > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A
> > > > > > > %2F%2Fgithub.com%2Fapache%2Fpulsar%2Fpull%2F21716&data=05%7C
> > > > > > > 02%7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f5
> > > > > > > 3d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0%7C0%7C63843616547
> > > > > > > 3681456%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> > > > > > > V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=B0
> > > > > > > vOlZVAdBUQV3qdkxAIJe5G4OLQsnCAkntD1tsSEVk%3D&reserved=0
> > > > > > >
> > > > > > > Matteo
> > > > > > >
> > > > > > > --
> > > > > > > Matteo Merli
> > > > > > > <mm...@apache.org>
> > > > > >
> > > > >
> > > >
> >
>
Re: [DISCUSS] PIP-324: Alpine Docker images
Posted by Matteo Merli <ma...@gmail.com>.
Hi Alexander,
it doesn't look to be only 4 issues in that image:
https://catalog.redhat.com/software/containers/ubi9/ubi/615bcf606feffc5384e8452e
points to this Docker image
registry.access.redhat.com/ubi9/ubi@sha256:1fafb0905264413501df60d90a92ca32df8a2011cbfb4876ddff5ceb20c8f165
(redhat 9.3)
Total: 172 (UNKNOWN: 0, LOW: 144, MEDIUM: 28, HIGH: 0, CRITICAL: 0)
Full list: https://gist.github.com/merlimat/a4fcea7336cab83ad64dcf01d9b15a1c
--
Matteo Merli
<ma...@gmail.com>
On Fri, Mar 1, 2024 at 9:19 AM Alexander Hall <ah...@teknoluxion.com.invalid>
wrote:
> According to Red Hat their latest tagged release for UBI9.3, 9.3-1552, has
> four moderate CVE's (
> https://catalog.redhat.com/software/containers/ubi9/ubi/615bcf606feffc5384e8452e).
> There is also the option of basing the Pulsar image on the UBI9-minimal
> image (
> https://catalog.redhat.com/software/containers/ubi9/ubi-minimal/615bd9b4075b022acc111bf5).
> That may have a better security footprint.
>
> Thank You,
>
> Alex Hall
> <ah...@teknoluxion.com>
>
> -----Original Message-----
> From: Matteo Merli <ma...@gmail.com>
> Sent: Thursday, February 15, 2024 12:55 PM
> To: dev@pulsar.apache.org
> Subject: ''Re: Re: [DISCUSS] PIP-324: Alpine Docker images
>
> [You don't often get email from matteo.merli@gmail.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi Alex,
>
> the situation for UBI9 doesn't look much different from Ubuntu:
>
> registry.access.redhat.com/ubi9/ubi (redhat 9.3)
> Total: 166 (UNKNOWN: 0, LOW: 138, MEDIUM: 28, HIGH: 0, CRITICAL: 0)
>
> Full list:
> https://gist.github.com/merlimat/ba96b91ea49709bb218ddc3906bb9e95
>
>
> --
> Matteo Merli
> <ma...@gmail.com>
>
>
> On Thu, Feb 15, 2024 at 9:10 AM Alexander Hall
> <ah...@teknoluxion.com.invalid> wrote:
>
> > Reviving a previous tangent from this discussion. Using UBI9 as a base
> > is also a great option. Some end-users use that as a base and copy the
> > files from the pulsar and pulsar-all containers as an upstream source.
> >
> > -Alex H
> >
> > -----Original Message-----
> > From: Matteo Merli <ma...@gmail.com>
> > Sent: Wednesday, February 14, 2024 2:01 PM
> > To: david.christle@discordapp.com.invalid
> > Cc: dev@pulsar.apache.org
> > Subject: ''Re: Re: [DISCUSS] PIP-324: Alpine Docker images
> >
> > [You don't often get email from *REDACTED*. Learn why this is
> > important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > Reviving the discussion thread.
> >
> >
> > > For Netty, I think netty-transport-native-epoll is only built
> > > against glibc (
> >
> > https://nett/
> > y.io%2Fwiki%2Fnative-transports.html%23using-the-linux-native-transpor
> > t&data=05%7C02%7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4
> > f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473628082%
> > 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> > 1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=kJQqQ5o6ZnuIlqO6Chq0P0Z6axc6Ji
> > WSP%2F5Qd7bN7xw%3D&reserved=0
> > ).
> > > Is there a workaround ?
> >
> > Yes, there is a workaround for Netty. It works perfectly fine by
> > including the GLibc compatibility library. Same for Kinesis producer
> (side note:
> > Kinesis SDK is the worst train wreck I've seen in many many years:
> > it's a
> > C++ binary that it spawned from Java and communicates through a pipe...
> > anyway it works fine with the GLibc compatibility lib).
> >
> > > Other than that, there is the DNS caching issue Lari mentioned.
> >
> > I think the DNS issue was already solved a few releases ago. In any
> > case, it wouldn't affect Pulsar/BK since we use the Netty DNS client.
> > In the same way, I believe that JDK also doesn't use the glibc provided
> DNS client:
> > that's why we configure the DNS cache directly in the JVM configuration.
> >
> > >> - Using a smaller base image like Alpine can save space. The
> > >> relative
> > size of the JRE image for Alpine is about 45% smaller than the
> > equivalent Ubuntu slim image.
> > >> - The Ubuntu image has a few tens of CVEs in it, as reported by an
> > automated container CVE scan tool, compared to 0 in Alpine.
> > > These seem reasonable, but the true magnitude of benefit is likely
> > > lower
> > in practice. The pulsar-all images are 2.7GB in size, so saving 166MB
> > on the base + JRE install translates to just a 6% smaller image.
> > Unless we expect other installed packages part of pulsar-all to gain
> > additional space savings on Alpine, this difference seems very marginal
> in practice.
> >
> > `pulsar-all` is ready for separate discussion (I actually think we
> > should discontinue that image).
> >
> > For `pulsar` image:
> > * apache/pulsar:3.2.0 (which already does not include Presto anymore):
> > 919 MB
> > * alpine image wip: 505 MB
> >
> > There are additional ways we should explore to further reduce the
> > image size (eg: removing unused JDK modules, Python packages, etc...)
> >
> > > Security-wise, I took a cursory look at the CVEs, and many of them
> > > are in
> > libraries that aren’t used in a Pulsar deployment/are difficult to
> > envision a practical exploit scenario. Automated scanning tool results
> > should be taken with a grain of salt - they generate a lot of alerts,
> > and many public container images throw off these CVE alerts nowadays.
> > The counterargument is that only a fraction of the libraries indicated
> > are even loaded at runtime, only some fraction of those end up
> > potentially being exploitable, and only a smaller fraction have no
> > fix/workaround. This isn’t to say reducing the vulnerability surface
> > by using an image with less cruft in it is not a worthwhile endeavor —
> > I do think we should try to tackle it
> > -- but I’m simply trying to be realistic about what our actual gains
> > will be from switching to Alpine.
> >
> > Even though the CVEs might not be a "real" security issue, or not be
> > exploitable in the context of Pulsar, it is really not how any
> > security team would look at it. From their perspective, it becomes
> > unmanageable to check and understand every single CVE to assess the
> > potential specific threat.
> >
> > This is a real problem that is causing a lot of headaches to have
> > Pulsar distribution taken seriously from a security posture perspective.
> >
> > Just have a glance at the security CVE issues in our last Pulsar
> > release, released just a few days ago:
> >
> > apachepulsar/pulsar:3.2.0 (ubuntu 22.04)
> > Total: 243 (UNKNOWN: 0, LOW: 146, MEDIUM: 93, HIGH: 4, CRITICAL: 0)
> >
> > Compare with Pulsar image based on Alpine:
> >
> > merlimat/pulsar:3.3.0-SNAPSHOT-f2a91a1 (alpine 3.19.1)
> > Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)
> >
> > Full list here:
> > https://gist/
> > .github.com%2Fmerlimat%2Fee7534992b21cae0b04c8c63f64456ff&data=05%7C02
> > %7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb8
> > 92218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473633950%7CUnknown%7CTW
> > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> > Mn0%3D%7C0%7C%7C%7C&sdata=y3NzrPg14CBnD2nsr1Devtc5w2Ki0EPKeigKRT5piMI%
> > 3D&reserved=0 The above are all issues coming from Ubuntu base image.
> >
> > > It’s also worth mentioning we’d be moving away from other large
> > open-source big data projects in a way. Spark [2], Flink [3], Kafka
> > [4], Elasticsearch [5], and Trino [6] are based on Temurin/Ubuntu/ubi.
> > In my brief search, I didn’t find familiar names of tools in the big
> > data ecosystem with official images based on Alpine.
> > > Distroless would also remove almost everything from our base images,
> > minimizing space, reducing the vulnerability surface, and by
> > extension, reducing the CVE alerts from automated tooling. Apache
> > Druid [7] has used Distroless for a while in their official images. We
> > could achieve the same aims without any risk from musl/glibc, DNS
> > quirks, or other hiccups that Alpine may have.
> >
> >
> > Regarding the OpenJDK distribution, the team from Amazon Corretto,
> > publishes well tested and supported Alpine packages. See
> > https://aws/.
> > amazon.com%2Fcorretto&data=05%7C02%7Cahall%40teknoluxion.com%7C079cd39
> > e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0%7C0%7
> > C638436165473638107%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> > oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2FTa7LLrx
> > LHOwdHOIjP%2BIiFON%2FEjQdTH0cTZFtFaQkgA%3D&reserved=0
> >
> > I have created a WIP/draft PR to show the potential changes:
> > https://gith/
> > ub.com%2Fapache%2Fpulsar%2Fpull%2F22054&data=05%7C02%7Cahall%40teknolu
> > xion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e27223a
> > 522b9791%7C0%7C0%7C638436165473641886%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7
> > C&sdata=6eKLufeZ%2BsqcKJNp01PUYLYQKBLOSHGsDtbN831QQzM%3D&reserved=0
> >
> > The image already passes all the integration tests and has been tested
> > for few weeks in a test cluster.
> >
> > I have pushed a Docker image for preview purposes:
> > merlimat/pulsar/3.3.0-SNAPSHOT-f2a91a1
> >
> >
> > https://hub/.
> > docker.com%2Flayers%2Fmerlimat%2Fpulsar%2F3.3.0-SNAPSHOT-f2a91a1%2Fima
> > ges%2Fsha256-2d94832618bf30c02baa269bdf943c8f37aa5430258b7b4018f37ed12
> > 0abb17a%3Fcontext%3Dexplore&data=05%7C02%7Cahall%40teknoluxion.com%7C0
> > 79cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0
> > %7C0%7C638436165473645634%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> > LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=B6z5
> > xdq%2FF%2BLLasB7MM1OrqupF3vqullwEjZzOQT7ekQ%3D&reserved=0
> >
> > Thanks,
> > Matteo
> >
> > --
> > Matteo Merli
> > <ma...@gmail.com>
> >
> >
> > On Wed, Dec 20, 2023 at 12:49 PM David Christle
> > <da...@discordapp.com.invalid> wrote:
> >
> > > Are we sure the move to Alpine is worth the extensive performance
> > > testing and the risk of issues? Sticking with a popular glibc image
> > > like Temurin, Ubuntu/Debian, or ubi-minimal (mentioned also in this
> > > discussion) seems like a better path to me, without the risk of
> > > glibc vs musl issues. Using Distroless seems like another good
> > > potential option, as it would achieve the same aims as the Alpine
> > > move, with less
> > potential risk.
> > >
> > > The DNS issues seen with Alpine are worth paying strong attention to.
> > > Someone running a Pulsar deployment using the images could have a
> > > very difficult time debugging library/glibc vs musl/DNS issues, due
> > > to their low-level nature. A fix for the DNS issue only landed less
> > > than a year ago [1]. Unless we have a compelling reason for Alpine,
> > > it may be safer to wait for more adoption/testing before choosing it
> > > for the
> > official Pulsar images.
> > >
> > > The two main arguments in the PIP are:
> > >
> > > - Using a smaller base image like Alpine can save space. The
> > > relative size of the JRE image for Alpine is about 45% smaller than
> > > the equivalent Ubuntu slim image.
> > >
> > > - The Ubuntu image has a few tens of CVEs in it, as reported by an
> > > automated container CVE scan tool, compared to 0 in Alpine.
> > >
> > >
> > > These seem reasonable, but the true magnitude of benefit is likely
> > > lower in practice. The pulsar-all images are 2.7GB in size, so
> > > saving 166MB on the base + JRE install translates to just a 6% smaller
> image.
> > > Unless we expect other installed packages part of pulsar-all to gain
> > > additional space savings on Alpine, this difference seems very
> > > marginal
> > in practice.
> > >
> > > Security-wise, I took a cursory look at the CVEs, and many of them
> > > are in libraries that aren’t used in a Pulsar deployment/are
> > > difficult to envision a practical exploit scenario. Automated
> > > scanning tool results should be taken with a grain of salt - they
> > > generate a lot of alerts, and many public container images throw off
> these CVE alerts nowadays.
> > > The counterargument is that only a fraction of the libraries
> > > indicated are even loaded at runtime, only some fraction of those
> > > end up potentially being exploitable, and only a smaller fraction
> > > have no fix/workaround. This isn’t to say reducing the vulnerability
> > > surface by using an image with less cruft in it is not a worthwhile
> > > endeavor — I do think we should try to tackle it -- but I’m simply
> > > trying to be realistic about what our actual gains will be from
> switching to Alpine.
> > >
> > > It’s also worth mentioning we’d be moving away from other large
> > > open-source big data projects in a way. Spark [2], Flink [3], Kafka
> > > [4], Elasticsearch [5], and Trino [6] are based on Temurin/Ubuntu/ubi.
> > > In my brief search, I didn’t find familiar names of tools in the big
> > > data ecosystem with official images based on Alpine.
> > >
> > > Distroless would also remove almost everything from our base images,
> > > minimizing space, reducing the vulnerability surface, and by
> > > extension, reducing the CVE alerts from automated tooling. Apache
> > > Druid [7] has used Distroless for a while in their official images.
> > > We could achieve the same aims without any risk from musl/glibc, DNS
> > > quirks, or other hiccups that Alpine may have.
> > >
> > > Regards,
> > > David
> > >
> > >
> > > [1]
> > > https://gi/
> > > tlab.alpinelinux.org%2Falpine%2Ftsc%2F-%2Fissues%2F43%23note_295556&
> > > data=05%7C02%7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4
> > > f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0%7C0%7C63843616547365006
> > > 8%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> > > I6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=tvzXRU7tQWR8TkRjzKEk0PtW
> > > TJj8aenzYqjDGWSok3E%3D&reserved=0
> > > [2] Apache Spark - Temurin -
> > > https://gi/
> > > thub.com%2Fapache%2Fflink-docker%2Ftree%2Fmaster%2F1.18&data=05%7C02
> > > %7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcce
> > > b892218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473654182%7CUnknown%
> > > 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> > > JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=AUS85hOOnewk88bm7J4zDsr5F1cACzcj6ULv
> > > 2%2BGGEzk%3D&reserved=0
> > > [3] Apache Flink - Temurin -
> > > https://gi/
> > > thub.com%2Fapache%2Fflink-docker%2Ftree%2Fmaster%2F1.18&data=05%7C02
> > > %7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcce
> > > b892218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473658191%7CUnknown%
> > > 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> > > JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=L%2BUzvHzoENFmwQUeAgv0lFZlpDKIAncFu7
> > > %2FA3YeQPeQ%3D&reserved=0 [4] KIP-975: Docker Image for Apache Kafka
> > > - Temurin -
> > >
> > https://cwik/
> > i.apache.org%2Fconfluence%2Fdisplay%2FKAFKA%2FKIP-975%253A%2BDocker%2B
> > Image%2Bfor%2BApache%2BKafka&data=05%7C02%7Cahall%40teknoluxion.com%7C
> > 079cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e27223a522b9791%7C
> > 0%7C0%7C638436165473662148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> > iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=090
> > vsrQjkBCqK%2FVoPpVbBQ9Uo4LcmxSJY1dOzsuEwCw%3D&reserved=0
> > > [5] Elasticsearch - Ubuntu & ubi-minimal -
> > >
> > https://gith/
> > ub.com%2Felastic%2Felasticsearch%2Fblob%2Fbdde29720a9e37224a90e5f186ab
> > bcbc73ff9351%2Fdistribution%2Fdocker%2FREADME.md&data=05%7C02%7Cahall%
> > 40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6
> > f9e27223a522b9791%7C0%7C0%7C638436165473666193%7CUnknown%7CTWFpbGZsb3d
> > 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> > 0%7C%7C%7C&sdata=jKPpyOs5ZgrqHE5i%2FscNIDp3c8f8iXHjqsjcSgodmwQ%3D&rese
> > rved=0 [6] Trino - ubi, after moving from Ubuntu -
> > >
> > https://hub/.
> > docker.com%2Flayers%2Ftrinodb%2Ftrino%2F435%2Fimages%2Fsha256-9540a785
> > c31c4ba9ad099ad99ae06ccd5ccca506e39b7d557effe1482309e05d&data=05%7C02%
> > 7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb89
> > 2218c4d6f9e27223a522b9791%7C0%7C0%7C638436165473669894%7CUnknown%7CTWF
> > pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> > n0%3D%7C0%7C%7C%7C&sdata=kS9hu%2FXVA4fHP3dL23LBQ1yY5rzIvPZ40V73UBbN7cA
> > %3D&reserved=0
> > > [7] Apache Druid - Distroless -
> > >
> > https://gith/
> > ub.com%2Fapache%2Fdruid%2Fblob%2Fe373f6269251655f5be93ce895aee8dee8cc6
> > 7dd%2Fdistribution%2Fdocker%2FDockerfile%23L4&data=05%7C02%7Cahall%40t
> > eknoluxion.com%7C079cd39e87b240332d3108dc2e4f53d5%7Cfcceb892218c4d6f9e
> > 27223a522b9791%7C0%7C0%7C638436165473676661%7CUnknown%7CTWFpbGZsb3d8ey
> > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> > C%7C%7C&sdata=xqjkAQD0%2FQM%2BQ%2BWc1Gfs6KQ%2FOm1RsGeKfaYijvc2ogg%3D&r
> > eserved=0
> > >
> > >
> > > On 2023/12/13 17:06:12 Matteo Merli wrote:
> > > > I don't think the compatibility for downstream users is going to
> > > > be a big
> > > > problem:
> > > > 1. Most users don't need to modify the Pulsar image in
> > > > significant way 2. If they do, they won't be using the "latest"
> > > > tag, but rather a
> > > specific
> > > > version
> > > > 3. Users who are dependent on the Ubuntu base image can stay on
> > > > the
> > > > 3.0 LTS release branch for the entire LTS lifespan
> > > >
> > > > I would avoid supporting 2 images at the same time because it
> > > > would make
> > > it
> > > > very hard to properly test them both.
> > > >
> > > >
> > > > --
> > > > Matteo Merli
> > > > <mm...@apache.org>
> > > >
> > > >
> > > > On Tue, Dec 12, 2023 at 8:57 PM Zixuan Liu <zi...@apache.org> wrote:
> > > >
> > > > > +1.
> > > > >
> > > > > It is a good idea to use the Alpine image to run the Pulsar, as
> > > > > it is
> > > more
> > > > > secure.
> > > > >
> > > > > However, switching images may affect downstream users, and I am
> > > wondering
> > > > > if it is possible to provide multiple docker tags:
> > > > > - latest: using the Ubuntu image
> > > > > - alpine: using the Alpine image
> > > > >
> > > > > Thanks,
> > > > > Zixuan
> > > > >
> > > > > Yunze Xu <xy...@apache.org> 于2023年12月13日周三 12:24写道：
> > > > >
> > > > > > +1 to me. The Alpine Linux is much more light-weight than Ubuntu.
> > > > > >
> > > > > > Thanks,
> > > > > > Yunze
> > > > > >
> > > > > > On Wed, Dec 13, 2023 at 3:00 AM Matteo Merli
> > > > > > <mm...@apache.org>
> > > wrote:
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > I've created a new proposal to switch Pulsar base docker
> > > > > > > images
> > > from
> > > > > > Ubuntu
> > > > > > > to Alpine Linux.
> > > > > > >
> > > > > > > Details and motivation in the PIP:
> > > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A
> > > > > > > %2F%2Fgithub.com%2Fapache%2Fpulsar%2Fpull%2F21716&data=05%7C
> > > > > > > 02%7Cahall%40teknoluxion.com%7C079cd39e87b240332d3108dc2e4f5
> > > > > > > 3d5%7Cfcceb892218c4d6f9e27223a522b9791%7C0%7C0%7C63843616547
> > > > > > > 3681456%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> > > > > > > V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=B0
> > > > > > > vOlZVAdBUQV3qdkxAIJe5G4OLQsnCAkntD1tsSEVk%3D&reserved=0
> > > > > > >
> > > > > > > Matteo
> > > > > > >
> > > > > > > --
> > > > > > > Matteo Merli
> > > > > > > <mm...@apache.org>
> > > > > >
> > > > >
> > > >
> >
>