Add docker images built using FIPS binaries

[Razeen-Abdal-Rahman]

Description

Auto generated changes by gromit to add fips compliant docker images to releases. These changes are in response to a customer request for fips compliant docker images. These are provided by using our existing fips binaries in a distroless image. THESE ARE NOT FIPS VALIDATED IMAGES. Tyk's FIPS documentation has been updated as a result of this request.

Related Issue

see this ticket. A PR has also been made against branch master on tyk-sink

Motivation and Context

These images were request to be included in regular releases by a client.

How This Has Been Tested

goreleaser was run locally, everything seems okay a fips image is built using the fips binary. More end to end testing is needed with the other fips components.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• Make sure you are requesting to pull a topic/feature/bugfix branch (right side). If pulling from your own
  fork, don't request your master!
• Make sure you are making a pull request against the master branch (left side). Also, you should start
  your branch off our latest master.
• My change requires a change to the documentation.
  • If you've changed APIs, describe what needs to be updated in the documentation.
• I have updated the documentation accordingly.
• Modules and vendor dependencies have been updated; run go mod tidy && go mod vendor
• I have added tests to cover my changes.
• All new and existing tests passed.
• Check your code additions will not fail linting checks:
  • go fmt -s
  • go vet

[probelabs]

🔍 Code Analysis Results

1. Change Impact Analysis

What this PR accomplishes

This pull request introduces the capability to build and release FIPS-compliant, multi-architecture Docker images for tyk-pump. Responding to a customer request, it extends FIPS support beyond the existing amd64 architecture to include arm64 and s390x. This is achieved by using Go's boringcrypto library to compile FIPS-compliant binaries for each architecture and then packaging them into separate Docker images. Finally, these images are grouped under a single multi-architecture manifest, simplifying distribution and usage for consumers on different platforms. The PR also adds s390x support for the standard (non-FIPS) Docker image.

Key Technical Changes

The core of the changes lies in the CI/CD configuration files:

1. GoReleaser Configuration (ci/goreleaser/goreleaser.yml):

   • New Build Definitions: Two new build IDs, fips-arm64 and fips-s390x, are added. These builds are configured with the fips,boringcrypto tags and the GOEXPERIMENT=boringcrypto environment variable, which instructs the Go compiler to use the FIPS 140-2 validated BoringCrypto module.
   • Multi-Arch Docker Builds: The dockers section is expanded to create architecture-specific Docker images for fips-arm64 and fips-s390x.
   • Multi-Arch Manifests: The docker_manifests section is updated to group the newly created arm64 and s390x images with the existing amd64 image. This allows users to pull a tag like tykio/tyk-pump-fips:vX.Y.Z-fips and have the container runtime automatically select the correct image for their machine's architecture.

2. GitHub Actions Workflow (.github/workflows/release.yml):

   • The docker/build-push-action steps are modified to build for multiple platforms simultaneously by changing platforms: linux/amd64 to platforms: linux/amd64,linux/arm64,linux/s390x. This enables the workflow to produce the multi-architecture images required by the GoReleaser configuration.

Affected System Components

• CI/CD Release Pipeline: The primary impact is on the release process. The pipeline will now execute additional build steps for the new architectures, create corresponding Docker images, and publish multi-arch manifests to the container registry.
• Release Artifacts: The set of release artifacts is expanded to include:
  • FIPS-compliant binaries for linux/arm64 and linux/s390x.
  • Multi-architecture Docker images for both FIPS (tykio/tyk-pump-fips) and standard (tykio/tyk-pump-docker-pub) builds.

2. Architecture Visualization

The following diagram illustrates the updated build and release process for FIPS-compliant Docker images.

flowchart TD
    subgraph "GoReleaser Build Process"
        A[Trigger Release] --> B{Build Binaries};
        B --> C1[Build fips-amd64];
        B --> C2[Build fips-arm64];
        B --> C3[Build fips-s390x];
    end

    subgraph "Docker Image Creation (via buildx)"
        C1 --> D1[Create tyk-pump-fips:tag-fips-amd64 Image];
        C2 --> D2[Create tyk-pump-fips:tag-fips-arm64 Image];
        C3 --> D3[Create tyk-pump-fips:tag-fips-s390x Image];
    end

    subgraph "Docker Manifest Publication"
        D1 --> E{Combine into Multi-Arch Manifest};
        D2 --> E;
        D3 --> E;
        E -- "tykio/tyk-pump-fips:tag-fips" --> F[Push to Container Registry];
    end

    subgraph "End User"
        G[User on amd64] -- "docker pull" --> F;
        H[User on arm64] -- "docker pull" --> F;
        I[User on s390x] -- "docker pull" --> F;
    end

    style F fill:#cde4ff,stroke:#333,stroke-width:2px

Loading

This diagram shows how GoReleaser now builds binaries for three different architectures in parallel. Each binary is then used to create a platform-specific Docker image. Finally, these individual images are linked together by a single multi-architecture manifest, which is pushed to the container registry. This allows users on any of the supported platforms to pull the correct image using a single, consistent tag.

---

Powered by Visor from Probelabs

Last updated: 2025-10-01T08:24:02.596Z | Triggered by: opened | Commit: 2bf9ec9

[probelabs]

🔍 Code Analysis Results

Security Issues (1)

Severity	Location	Issue
🟢 Info	ci/goreleaser/goreleaser.yml:1	The term 'FIPS compliant' can be misinterpreted. While the binaries are built with FIPS-enabled cryptographic libraries, the resulting Docker images are not officially FIPS 140-2/3 validated. This distinction is important for users in regulated environments. 💡 Suggestion Ensure that all public-facing documentation, release notes, and image descriptions clearly state that the images are 'built with FIPS-compliant binaries' but are not themselves 'FIPS validated'. This manages user expectations and prevents potential compliance issues on their end.

Performance Issues (2)

Severity	Location	Issue
🟢 Info	ci/goreleaser/goreleaser.yml:24-60	The addition of `fips-arm64` and `fips-s390x` builds, along with corresponding Docker image creation and manifest updates, will increase the overall CI pipeline execution time and resource consumption. While necessary for multi-architecture support, this can slow down the release process. 💡 Suggestion Monitor the execution time of the release workflow. If it becomes excessively long, consider optimizing the build process. This could involve using more powerful self-hosted runners, optimizing Docker layer caching across workflow runs, or investigating if `goreleaser` can parallelize more of the build steps.
🟢 Info	.github/workflows/release.yml:154	Building Docker images for multiple platforms (`linux/amd64`, `linux/arm64`, `linux/s390x`) in a single step will increase the duration of the 'build-push-action'. This change is also present on line 187. 💡 Suggestion This is an expected consequence of supporting multi-arch images. Ensure that Docker layer caching is effectively configured for the `build-push-action` to minimize rebuilds of unchanged layers, which can help mitigate the increase in build time.

Quality Issues (1)

Severity	Location	Issue
🟡 Warning	ci/goreleaser/goreleaser.yml:24-260	The `goreleaser.yml` configuration contains significant duplication across the `builds` and `dockers` sections for different architectures (amd64, arm64, s390x). Common properties like `ldflags`, `env`, `build_flag_templates`, and `extra_files` are repeated for each architecture. 💡 Suggestion To improve maintainability and reduce redundancy, use YAML anchors and aliases. Define common configuration blocks once and reference them where needed. This will make the file shorter, easier to read, and less error-prone when making future changes.

Style Issues (1)

Severity	Location	Issue
🟡 Warning	ci/goreleaser/goreleaser.yml:25-232	The configuration for `arm64` and `s390x` architectures in the `builds` and `dockers` sections is heavily duplicated from the existing `amd64` configuration. This copy-paste approach increases maintenance overhead, as any future changes to build flags, labels, or file lists must be manually replicated across all architecture-specific blocks. This makes the configuration file verbose, error-prone, and difficult to manage. 💡 Suggestion To improve maintainability and reduce redundancy, refactor the `builds` and `dockers` configurations to use GoReleaser's `matrix` feature. A matrix allows you to define a single configuration block that generates multiple builds and Docker images based on a set of variables, such as the target architecture. This will significantly simplify the file and ensure consistency across all builds. Example for builds: builds: - id: fips matrix: goarch: - amd64 - arm64 - s390x flags: - -tags=fips,boringcrypto env: - GOEXPERIMENT=boringcrypto ldflags: - -X github.com/TykTechnologies/tyk-pump/pumps.Version={{.Version}} - -X github.com/TykTechnologies/tyk-pump/pumps.Commit={{.FullCommit}} - -X github.com/TykTechnologies/tyk-pump/pumps.BuildDate={{.Date}} - -X github.com/TykTechnologies/tyk-pump/pumps.BuiltBy=goreleaser goos: - linux binary: tyk-pump Example for dockers: dockers: - matrix: goarch: - amd64 - arm64 - s390x ids: - fips image_templates: - &#34;tykio/tyk-pump-fips:{{.Tag}}-fips-{{.Arch}}&#34; build_flag_templates: - &#34;--platform=linux/{{.Arch}}&#34; # ... other flags use: buildx goos: linux dockerfile: ci/Dockerfile.std extra_files: - &#34;ci/install/&#34; - &#34;README.md&#34; - &#34;dist/&#34; - &#34;LICENSE.md&#34; - &#34;pump.example.conf&#34; ```</details> </div></td> </tr> </tbody> </table> --- *Powered by [Visor](https://probelabs.com/visor) from [Probelabs](https://probelabs.com)* *Last updated: 2025-10-01T08:24:03.528Z | Triggered by: opened | Commit: 2bf9ec9* <!-- /visor-comment-id:pr-review-897-review -->