Skip to content

Use FIPS base images for amd64/arm64, standard images for s390x #7676

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
buger wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Use FIPS base images for amd64/arm64, standard images for s390x #7676

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c23654f
Use conditional base images: FIPS for amd64/arm64, standard for s390x
buger Jan 16, 2026
e8d99f3
Add FIPS build configuration and Docker image workflow
buger Jan 16, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 66 additions & 0 deletions .github/workflows/release.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -50,6 +50,7 @@
debvers: 'ubuntu/xenial ubuntu/bionic ubuntu/focal ubuntu/jammy ubuntu/noble debian/jessie debian/buster debian/bullseye debian/bookworm debian/trixie'
outputs:
ee_tags: ${{ steps.ci_metadata_ee.outputs.tags }}
fips_tags: ${{ steps.ci_metadata_fips.outputs.tags }}
std_tags: ${{ steps.ci_metadata_std.outputs.tags }}
commit_author: ${{ steps.set_outputs.outputs.commit_author}}
steps:
Expand Down Expand Up @@ -196,7 +197,72 @@
tags: ${{ steps.tag_metadata_ee.outputs.tags }}
labels: ${{ steps.tag_metadata_ee.outputs.labels }}
build-args: |
BUILD_PACKAGE_NAME=tyk-gateway-ee
- name: Docker metadata for fips CI
id: ci_metadata_fips
if: ${{ matrix.golang_cross == '1.24-bullseye' }}
uses: docker/metadata-action@v5
with:
images: |
${{ steps.ecr.outputs.registry }}/tyk
flavor: |
latest=false
tags: |
type=ref,event=branch
type=ref,event=pr
type=sha,format=long
type=semver,pattern={{major}},prefix=v
type=semver,pattern={{major}}.{{minor}},prefix=v
type=semver,pattern={{version}},prefix=v
- name: push fips image to CI
if: ${{ matrix.golang_cross == '1.24-bullseye' }}
uses: docker/build-push-action@v6
with:
context: "dist"
platforms: linux/amd64,linux/arm64
file: ci/Dockerfile.distroless
provenance: mode=max
sbom: true
push: true
cache-from: type=gha
cache-to: type=gha,mode=max
tags: ${{ steps.ci_metadata_fips.outputs.tags }}
labels: ${{ steps.ci_metadata_fips.outputs.labels }}
build-args: |
BUILD_PACKAGE_NAME=tyk-gateway-fips
- name: Docker metadata for fips tag push
id: tag_metadata_fips
uses: docker/metadata-action@v5
with:
images: |
tykio/tyk-gateway-fips
flavor: |
latest=false
prefix=v
tags: |
type=semver,pattern={{major}}.{{minor}}
type=semver,pattern={{version}}
labels: |
org.opencontainers.image.title=Tyk Gateway Enterprise Edition FIPS

Check warning on line 246 in .github/workflows/release.yml

View check run for this annotation

probelabs / Visor: security

security Issue 

GitHub Actions are referenced using floating major version tags (e.g., `@v5`, `@v6`). This practice can introduce unexpected breaking changes or security vulnerabilities if a new version is released under the same tag.
Raw output 
Pin actions to a specific commit SHA to ensure the workflow is deterministic and secure. For example, `uses: docker/metadata-action@599e35b...` instead of `uses: docker/metadata-action@v5`. This applies to all newly added `docker/metadata-action@v5` and `docker/build-push-action@v6` actions.
org.opencontainers.image.description=Tyk API Gateway Enterprise Edition written in Go, supporting REST, GraphQL, TCP and gRPC protocols Built with boringssl
org.opencontainers.image.vendor=tyk.io
org.opencontainers.image.version=${{ github.ref_name }}
- name: push fips image to prod
if: ${{ matrix.golang_cross == '1.24-bullseye' }}
uses: docker/build-push-action@v6
with:
context: "dist"

Check warning on line 254 in .github/workflows/release.yml

View check run for this annotation

probelabs / Visor: performance

performance Issue 

The workflow builds the FIPS docker image twice on tagged releases: once for the CI registry and a second time for the production registry. This duplicates the build process, leading to inefficient use of CI resources and longer pipeline execution times.
Raw output 
To optimize the workflow, build the image only once. A recommended pattern is to have one job that builds and pushes the image to the CI registry. Then, for tagged releases, a subsequent job can pull the image from the CI registry, re-tag it for production, and push it to the production registry. This avoids the redundant build step entirely.
platforms: linux/amd64,linux/arm64
file: ci/Dockerfile.distroless
provenance: mode=max
sbom: true
cache-from: type=gha
cache-to: type=gha,mode=max
push: ${{ startsWith(github.ref, 'refs/tags') }}
tags: ${{ steps.tag_metadata_fips.outputs.tags }}
labels: ${{ steps.tag_metadata_fips.outputs.labels }}
build-args: |

Check warning on line 264 in .github/workflows/release.yml

View check run for this annotation

probelabs / Visor: architecture

architecture Issue 

The GitHub Actions workflow adds a series of steps for building and pushing FIPS Docker images (lines 204-264) that are almost a direct copy of the existing steps for standard images. This duplication makes the workflow file verbose and harder to maintain.
Raw output 
To reduce this duplication, abstract the common logic into a reusable workflow or a composite action. This new workflow/action could accept parameters such as the package name (`tyk-gateway-fips` vs. `tyk-gateway`), target platforms, and image name, allowing you to invoke it for both FIPS and standard builds with minimal repeated code.
BUILD_PACKAGE_NAME=tyk-gateway-fips
- name: Docker metadata for std CI
id: ci_metadata_std
if: ${{ matrix.golang_cross == '1.24-bullseye' }}

Check warning on line 268 in .github/workflows/release.yml

View check run for this annotation

probelabs / Visor: quality

architecture Issue 

The workflow adds a large, duplicated block of steps for building and pushing FIPS Docker images. This pattern is likely repeated for other image types (std, ee), making the workflow file long, hard to read, and difficult to maintain. Any change to the build/push logic must be manually synchronized across multiple sections.
Raw output 
Refactor the workflow to use GitHub Actions' reusable workflows or composite actions. A reusable workflow could encapsulate the logic for metadata generation and image pushing, taking parameters like image name, package name, and other variants. This would significantly reduce duplication and improve maintainability.
Expand Down
15 changes: 13 additions & 2 deletions ci/Dockerfile.distroless
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,12 @@
# Generated by: gromit policy

FROM debian:trixie-slim AS deb
# Build stage base selection: FIPS for amd64/arm64, standard debian for s390x
FROM tykio/dhi-debian-base:trixie-debian13-fips AS deb-base-amd64
FROM tykio/dhi-debian-base:trixie-debian13-fips AS deb-base-arm64

Check warning on line 5 in ci/Dockerfile.distroless

View check run for this annotation

probelabs / Visor: security

security Issue 

The change introduces a dependency on a new base image, `tykio/dhi-debian-base:trixie-debian13-fips`. The security of the final product is highly dependent on the maintenance and security posture of this base image.
Raw output 
Ensure that this new base image is regularly scanned for vulnerabilities and has a clear maintenance policy. Consider integrating container scanning for the final built images into the CI/CD pipeline to detect vulnerabilities inherited from the base image.
FROM debian:trixie-slim AS deb-base-s390x

Check warning on line 7 in ci/Dockerfile.distroless

View check run for this annotation

probelabs / Visor: security

security Issue 

Base images in `ci/Dockerfile.distroless` and `ci/Dockerfile.std` are specified using mutable tags (e.g., `:trixie-debian13-fips`, `:trixie-slim`, `:latest`). This can lead to unpredictable behavior in the build pipeline if the image tag is updated, and poses a security risk if the tag is overwritten with a compromised image. Builds will not be reproducible.
Raw output 
Pin base images to their immutable SHA256 digest to ensure build reproducibility and security. For example, `FROM tykio/dhi-debian-base:trixie-debian13-fips@sha256:deadbeef...`.
ARG TARGETARCH
FROM deb-base-${TARGETARCH} AS deb
ARG TARGETARCH
ARG BUILD_PACKAGE_NAME

Expand All @@ -10,7 +16,12 @@
COPY ${BUILD_PACKAGE_NAME}_*${TARGETARCH}.deb /
RUN dpkg -i /${BUILD_PACKAGE_NAME}_*${TARGETARCH}.deb && rm /*.deb

FROM gcr.io/distroless/base-debian12:latest
# Runtime base selection: FIPS for amd64/arm64, distroless for s390x
FROM tykio/dhi-debian-base:trixie-debian13-fips AS runtime-amd64
FROM tykio/dhi-debian-base:trixie-debian13-fips AS runtime-arm64
FROM gcr.io/distroless/base-debian12:latest AS runtime-s390x

FROM runtime-${TARGETARCH}

COPY --from=deb /opt/tyk-gateway /opt/tyk-gateway

Expand Down
8 changes: 7 additions & 1 deletion ci/Dockerfile.std
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,12 @@
# Generated by: gromit policy

FROM debian:trixie-slim
# Base image selection: FIPS for amd64/arm64, standard debian for s390x
FROM tykio/dhi-debian-base:trixie-debian13-fips AS base-amd64
FROM tykio/dhi-debian-base:trixie-debian13-fips AS base-arm64
FROM debian:trixie-slim AS base-s390x

ARG TARGETARCH
FROM base-${TARGETARCH}
ARG TARGETARCH
ARG BUILD_PACKAGE_NAME

Expand Down
100 changes: 100 additions & 0 deletions ci/goreleaser/goreleaser.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -57,117 +57,211 @@
goarch:
- s390x
binary: tyk
- id: fips-amd64
flags:
- -tags=goplugin,ee,fips,boringcrypto
- -trimpath
env:
- NOP=nop # ignore this, it is jsut to avoid a complex conditional in the templates
- CC=gcc
- GOEXPERIMENT=boringcrypto
ldflags:
- -X github.com/TykTechnologies/tyk/internal/build.Version={{.Version}}
- -X github.com/TykTechnologies/tyk/internal/build.Commit={{.FullCommit}}
- -X github.com/TykTechnologies/tyk/internal/build.BuildDate={{.Date}}
- -X github.com/TykTechnologies/tyk/internal/build.BuiltBy=goreleaser
goos:
- linux
goarch:
- amd64
binary: tyk
- id: fips-arm64
flags:
- -tags=goplugin,ee,fips,boringcrypto
- -trimpath
env:
- NOP=nop # ignore this, it is jsut to avoid a complex conditional in the templates
- CC=aarch64-linux-gnu-gcc
- GOEXPERIMENT=boringcrypto
ldflags:
- -X github.com/TykTechnologies/tyk/internal/build.Version={{.Version}}
- -X github.com/TykTechnologies/tyk/internal/build.Commit={{.FullCommit}}
- -X github.com/TykTechnologies/tyk/internal/build.BuildDate={{.Date}}
- -X github.com/TykTechnologies/tyk/internal/build.BuiltBy=goreleaser
goos:
- linux
goarch:
- arm64
binary: tyk
- id: std-amd64
flags:
- -tags=goplugin
- -trimpath
env:
- NOP=nop # ignore this, it is jsut to avoid a complex conditional in the templates
- CC=gcc
ldflags:
- -X github.com/TykTechnologies/tyk/internal/build.Version={{.Version}}
- -X github.com/TykTechnologies/tyk/internal/build.Commit={{.FullCommit}}
- -X github.com/TykTechnologies/tyk/internal/build.BuildDate={{.Date}}
- -X github.com/TykTechnologies/tyk/internal/build.BuiltBy=goreleaser
goos:
- linux
goarch:
- amd64
binary: tyk
- id: std-arm64
flags:
- -tags=goplugin
- -trimpath
env:
- NOP=nop # ignore this, it is jsut to avoid a complex conditional in the templates
- CC=aarch64-linux-gnu-gcc
ldflags:
- -X github.com/TykTechnologies/tyk/internal/build.Version={{.Version}}
- -X github.com/TykTechnologies/tyk/internal/build.Commit={{.FullCommit}}
- -X github.com/TykTechnologies/tyk/internal/build.BuildDate={{.Date}}
- -X github.com/TykTechnologies/tyk/internal/build.BuiltBy=goreleaser
goos:
- linux
goarch:
- arm64
binary: tyk
- id: std-s390x
flags:
- -tags=goplugin
- -trimpath
env:
- NOP=nop # ignore this, it is jsut to avoid a complex conditional in the templates
- CC=s390x-linux-gnu-gcc
ldflags:
- -X github.com/TykTechnologies/tyk/internal/build.Version={{.Version}}
- -X github.com/TykTechnologies/tyk/internal/build.Commit={{.FullCommit}}
- -X github.com/TykTechnologies/tyk/internal/build.BuildDate={{.Date}}
- -X github.com/TykTechnologies/tyk/internal/build.BuiltBy=goreleaser
goos:
- linux
goarch:
- s390x
binary: tyk
nfpms:
- id: ee
vendor: "Tyk Technologies Ltd"
homepage: "https://tyk.io"
maintainer: "Tyk <info@tyk.io>"
description: Tyk API Gateway Enterprise Edition written in Go, supporting REST, GraphQL, TCP and gRPC protocols
package_name: tyk-gateway-ee
file_name_template: "{{ .ConventionalFileName }}"
ids:
- ee-amd64
- ee-arm64
- ee-s390x
formats:
- deb
- rpm
contents:
- src: "README.md"
dst: "/opt/share/docs/tyk-gateway/README.md"
- src: "ci/install/*"
dst: "/opt/tyk-gateway/install"
- src: ci/install/inits/systemd/system/tyk-gateway.service
dst: /lib/systemd/system/tyk-gateway.service
- src: ci/install/inits/sysv/init.d/tyk-gateway
dst: /etc/init.d/tyk-gateway
- src: /opt/tyk-gateway
dst: /opt/tyk
type: "symlink"
- src: "LICENSE.md"
dst: "/opt/share/docs/tyk-gateway/LICENSE.md"
- src: "apps/app_sample.*"
dst: "/opt/tyk-gateway/apps"
- src: "templates/*.json"
dst: "/opt/tyk-gateway/templates"
- src: "templates/playground/*"
dst: "/opt/tyk-gateway/templates/playground"
- src: "middleware/*.js"
dst: "/opt/tyk-gateway/middleware"
- src: "event_handlers/sample/*.js"
dst: "/opt/tyk-gateway/event_handlers/sample"
- src: "policies/*.json"
dst: "/opt/tyk-gateway/policies"
- src: "coprocess/*"
dst: "/opt/tyk-gateway/coprocess"
- src: tyk.conf.example
dst: /opt/tyk-gateway/tyk.conf
type: "config|noreplace"
scripts:
preinstall: "ci/install/before_install.sh"
postinstall: "ci/install/post_install.sh"
postremove: "ci/install/post_remove.sh"
bindir: "/opt/tyk-gateway"
rpm:
scripts:
posttrans: ci/install/post_trans.sh
signature:
key_file: tyk.io.signing.key
deb:
signature:
key_file: tyk.io.signing.key
type: origin
- id: fips
vendor: "Tyk Technologies Ltd"
homepage: "https://tyk.io"
maintainer: "Tyk <info@tyk.io>"
description: Tyk API Gateway Enterprise Edition written in Go, supporting REST, GraphQL, TCP and gRPC protocols Built with boringssl
package_name: tyk-gateway-fips
file_name_template: "{{ .ConventionalFileName }}"
ids:
- fips-amd64
- fips-arm64
formats:
- deb
- rpm
contents:
- src: "README.md"
dst: "/opt/share/docs/tyk-gateway/README.md"
- src: "ci/install/*"
dst: "/opt/tyk-gateway/install"
- src: ci/install/inits/systemd/system/tyk-gateway.service
dst: /lib/systemd/system/tyk-gateway.service
- src: ci/install/inits/sysv/init.d/tyk-gateway
dst: /etc/init.d/tyk-gateway
- src: /opt/tyk-gateway
dst: /opt/tyk
type: "symlink"

Check failure on line 231 in ci/goreleaser/goreleaser.yml

View check run for this annotation

probelabs / Visor: architecture

architecture Issue 

The GoReleaser configuration for FIPS builds introduces a large amount of duplication. The `nfpms` package definition for `fips` (lines 174-231) is nearly identical to its `std` counterpart, as are the new `builds` (lines 63-104) and `publishers` (lines 240-245) sections. This violates the DRY principle and increases maintenance overhead, as future changes will need to be applied in multiple places.
Raw output 
Refactor the configuration to use YAML anchors and aliases. A common configuration block can be defined for shared settings (like `contents`, `scripts`, etc. in `nfpms`) and then merged into both the `fips` and `std` definitions. This will significantly reduce duplication and improve maintainability.
- src: "LICENSE.md"
dst: "/opt/share/docs/tyk-gateway/LICENSE.md"
- src: "apps/app_sample.*"
dst: "/opt/tyk-gateway/apps"
- src: "templates/*.json"
dst: "/opt/tyk-gateway/templates"
- src: "templates/playground/*"
dst: "/opt/tyk-gateway/templates/playground"
- src: "middleware/*.js"
dst: "/opt/tyk-gateway/middleware"

Check warning on line 241 in ci/goreleaser/goreleaser.yml

View check run for this annotation

probelabs / Visor: quality

architecture Issue 

The GoReleaser configuration introduces significant duplication for the new FIPS build. The `builds` for `fips-amd64` and `fips-arm64` are nearly identical, and the `nfpms` and `publishers` sections for `fips` are large blocks of configuration that appear to be copied from existing definitions. This makes the file harder to maintain, as any change to packaging or publishing logic will need to be replicated.
Raw output 
To improve maintainability, refactor this configuration to reduce duplication. For the `builds` section, consolidate `fips-amd64` and `fips-arm64` into a single definition using GoReleaser's matrix-like features or templating (e.g., setting `CC` based on `{{ .Arch }}`). For the `nfpms` and `publishers` sections, use YAML anchors and aliases to define common configuration blocks once and reuse them across different package types.
- src: "event_handlers/sample/*.js"
dst: "/opt/tyk-gateway/event_handlers/sample"
- src: "policies/*.json"
dst: "/opt/tyk-gateway/policies"
- src: "coprocess/*"
dst: "/opt/tyk-gateway/coprocess"
- src: tyk.conf.example
dst: /opt/tyk-gateway/tyk.conf
type: "config|noreplace"
scripts:
preinstall: "ci/install/before_install.sh"
postinstall: "ci/install/post_install.sh"
postremove: "ci/install/post_remove.sh"
bindir: "/opt/tyk-gateway"
rpm:
scripts:
posttrans: ci/install/post_trans.sh
signature:
key_file: tyk.io.signing.key
deb:
signature:
key_file: tyk.io.signing.key
type: origin
- id: std
vendor: "Tyk Technologies Ltd"
homepage: "https://tyk.io"
Expand Down Expand Up @@ -234,6 +328,12 @@
env:
- PACKAGECLOUD_TOKEN={{ .Env.PACKAGECLOUD_TOKEN }}
cmd: packagecloud publish --debvers "{{ .Env.DEBVERS }}" --rpmvers "{{ .Env.RPMVERS }}" tyk/tyk-ee-unstable {{ .ArtifactPath }}
- name: fips
ids:
- fips
env:
- PACKAGECLOUD_TOKEN={{ .Env.PACKAGECLOUD_TOKEN }}
cmd: packagecloud publish --debvers "{{ .Env.DEBVERS }}" --rpmvers "{{ .Env.RPMVERS }}" tyk/tyk-ee-unstable {{ .ArtifactPath }}
- name: std
ids:
- std
Expand Down
Loading