Organize docker image tags supporting currently supported FluentBit

[gautam-nutalapati]

Hi There,

Our latest fluent bit CICD builds that build docker images on top of https://gallery.ecr.aws/aws-observability/aws-for-fluent-bit has been marked with security vulnerabilities. I tried finding latest stable version. I created this ticket, hoping it would add some meaningful organization to docker tagging approach.

Please correct or point me in right direction if I am missing something. I believe this is needed for anyone out there using AWS fluent bit images

Please organize release tags to support all versions of FluentBit.

Latest stable version 2.34.1.20251112 is still using FluentBit v1.9.10
latest and stable tags are still using v1.9.10
aws-for-fluent-bit:3.1.0 is using FluentBit v4.2.0

FluentBit versions before 3.1 are at end of life as of 2024 September (https://fluentbit.io/announcements/older-versions/)

⚠️ There is no clean structure for the docker tags in https://gallery.ecr.aws/aws-observability/aws-for-fluent-bit

Can we have latest and stable multi-arch tags per each fluent-bit currently supported version 4.0, 4.1, 4.2, 3.1, 3.2?
Something like
aws-for-fluent-bit:4.0-latest
aws-for-fluent-bit:4.0-stable
And below should actually point to latest fluent-bit always (4.2 as of when this issue is created)
aws-for-fluent-bit:latest
aws-for-fluent-bit:stable

[ShelbyZ]

https://github.com/aws/aws-for-fluent-bit/blob/mainline/VERSIONS.md#tags

Note: The stable image tag continues to point to AWS for Fluent Bit version 2.x

1. The stable tag will not point to 3.x or later releases.
2. The latest tag may eventually point to a 3.x or later release.
3. AWS for Fluent Bit maintains a separate version from fluent-bit to allow container/packaging changes that exist outside fluent-bit releases

Can we have latest and stable multi-arch tags per each fluent-bit currently supported version 4.0, 4.1, 4.2, 3.1, 3.2?

We do not want to get in the business of supporting multi fluent-bit versions and would rather anchor a release to a version

[gautam-nutalapati]

Thanks for quick response!
Even though all fluentbit versions are not supported, I believe above proposal would add some structure to help users select the version among the ones that AWS supports.
stable and latest pointing to different versions does not look like a good way to organize the images.

UPDATE:
public.ecr.aws/aws-observability/aws-for-fluent-bit:stable is using Fluent Bit v1.9.10, which contradicts the note Note: The stable image tag continues to point to AWS for Fluent Bit version 2.x

I hope this input helps.

[aofldl]

We came here with the same issue getting flagged for fluentbit version 1.9.10 being vulnerable to remote security vulns by security scanners.

We did see 3.1.0 using a fixed version of fluentbit upstream 4.2 and I am assuming if 3.x is not going to ever be stable then we can pin to a known working version of 3.x we test which is also a best practice so it doesnt shift/change underneath. @ShelbyZ is it safe to say that pinning to a working aws-for-fluent-bit 3.1.x release is the cleanest/approved way to use the newer fluentbit releases?

[umeshtoke0911]

We are also using the stable 2.x series in our production environment and are the vulnerability scanners is reporting Fluent Bit CVEs (e.g., CVE-2025-12970) in the embedded v1.9.10 core. @ShelbyZ Could you please provide an update on the official plan or timeline for releasing a backport patch to the 2.x stable branch?

As non stable release isn't recommended to be used on production/live environment we cannot go for any other release versions.