ci: add distroless-fips image variant built with --config=aws-lc-fips

[frbvianna]

Summary

Adds a distroless-fips-v{X}.{Y}.{Z} Docker image published alongside each standard release, built with --config=aws-lc-fips. A distroless-fips-dev image is also published on each push to main.

This addresses #45812.

Changes

• ci/do_ci.sh: add release.server_only.fips target that appends --config=aws-lc-fips to BAZEL_RELEASE_OPTIONS and outputs the binary as release.fips.tar.zst
• distribution/docker/Dockerfile-envoy: add ENVOY_RELEASE_TARBALL build arg (default: release.tar.zst) to allow the FIPS build to supply an alternative tarball without duplicating the envoy-distroless stage
• distribution/docker/build.sh: add -distroless-fips to BUILD_TYPES; update build_args to strip -fips when deriving the Docker --target and pass --build-arg ENVOY_RELEASE_TARBALL=release.fips.tar.zst for FIPS builds
• .github/workflows/_publish_build.yml: add binary-fips and docker-fips jobs mirroring the existing binary/docker jobs, with timeout-minutes: 180 to account for the longer AWS-LC FIPS compilation
• .github/workflows/_publish_release_container.yml: add distroless-fips-dev and distroless-fips-v{X}.{Y}.{Z} manifest entries

Notes

• --config=aws-lc-fips is used (not --config=boringssl-fips) as it supports both amd64 and arm64; the boringssl-fips config is limited to Linux x86_64
• No new Dockerfile stage is needed — the FIPS image reuses the existing envoy-distroless target with a FIPS-built binary injected via the ENVOY_RELEASE_TARBALL build arg
• The Envoy project makes no compliance certification claim by publishing this image; users validate against their own requirements

[repokitteh-read-only]

Hi @frbvianna, welcome and thank you for your contribution.

We will try to review your Pull Request as quickly as possible.

In the meantime, please take a look at the contribution guidelines if you have not done so already.

🐱

Caused by: #45813 was opened by frbvianna.

see: more, trace.

[phlax]

@frbvianna i see a few problems wit this idea

firstly we dont publish any fips builds at all - they are not certified in any way - what we provide is the setup for downstreams to build fips for their own compliance/certification

next - we also dont currently have any aws-lc ci - its not really supported by the project, more accomodated

and finally - for us to consider publishing any additional container builds - we would first need to consider publishing a binary for that

[frbvianna]

firstly we dont publish any fips builds at all - they are not certified in any way - what we provide is the setup for downstreams to build fips for their own compliance/certification

@phlax, thanks for taking a look. I understand these are not certified, however, if we are to use a FIPS-compliant TLS module in Envoy, my understanding is that we should build our own Envoy artifact. Is there an alternative to that? I thought that simply releasing the image built with either --config=boringssl-fips or --config=aws-lc-fips would mean that every downstream doesn't need to maintain its own build.

next - we also dont currently have any aws-lc ci - its not really supported by the project, more accomodated

Is it feasible for --config=boringssl-fips?

and finally - for us to consider publishing any additional container builds - we would first need to consider publishing a binary for that

Do you see an issue with that?

[yanavlasov]

firstly we dont publish any fips builds at all - they are not certified in any way - what we provide is the setup for downstreams to build fips for their own compliance/certification

@phlax, thanks for taking a look. I understand these are not certified, however, if we are to use a FIPS-compliant TLS module in Envoy, my understanding is that we should build our own Envoy artifact. Is there an alternative to that? I thought that simply releasing the image built with either --config=boringssl-fips or --config=aws-lc-fips would mean that every downstream doesn't need to maintain its own build.

next - we also dont currently have any aws-lc ci - its not really supported by the project, more accomodated

Is it feasible for --config=boringssl-fips?

and finally - for us to consider publishing any additional container builds - we would first need to consider publishing a binary for that

Do you see an issue with that?

The issues are maintenance and CI resources for qualification. We do not qualify either FIPS configuration by building and running Envoy test suite. If we commit this change the only guarantee we have for this docker image is that the binary had been successfully linked. Is this something you'd be willing to deploy into your production? Adding qualification will require CI resources which are tight already. We could limit this qualification to just the points of release, but then who would be responsible for the eventual bit rot, failed build or tests? Would you commit to long term maintenance of these images?