Tyk Gateway Plugin Compatibility Issue

Support Installation and Deployment
, ,
1

Hi Tyk Community,

We’re currently encountering an issue with loading our custom authentication plugin (auth-plugin_v5.3.0_linux_amd64.so) in the Tyk Gateway. Despite following Tyk’s plugin compatibility guidelines, the plugin fails to load, and we’re hoping for some guidance to resolve this.

Our Setup:

  1. Tyk Gateway Build:
  • Built from source using the Microsoft FIPS Bookworm base image (mcr.microsoft.com/oss/go/microsoft/golang:1.21.11-fips-bookworm).
  • Build tags: coprocess, grpc, goplugin, dev, fipsonly.
  • Go version: 1.21.11.
  • Using the same tyk repository version for both Gateway and plugin builds.
  1. Auth Plugin Build:
  • Built with the same Microsoft FIPS Bookworm image.
  • References the local Tyk Gateway codebase (./tyk via replace directive in go.mod).
  • Build tags: coprocess, grpc, goplugin, dev, fipsonly.
  • Built as a .so file with GOEXPERIMENT=systemcrypto, GOOS=linux, and GOARCH=amd64.

The Issue:

When loading the plugin into the Tyk Gateway, the plugin fails to initialize, with logs indicating a potential runtime mismatch.

level=error msg="Could not load Go-plugin" error="plugin.Open(\"custom-plugins/auth-plugin_v5.3.0_linux_amd64\"): plugin was built with a different version of package github.com/TykTechnologies/tyk/internal/maps" mwPath=custom-plugins/auth-plugin.so mwSymbolName=AuthMiddleware

Here’s what we’ve done to ensure compatibility:

  1. Dependency Matching:
  • Verified shared dependencies (e.g., github.com/golang-jwt/jwt/v4, github.com/sirupsen/logrus) are identical in version across the Gateway and plugin.
  • Ensured the plugin references the same tyk tag (v5.3.3) as the Gateway.
  1. Build Consistency:
  • Both the Gateway and plugin use the same Go version, build flags, and build tags.
  • Verified runtime symbol definitions with nm and Go version metadata with go version -m.

Debugging Details:

Here are some relevant outputs:

  • Plugin Symbols:
$ nm -gD auth-plugin_v5.3.0_linux_amd64.so | grep AuthMiddleware
000000000052b700 T tyk-auth-plugin.AuthMiddleware
000000000052f2c0 T tyk-auth-plugin.AuthMiddleware.func1
  • Go Version Metadata: Plugin:
$ go version -m auth-plugin_v5.3.0_linux_amd64.so
build	-buildmode=plugin
build	-tags=coprocess,grpc,goplugin,dev,fipsonly
build	CGO_ENABLED=1
build	GOEXPERIMENT=systemcrypto
build	GOOS=linux
build	GOARCH=amd64

Tyk Gateway:

$ go version -m tyk
build	-buildmode=exe
build	-tags=coprocess,grpc,goplugin,dev,fipsonly
build	CGO_ENABLED=1
build	GOEXPERIMENT=systemcrypto
build	GOOS=linux
build	GOARCH=amd64

Given that we’ve ensured matching dependencies, build flags, and tags, we’re uncertain what might be causing this mismatch. Could there be additional runtime requirements or compatibility checks we’re missing?

We’d appreciate any insights or suggestions on:

  1. Debugging tools or techniques to further pinpoint the issue.
  2. Any specific nuances with using the Microsoft FIPS Bookworm image for both Tyk and plugin builds.
  3. Common pitfalls in aligning plugin and Gateway compatibility.

Thank you for your help!

2

Hi @phuynh-cm,

Welcome to the community and thank you for your patience. :star:

Thank you for providing such a detailed explanation of the steps you’ve taken and the challenges you’re facing - it’s clear you’ve invested significant effort into this.

While I may not have the technical depth to assist with your specific issue, I’d like to recommend using our official Plugin Compiler. This is the recommended approach for compiling plugins and is designed to work seamlessly with the official releases of the gateway. It can help simplify the build process and minimize potential compatibility issues.

Thank you again for sharing your experience, and I hope the utility provides a more streamlined path for your work! Please let us know if you experience challenges using it.

Best regards,