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. see this ticket. Changes to FIPS documentation may be required.

Related Issue

There are also PRs with the same branch name on the following repos tyk tyk-sink tyk-analytics

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

An analysis of the pull request is provided below, based on the submitted changes.

1. Change Impact Analysis

What this PR accomplishes

This pull request introduces the capability to build and release FIPS-compliant Docker images for Tyk Pump. This is a new feature driven by a customer requirement for environments that need FIPS compliance. The key outcome is a new Docker image, tykio/tyk-pump-fips, which is built using a FIPS-compliant Go binary.

Key technical changes introduced

1. FIPS-Compliant Go Build: The GoReleaser configuration (ci/goreleaser/goreleaser.yml) is updated to use the GOEXPERIMENT=boringcrypto flag when building the fips-amd64 binary. This flag enables Go's integration with BoringCrypto, which provides FIPS 140-2 validated cryptographic modules.

2. New Docker Image for FIPS: The GoReleaser configuration now defines a new Docker image build process for tykio/tyk-pump-fips. This image is specifically for the amd64 architecture.

3. CI/CD Workflow Updates: The GitHub Actions release workflow (.github/workflows/release.yml) has been significantly extended. It now includes steps to:

   • Generate metadata (tags and labels) for the FIPS Docker image.
   • Build and push the FIPS image to both a CI registry (ECR) and the production registry (tykio/tyk-pump-fips) upon a tag event.
   • The build process uses a distroless base image for a smaller footprint, as specified by file: ci/Dockerfile.distroless.

4. Configuration Refactoring:

   • The ci/Dockerfile.std has been slightly modified to be more generic. It now uses a BUILD_PACKAGE_NAME argument to locate the correct .deb package, allowing the same Dockerfile to be used for both standard and FIPS builds.
   • The .gitignore file is updated to exclude the dist/ directory, which is where GoReleaser places build artifacts.

Affected system components

• Build & Release Pipeline: The primary impact is on the project's CI/CD pipeline. The release process is now more complex, producing two distinct sets of Docker images (standard multi-arch and FIPS single-arch).
• Docker Image Consumers: Users and customers now have the option to pull a FIPS-compliant image. This affects deployment scripts, documentation, and operational procedures for teams that require FIPS compliance.
• GoReleaser Configuration: The goreleaser.yml file is now the central point for defining all Docker image builds and manifests, consolidating what might have been separate processes before.

2. Architecture Visualization

The following diagram illustrates the updated build and release process, highlighting the new FIPS image pipeline alongside the existing standard one.

graph TD
    subgraph "GitHub Actions: release.yml"
        A[Git Tag Push] --> B{Prepare Job};

        B --> C[Run GoReleaser];
        
        subgraph "GoReleaser Build"
            C --> D{Build Binaries};
            D -- GOEXPERIMENT=boringcrypto --> E[tyk-pump-fips amd64 binary];
            D -- Standard build --> F[tyk-pump std amd64/arm64 binaries];
        end

        subgraph "Docker Image Build & Push"
            C --> G{Build Docker Images};
            G -- Based on FIPS binary --> H(Build tyk-pump-fips Image);
            G -- Based on std binaries --> I(Build tyk-pump Images);

            H --> J[Push to tykio/tyk-pump-fips];
            I --> K[Push to tykio/tyk-pump-docker-pub];
        end

        subgraph "Docker Manifests"
            J --> L[Create Single-Arch FIPS Manifest];
            K --> M[Create Multi-Arch Standard Manifest];
        end
    end

    subgraph "Artifacts"
        L --> N[Image: tykio/tyk-pump-fips:vX.Y.Z-fips];
        M --> O[Image: tykio/tyk-pump-docker-pub:vX.Y.Z];
    end

    style E fill:#cce5ff,stroke:#333,stroke-width:2px
    style H fill:#cce5ff,stroke:#333,stroke-width:2px
    style J fill:#cce5ff,stroke:#333,stroke-width:2px
    style L fill:#cce5ff,stroke:#333,stroke-width:2px
    style N fill:#cce5ff,stroke:#333,stroke-width:2px

Loading

Diagram Explanation:

1. The process starts when a new Git tag is pushed, triggering the release.yml workflow.
2. The central GoReleaser step now has two parallel paths for building binaries: one for standard (std) and a new one for FIPS. The FIPS path is distinguished by the GOEXPERIMENT=boringcrypto flag.
3. Based on these binaries, corresponding Docker images are built. The new tyk-pump-fips image is created from the FIPS binary.
4. Finally, the images are pushed to Docker Hub (tykio), and manifests are created. The FIPS image gets a single-architecture manifest, while the standard image gets a multi-architecture manifest for amd64 and arm64.

---

Powered by Visor from Probelabs

Last updated: 2025-09-23T18:04:45.822Z | Triggered by: synchronize | Commit: 571a7c4

[probelabs]

🔍 Code Analysis Results

Security Issues (3)

Severity	Location	Issue
🟢 Info	.github/workflows/release.yml:51	The GitHub Actions workflow does not define job-level permissions, causing it to run with default, potentially overly broad, permissions for the `GITHUB_TOKEN`. This violates the principle of least privilege. 💡 Suggestion Add a `permissions` block to the `release` job to scope the `GITHUB_TOKEN`'s access to the minimum required for its tasks. For example: ```yaml permissions: contents: read id-token: write packages: write ```
🟢 Info	ci/Dockerfile.std:24	The Dockerfile does not create or switch to a non-root user. Running containers as the root user is a security risk, as it reduces the defense-in-depth against container breakout vulnerabilities. 💡 Suggestion Modify the Dockerfile to create a non-privileged user and switch to it before setting the `ENTRYPOINT` or `CMD`. This hardening step should be applied to the `ci/Dockerfile.distroless` used in the final release build. Example: ```dockerfile RUN groupadd --system nonroot && useradd --system --gid nonroot nonroot USER nonroot ```
🟡 Warning	ci/goreleaser/goreleaser.yml:160-259	The CI workflow defines two different ways to build and publish Docker images: one via GoReleaser's `dockers` configuration and another via explicit `docker/build-push-action` steps in the GitHub workflow. This creates ambiguity and could lead to inconsistent builds, as they use different Dockerfiles (`ci/Dockerfile.std` vs. `ci/Dockerfile.distroless`). 💡 Suggestion Consolidate the Docker build logic into a single source of truth. The recommended approach is to use the `docker/build-push-action` steps in the GitHub Actions workflow, as they are more transparent and use the preferred distroless image. Remove the `dockers` and `docker_manifests` sections from `ci/goreleaser/goreleaser.yml`.

Performance Issues (2)

Severity	Location	Issue
🟢 Info	ci/goreleaser/goreleaser.yml:15	The introduction of `GOEXPERIMENT=boringcrypto` and the `fips,boringcrypto` build tags switches the underlying cryptographic implementation to BoringSSL for the FIPS build. This will alter the performance characteristics of cryptographic functions compared to the standard Go crypto library. While this is necessary for FIPS compliance, it's important to be aware of the potential performance shift. 💡 Suggestion If cryptographic performance is a critical aspect of the service, consider benchmarking the FIPS-enabled binary against the standard version to quantify any differences and ensure they are within acceptable limits.
🟢 Info	.github/workflows/release.yml:60-124	Adding steps to build and push FIPS-compliant Docker images will increase the overall execution time of the release workflow. This is an expected trade-off for supporting an additional build artifact. 💡 Suggestion The workflow correctly utilizes GitHub Actions caching (`cache-from: type=gha`, `cache-to: type=gha,mode=max`), which is a best practice that helps mitigate the increased build time by reusing cached layers from previous runs. No immediate action is required, but it's good to monitor the pipeline's duration.

Quality Issues (2)

Severity	Location	Issue
🟡 Warning	ci/goreleaser/goreleaser.yml:160-255	The `dockers` and `docker_manifests` configurations contain significant duplication. The definitions for `fips-amd64`, `std-amd64`, and `std-arm64` share many common properties like `use`, `goos`, `dockerfile`, and `extra_files`. Similarly, the `docker_manifests` for different tags are repetitive. This duplication makes the configuration harder to maintain, as changes may need to be applied in multiple places, increasing the risk of inconsistencies. 💡 Suggestion To improve maintainability and reduce redundancy, consider using YAML anchors and aliases. You can define a base template for the docker build and manifest configurations and then extend it for each specific variant (fips, std, amd64, arm64). This would centralize the common configuration and make future updates simpler.
🟡 Warning	.github/workflows/release.yml:132-202	The GitHub Actions workflow introduces a set of steps for building and pushing the FIPS Docker image that are nearly identical to the steps for the standard image. This includes metadata generation, building, and pushing for both CI and production releases. This duplication makes the workflow file longer and more difficult to maintain. A change in the build process (e.g., updating the build action version, changing labels, or modifying caching strategy) would need to be manually synchronized across both FIPS and standard build steps. 💡 Suggestion To make the workflow more maintainable and adhere to the DRY (Don't Repeat Yourself) principle, refactor the duplicated steps into a reusable workflow or a composite action. This would allow you to define the build-and-push logic once and invoke it with different parameters (e.g., image name, build arguments) for the FIPS and standard images.

Style Issues (2)

Severity	Location	Issue
🟢 Info	ci/goreleaser/goreleleaser.yml:170-240	The `dockers` section contains significant duplication. The `extra_files` list and many `build_flag_templates` are identical across multiple docker build configurations. 💡 Suggestion To improve maintainability and reduce redundancy, consider using YAML anchors and aliases to define common blocks of configuration once and reuse them. For example, the `extra_files` list can be defined as an anchor and referenced in each docker configuration.
🟢 Info	ci/goreleaser/goreleleaser.yml:241-264	The `docker_manifests` section contains duplicated `image_templates` for different tag formats (e.g., full tag, major.minor, major). 💡 Suggestion While `goreleaser`'s configuration schema might limit the use of anchors within `name_template` and `image_templates` combinations, it's worth reviewing if a more concise structure can be achieved to avoid repeating the list of images for each manifest tag version.

---

Powered by Visor from Probelabs

Last updated: 2025-09-23T18:04:46.858Z | Triggered by: synchronize | Commit: 571a7c4