Learn Multigress - Extensions & Plugin Ecosystem

#Introduction

Gateway needs never stop at standard routing and security. Episode 16 covers the extensions and plugin ecosystem of Multigress: extending the data plane with Envoy filters and custom plugins, building advanced filter chains for request transformation, and combining third-party tools for security and observability.

The key is knowing when to use built-in features and when to add a plugin. Over-extending becomes an operational burden instead.

#Envoy Filters and Custom Plugins

#Declarative HTTPFilter

Multigress exposes Envoy capabilities through the HTTPFilter CRD, so filters can be registered declaratively without touching the bootstrap configuration. The example below adds a header via a Lua filter.

apiVersion: gateway.multigress.io/v1
kind: HTTPFilter
metadata:
  name: custom-header-filter
spec:
  type: Envoy
  envoy:
    name: envoy.filters.http.lua
    typedConfig:
      inlineCode: |
        function envoy_on_request(request_handle)
          request_handle:headers():add("X-Proxy", "multigress")
        end

The envoy.filters.http.lua filter executes Lua code on each request. Once this filter is installed, every request that passes through carries the X-Proxy: multigress header.

#Custom Plugins with WebAssembly

For more complex logic, use a WebAssembly plugin compiled from a language like Rust or Go. WASM plugins run in a sandbox, so a bug in the plugin won't crash the whole proxy.

apiVersion: gateway.multigress.io/v1
kind: HTTPFilter
metadata:
  name: wasm-rewrite
spec:
  type: Wasm
  wasm:
    url: oci://registry.example.com/multigress/plugins/rewrite:v1
    sha256: a1b2c3d4e5f6a7b8

The WASM plugin is pulled from an OCI registry and verified with sha256 before loading. The small size of WASM makes plugin distribution fast, and updates can be done without overhauling the gateway.

#Advanced Filter Chains for Request Transformation

#Composing Filters in HTTPRoute

Request transformations like rewrites and header modifications are composed as a chain inside the HTTPRoute, following the Gateway API spec.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: platform
spec:
  parentRefs:
    - name: multigress-gateway
  hostnames:
    - api.example.com
  rules:
    - filters:
        - type: URLRewrite
          urlRewrite:
            path:
              type: ReplacePrefixMatch
              replacePrefixMatch: /v1
        - type: RequestHeaderModifier
          requestHeaderModifier:
            set:
              - name: X-Client
                value: mobile
      backendRefs:
        - name: api-svc
          port: 8080

The chain above removes the old prefix and replaces it with /v1, then adds the X-Client: mobile header. Filter order matters: the rewrite runs before the header modification, and the final result the backend sees is the product of all transformations.

#Combining with HTTPFilter

Global filters and route-level chains can be combined. Global filters handle needs shared by all routes, while the route chain handles hostname-specific needs. This separation keeps configuration easy to understand and review.

#Third-Party Tools for Security and Observability

#OAuth2 Proxy and WAF Integration

Instead of writing your own filters, you can place mature tools in front of or behind the gateway. OAuth2 Proxy, for example, handles the OIDC flow without writing any code.

helm repo add oauth2-proxy https://oauth2-proxy.github.io/manifests
helm install oauth2-proxy oauth2-proxy/oauth2-proxy \
  --namespace oauth2-proxy --create-namespace \
  --set config.oidcIssuerUrl=https://auth.example.com

Once installed, point your route to the oauth2-proxy service as the backend. The gateway still handles TLS and routing, while oauth2-proxy handles the login flow.

#Observability Tools as Extensions

The ecosystem beyond the gateway is also worth connecting: vector or fluent-bit for log shipping, Loki for aggregation, and OPA for policy. They're all installed as separate services and connected to the gateway via the configuration we covered in episodes 12 and 14.

kubectl get httpfilter -A
kubectl get securitypolicy -A

The kubectl get httpfilter -A command lists all registered global filters. In short: only add a plugin when the built-in features have proven insufficient.

#Closing

Episode 16 opened the ways to extend your gateway: HTTPFilter for Envoy capabilities, WASM for sandboxed plugins, filter chains in HTTPRoute for transformations, and third-party tools that blend into the ecosystem.

The key takeaways:

• HTTPFilter registers Envoy filters declaratively.
• WASM plugins run in a sandbox and are safe to distribute.
• HTTPRoute filter chains transform requests in a defined order.
• Global and per-route filters can be combined.
• OAuth2 Proxy and observability tools integrate seamlessly.
• Only add a plugin when built-in features aren't enough.

In the next episode 17 we'll discuss multi-cluster & hybrid deployments — cross-cluster routing, multi-cluster service exposure patterns, and networking considerations for hybrid cloud. The gateway capabilities you extended will be used in a wider topology.