Add docker images built using FIPS binaries

[Razeen-Abdal-Rahman]

User description

TT-15334

Summary	Docker Images for FIPS Components
Type	Task
Status	In Dev
Points	N/A
Labels	jira_escalated, sysEng

---

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

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. There are also PRs with the same branch name on the following repos tyk-pump 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

---

PR Type

Enhancement, Other

---

Description

• Add FIPS Docker image build and publish

• Extend CI with FIPS image metadata/tags

• Configure goreleaser for FIPS/std/EE images

• Tweak Dockerfile install and cleanup paths

---

Diagram Walkthrough

flowchart LR
  CI["GitHub Actions release.yml"]
  MetaFIPS["metadata-action fips tags/labels"]
  BuildFIPSCI["build-push-action fips CI (distroless)"]
  BuildFIPSProd["build-push-action fips prod (tags)"]
  GoReleaser["goreleaser.yml"]
  Images["Docker images: EE, STD, FIPS"]
  Manifests["Docker manifests (std multi-arch, fips single-arch)"]
  Dockerfile["ci/Dockerfile.std updates"]

  CI -- "adds fips_tags output" --> MetaFIPS
  CI -- "push CI/prod fips images" --> BuildFIPSCI
  CI -- "push prod on tag" --> BuildFIPSProd
  GoReleaser -- "define buildx images & manifests" --> Images
  GoReleaser -- "publish manifests" --> Manifests
  Dockerfile -- "install from dist, cleanup" --> Images

Loading

File Walkthrough

	Relevant files
Configuration changes	release.yml CI workflow adds FIPS image build and publish                        .github/workflows/release.yml Add FIPS CI metadata and tags. Build/push FIPS distroless image to CI and prod. Set FIPS image labels and build args. Expose fips_tags as workflow output. +66/-0    goreleaser.yml Goreleaser config for FIPS/STD/EE Docker images                    ci/goreleaser/goreleaser.yml Set GOEXPERIMENT=boringcrypto for FIPS build. Define Docker images for EE, STD, and FIPS. Add buildx flags, extra files, labels, platforms. Add manifests (std multi-arch, fips single-arch). +184/-1
Enhancement	Dockerfile.std Standard Dockerfile installs from dist and cleans                ci/Dockerfile.std Install package from dist using BUILD_PACKAGE_NAME. Adjust cleanup paths for apt/cache/logs. Remove old COPY/dpkg patterns. +5/-5

---

[buger]

Let's make that PR title a 💯 shall we? 💪

Your PR title and story title look slightly different. Just checking in to know if it was intentional!

Story Title	Docker Images for FIPS Components
PR Title	Add docker images built using FIPS binaries

Check out this guide to learn more about PR best-practices.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review CI Consistency CI pushes FIPS images unconditionally (push: true) for CI but only tags-based for prod; verify this aligns with intended behavior and does not publish unintended images from non-tag branches. - 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 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 Cleanup Paths The new cleanup line drops /var/lib/apt but not /var/lib/dpkg and changes the dev comment placement; confirm no package manager metadata is needed later and that the dpkg install step occurs before removing apt state. # Clean up caches, unwanted .a and .o files RUN rm -rf /root/.cache \ && apt-get -y autoremove \ && apt-get clean \ && rm -rf /usr/include/* /var/cache/apt/archives /var/lib/apt /var/lib/cache /var/log/* \ && find /usr/lib -type f -name '*.a' -o -name '*.o' -delete Tag/Manifest Scheme Image templates add suffixes (-ee-, -std-, -fips-*) and separate manifest names; ensure downstream tooling and docs expect these tag formats and that FIPS images intentionally ship only amd64. dockers: # Build tykio/tyk-gateway-ee ee (amd64) - ids: - ee-amd64 image_templates: - "tykio/tyk-gateway-ee:{{.Tag}}-ee-amd64" build_flag_templates: - "--build-arg=PORTS=8080" - "--build-arg=BUILD_PACKAGE_NAME=tyk-gateway-ee" - "--platform=linux/amd64" - "--label=org.opencontainers.image.created={{.Date}}" - "--label=org.opencontainers.image.title={{.ProjectName}} Enterprise Edition" - "--label=org.opencontainers.image.revision={{.FullCommit}}" - "--label=org.opencontainers.image.version={{.Version}}" use: buildx goarch: amd64 goos: linux dockerfile: ci/Dockerfile.std extra_files: - "ci/install/" - "README.md" - "dist/" - "LICENSE.md" - "apps/app_sample.json" - "templates" - "middleware" - "event_handlers/sample" - "policies" - "coprocess" - "tyk.conf.example" # Build tykio/tyk-gateway-ee ee (arm64) - ids: - ee-arm64 image_templates: - "tykio/tyk-gateway-ee:{{.Tag}}-ee-arm64" build_flag_templates: - "--build-arg=PORTS=8080" - "--build-arg=BUILD_PACKAGE_NAME=tyk-gateway-ee" - "--platform=linux/arm64" - "--label=org.opencontainers.image.created={{.Date}}" - "--label=org.opencontainers.image.title={{.ProjectName}} Enterprise Edition" - "--label=org.opencontainers.image.revision={{.FullCommit}}" - "--label=org.opencontainers.image.version={{.Version}}" use: buildx goarch: arm64 goos: linux dockerfile: ci/Dockerfile.std extra_files: - "ci/install/" - "README.md" - "dist/" - "LICENSE.md" - "apps/app_sample.json" - "templates" - "middleware" - "event_handlers/sample" - "policies" - "coprocess" - "tyk.conf.example" # Build tykio/tyk-gateway-fips fips (amd64) - ids: - fips-amd64 image_templates: - "tykio/tyk-gateway-fips:{{.Tag}}-fips-amd64" build_flag_templates: - "--build-arg=PORTS=8080" - "--build-arg=BUILD_PACKAGE_NAME=tyk-gateway-fips" - "--platform=linux/amd64" - "--label=org.opencontainers.image.created={{.Date}}" - "--label=org.opencontainers.image.title={{.ProjectName}} FIPS" - "--label=org.opencontainers.image.revision={{.FullCommit}}" - "--label=org.opencontainers.image.version={{.Version}}" use: buildx goarch: amd64 goos: linux dockerfile: ci/Dockerfile.std extra_files: - "ci/install/" - "README.md" - "dist/" - "LICENSE.md" - "apps/app_sample.json" - "templates" - "middleware" - "event_handlers/sample" - "policies" - "coprocess" - "tyk.conf.example" # Build tykio/tyk-gateway std (amd64) - ids: - std-amd64 image_templates: - "tykio/tyk-gateway:{{.Tag}}-std-amd64" build_flag_templates: - "--build-arg=PORTS=8080" - "--build-arg=BUILD_PACKAGE_NAME=tyk-gateway" - "--platform=linux/amd64" - "--label=org.opencontainers.image.created={{.Date}}" - "--label=org.opencontainers.image.title={{.ProjectName}}" - "--label=org.opencontainers.image.revision={{.FullCommit}}" - "--label=org.opencontainers.image.version={{.Version}}" use: buildx goarch: amd64 goos: linux dockerfile: ci/Dockerfile.std extra_files: - "ci/install/" - "README.md" - "dist/" - "LICENSE.md" - "apps/app_sample.json" - "templates" - "middleware" - "event_handlers/sample" - "policies" - "coprocess" - "tyk.conf.example" # Build tykio/tyk-gateway std (arm64) - ids: - std-arm64 image_templates: - "tykio/tyk-gateway:{{.Tag}}-std-arm64" build_flag_templates: - "--build-arg=PORTS=8080" - "--build-arg=BUILD_PACKAGE_NAME=tyk-gateway" - "--platform=linux/arm64" - "--label=org.opencontainers.image.created={{.Date}}" - "--label=org.opencontainers.image.title={{.ProjectName}}" - "--label=org.opencontainers.image.revision={{.FullCommit}}" - "--label=org.opencontainers.image.version={{.Version}}" use: buildx goarch: arm64 goos: linux dockerfile: ci/Dockerfile.std extra_files: - "ci/install/" - "README.md" - "dist/" - "LICENSE.md" - "apps/app_sample.json" - "templates" - "middleware" - "event_handlers/sample" - "policies" - "coprocess" - "tyk.conf.example" docker_manifests: # Multi-arch manifest for tykio/tyk-gateway-ee ee - name_template: tykio/tyk-gateway-ee:{{ .Tag }}-ee image_templates: - tykio/tyk-gateway-ee:{{`{{ .Tag }}`}}-ee-amd64 - tykio/tyk-gateway-ee:{{`{{ .Tag }}`}}-ee-arm64 - name_template: tykio/tyk-gateway-ee:v{{ .Major }}.{{ .Minor }}{{.Prerelease}}-ee image_templates: - tykio/tyk-gateway-ee:{{`{{ .Tag }}`}}-ee-amd64 - tykio/tyk-gateway-ee:{{`{{ .Tag }}`}}-ee-arm64 - name_template: tykio/tyk-gateway-ee:v{{ .Major }}{{.Prerelease}}-ee image_templates: - tykio/tyk-gateway-ee:{{`{{ .Tag }}`}}-ee-amd64 - tykio/tyk-gateway-ee:{{`{{ .Tag }}`}}-ee-arm64 # Single-arch manifest for tykio/tyk-gateway-fips fips - name_template: tykio/tyk-gateway-fips:{{ .Tag }}-fips image_templates: - tykio/tyk-gateway-fips:{{`{{ .Tag }}`}}-fips-amd64 - name_template: tykio/tyk-gateway-fips:v{{ .Major }}.{{ .Minor }}{{.Prerelease}}-fips image_templates: - tykio/tyk-gateway-fips:{{`{{ .Tag }}`}}-fips-amd64 - name_template: tykio/tyk-gateway-fips:v{{ .Major }}{{.Prerelease}}-fips image_templates: - tykio/tyk-gateway-fips:{{`{{ .Tag }}`}}-fips-amd64 # Multi-arch manifest for tykio/tyk-gateway std - name_template: tykio/tyk-gateway:{{ .Tag }} image_templates: - tykio/tyk-gateway:{{`{{ .Tag }}`}}-std-amd64 - tykio/tyk-gateway:{{`{{ .Tag }}`}}-std-arm64 - name_template: tykio/tyk-gateway:v{{ .Major }}.{{ .Minor }}{{.Prerelease}} image_templates: - tykio/tyk-gateway:{{`{{ .Tag }}`}}-std-amd64 - tykio/tyk-gateway:{{`{{ .Tag }}`}}-std-arm64 - name_template: tykio/tyk-gateway:v{{ .Major }}{{.Prerelease}} image_templates: - tykio/tyk-gateway:{{`{{ .Tag }}`}}-std-amd64 - tykio/tyk-gateway:{{`{{ .Tag }}`}}-std-arm64

[github-actions]

API Changes

no api changes detected

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Avoid breaking apt state Removing the entire /var/lib/apt can break later layer operations and may cause dpkg status issues. Cleanup the apt cache without deleting apt databases. Keep logs removal but avoid nuking apt metadata. ci/Dockerfile.std [21-25] RUN rm -rf /root/.cache \ && apt-get -y autoremove \ && apt-get clean \ - && rm -rf /usr/include/* /var/cache/apt/archives /var/lib/apt /var/lib/cache /var/log/* \ - && find /usr/lib -type f -name '*.a' -o -name '*.o' -delete + && rm -rf /usr/include/* /var/cache/apt/archives/* /var/cache/apt/* /var/lib/apt/lists/* /var/lib/cache /var/log/* \ + && find /usr/lib -type f \( -name '*.a' -o -name '*.o' \) -delete Suggestion importance[1-10]: 7 __ Why: The PR removes /var/lib/apt, which can corrupt dpkg/apt state for later layers; proposing to clean caches and lists instead is accurate and improves reliability without altering functionality.	Medium
	Prevent unintended image pushes The CI step always pushes FIPS images on any branch, which can unintentionally publish non-release builds. Gate the push with the same tag-based condition used elsewhere. This prevents accidental registry pollution. .github/workflows/release.yml [217-233] - name: push fips image to CI - if: ${{ matrix.golang_cross == '1.24-bullseye' }} + if: ${{ matrix.golang_cross == '1.24-bullseye' && startsWith(github.ref, 'refs/tags') }} uses: docker/build-push-action@v6 with: context: "dist" platforms: linux/amd64 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 Suggestion importance[1-10]: 4 __ Why: The existing step intentionally pushes FIPS images to CI unconditionally, mirroring std/ee CI behavior; gating it to tags would block CI images for branches/PRs. The suggestion reduces registry noise but conflicts with added CI publishing intent, so only a minor improvement.	Low
Security	Enforce FIPS-safe crypto behavior Setting GOEXPERIMENT=boringcrypto alone may not ensure FIPS-ready binaries unless the appropriate Go toolchain is used. Add GODEBUG=x509sha1=0 at build time to avoid accidental SHA-1 usage that can violate FIPS requirements. ci/goreleaser/goreleaser.yml [61-67] - id: fips-amd64 flags: - -tags=goplugin,fips,boringcrypto env: - NOP=nop # ignore this, it is jsut to avoid a complex conditional in the templates - CC=gcc - GOEXPERIMENT=boringcrypto + - GODEBUG=x509sha1=0 Suggestion importance[1-10]: 5 __ Why: Adding GODEBUG=x509sha1=0 can help avoid SHA-1 in x509 and aligns with FIPS goals, but it may not be strictly required if the codebase already avoids SHA-1 and toolchain enforces boringcrypto; moderate benefit and correctness.	Low

[github-actions]

📦 Impact Review Snapshot

Effort	Downstream Updates	Compatibility	Docs	TL;DR
Low	✅	🟢	⚠️	Adds FIPS Docker images without affecting APIs or schemas

Impact Assessment

This PR adds FIPS-compliant Docker images to Tyk Gateway releases without modifying any APIs, schemas, or protocols. The changes are limited to build configuration (goreleaser.yml) and CI/CD workflows (release.yml). Parallel PRs exist for other components (tyk-pump, tyk-sink, tyk-analytics) to ensure consistent FIPS support across the platform.

Required Updates

No direct code updates are required in downstream repositories, but documentation should be updated to reflect the availability of FIPS-compliant Docker images. The PR author notes that "Changes to FIPS documentation may be required."

For tyk-charts, consider adding support for deploying FIPS images as an option in Helm charts, though this isn't strictly required for compatibility.

For tyk-sink (MDCB), the parallel PR mentioned in the description should handle the necessary changes to ensure consistent FIPS support.

Compatibility Concerns

No backward compatibility issues are expected as this PR only adds new Docker image variants without changing existing functionality. The FIPS images are built using the GOEXPERIMENT=boringcrypto flag and packaged in distroless containers, but the API surface and behavior remain unchanged.

Note that FIPS images are currently only available for amd64 architecture (not arm64), which should be documented.

Summary & Recommendations

• Update documentation to reflect the availability of FIPS-compliant Docker images and their limitations (amd64-only, not FIPS validated)
• Consider adding FIPS image support to tyk-charts for easier deployment in Kubernetes environments
• Ensure consistent versioning and tagging across all FIPS-enabled components (tyk, tyk-pump, tyk-sink, tyk-analytics)
• Verify that the parallel PRs for other components (especially tyk-sink) maintain compatibility with this implementation

---

Tip: Mention me again using /dependency <request>.
Powered by Probe AI
Tyk Gateway Dependency Impact Reviewer

[github-actions]

🚀 Performance Snapshot

Effort	Perf Risk	Hot Paths	Benchmarks	TL;DR
Low	🟡	✅	❔	FIPS crypto may impact TLS/crypto operations but no code changes

## Performance Impact Analysis

This PR adds FIPS-compliant Docker images to Tyk Gateway releases without modifying the core codebase. The performance impact is isolated to cryptographic operations due to the use of BoringSSL (via Go's boringcrypto experiment) instead of standard Go crypto libraries. BoringSSL typically has different performance characteristics, often with some overhead for FIPS compliance.

## Critical Areas

The only performance-sensitive areas potentially affected are:

1. TLS Handshakes: Connection establishment may be slower with FIPS-compliant crypto
2. JWT Validation: Token signature verification might have increased latency
3. mTLS Authentication: Client certificate validation could experience higher CPU usage
4. Hashing Operations: Any internal hashing (e.g., for caching) might be affected

No changes to request handling logic, middleware chains, or API definition processing are included in this PR.

## Optimization Recommendations

1. Consider benchmarking the FIPS binary against the standard binary to quantify performance differences, particularly for TLS handshakes and JWT operations
2. Document any performance differences in the FIPS documentation to set appropriate expectations
3. If significant performance degradation is observed, consider tuning connection pools and timeouts specifically for FIPS deployments

## Summary

• This PR adds Docker images built using FIPS-compliant binaries without changing any code
• Performance impact is limited to cryptographic operations due to BoringSSL vs standard Go crypto
• The distroless container base should have minimal overhead
• No changes to hot paths like request routing, middleware execution, or rate limiting
• Performance impact should be documented for users choosing FIPS compliance over standard builds

---

Tip: Mention me again using /performance <request>.
Powered by Probe AI
Performance Impact Reviewer Prompt

[github-actions]

🚦 Connectivity Review Snapshot

Effort	Tests	Security	Perf	TL;DR
Low	⚠️	🔒 none	🟡	FIPS Docker images use BoringSSL which may impact TLS connections

## Connectivity Assessment

• Redis Connections: No direct changes to Redis connection code, but FIPS builds use BoringSSL which may affect TLS behavior when Redis SSL is enabled.
• RPC Connections: FIPS crypto implementation could impact TLS handshakes with MDCB in RPC mode, though connection protocols remain unchanged.
• Synchronization Mechanisms: No changes to pub/sub channels or notification mechanisms; only the underlying crypto implementation is modified.

## Test Coverage Validation

• Redis Tests: No specific tests for FIPS Redis connectivity; relies on existing test suite and assumes BoringSSL compatibility.
• RPC Tests: No dedicated tests for FIPS RPC connections; should consider validating TLS handshakes with MDCB when using FIPS images.
• Failure Scenario Tests: Missing tests for TLS negotiation failures specific to BoringSSL implementation; recommend adding tests for Redis and RPC connections with TLS enabled.

## Security & Performance Impact

• Authentication Changes: FIPS builds enforce stronger cryptographic standards which may reject certain weak ciphers that non-FIPS builds accept.
• Performance Considerations: BoringSSL implementations typically have different performance characteristics than standard Go crypto; TLS handshakes may be slower.
• Error Handling: Error messages from BoringSSL may differ from standard Go crypto, potentially affecting troubleshooting of TLS connection issues.

## Summary & Recommendations

• This PR adds Docker images built with FIPS-compliant binaries without changing connection code.
• Consider adding specific tests for Redis and RPC connections with TLS enabled using the FIPS binary.
• Document potential differences in TLS behavior and performance characteristics for users deploying FIPS images.
• Ensure error messages from BoringSSL are properly captured and logged for troubleshooting.

---

Tip: Mention me again using /connectivity <request>.
Powered by Probe AI
Connectivity Issues Reviewer Prompt for Tyk Gateway

[github-actions]

Analysis of PR: Add Docker Images Built Using FIPS Binaries

This PR adds FIPS-compliant Docker images to Tyk Gateway releases by leveraging existing FIPS binaries in a distroless container. The changes are purely infrastructure-focused and don't modify any application code or APIs.

Key Changes

1. FIPS Binary Build Configuration:

   • Added a dedicated build configuration in goreleaser.yml for FIPS binaries
   • Uses GOEXPERIMENT=boringcrypto and -tags=goplugin,fips,boringcrypto to enable FIPS-compliant cryptography
   • Only supports Linux/amd64 architecture (not arm64)

2. Docker Image Configuration:

   • Added Docker image definition for tykio/tyk-gateway-fips in goreleaser config
   • Uses the standard Dockerfile but with BUILD_PACKAGE_NAME=tyk-gateway-fips
   • Creates appropriate Docker manifests with -fips tag suffixes

3. CI/CD Workflow Updates:

   • Extended GitHub Actions workflow to build and publish FIPS images
   • Added metadata generation for FIPS images with appropriate labels
   • Configured both CI and production publishing paths with conditional logic

4. Dockerfile Improvements:

   • Updated cleanup paths in Dockerfile.std for better package management
   • Uses distroless base image for FIPS builds to minimize attack surface

Important Notes

• These are not FIPS-validated images - they use FIPS-compliant binaries but haven't gone through formal FIPS validation
• FIPS images are only available for amd64 architecture (not arm64)
• The changes are part of a broader effort that includes similar changes to tyk-pump, tyk-sink, and tyk-analytics

Performance & Security Considerations

• FIPS-compliant cryptography (BoringSSL) may have different performance characteristics than standard Go crypto
• TLS handshakes and cryptographic operations might be slightly slower in the FIPS builds
• The distroless container base provides a smaller attack surface than the standard Debian-based image

This PR successfully implements the requested feature without modifying any application code or APIs, making it a low-risk enhancement that meets the customer requirements for FIPS-compliant Docker images.

---

Tip: Mention me again using /performance <request>.
Powered by Probe AI
Performance Impact Reviewer Prompt

[github-actions]

🚦 Connectivity Review Snapshot

Effort	Tests	Security	Perf	TL;DR
Low	⚠️	🔒 none	🟡	FIPS Docker images use BoringSSL which may impact TLS connections

## Connectivity Assessment

• Redis Connections: No direct changes to Redis connection code, but FIPS builds use BoringSSL which may affect TLS behavior when Redis SSL is enabled.
• RPC Connections: FIPS crypto implementation could impact TLS handshakes with MDCB in RPC mode, though connection protocols remain unchanged.
• Synchronization Mechanisms: No changes to pub/sub channels or notification mechanisms; only the underlying crypto implementation is modified.

## Test Coverage Validation

• Redis Tests: No specific tests for FIPS Redis connectivity; relies on existing test suite and assumes BoringSSL compatibility.
• RPC Tests: No dedicated tests for FIPS RPC connections; should consider validating TLS handshakes with MDCB when using FIPS images.
• Failure Scenario Tests: Missing tests for TLS negotiation failures specific to BoringSSL implementation; recommend adding tests for Redis and RPC connections with TLS enabled.

## Security & Performance Impact

• Authentication Changes: FIPS builds enforce stronger cryptographic standards which may reject certain weak ciphers that non-FIPS builds accept.
• Performance Considerations: BoringSSL implementations typically have different performance characteristics than standard Go crypto; TLS handshakes may be slower.
• Error Handling: Error messages from BoringSSL may differ from standard Go crypto, potentially affecting troubleshooting of TLS connection issues.

## Summary & Recommendations

• This PR adds Docker images built with FIPS-compliant binaries without changing connection code.
• Consider adding specific tests for Redis and RPC connections with TLS enabled using the FIPS binary.
• Document potential differences in TLS behavior and performance characteristics for users deploying FIPS images.
• Ensure error messages from BoringSSL are properly captured and logged for troubleshooting.

---

Tip: Mention me again using /connectivity <request>.
Powered by Probe AI
Connectivity Issues Reviewer Prompt for Tyk Gateway

[sonarqubecloud]

Quality Gate failed

Failed conditions
4 Security Hotspots

See analysis details on SonarQube Cloud