MuleSoft Flex Gateway: Custom Policy with MuleSoft PDK

Published in

Another Integration Blog

5 min readMay 13, 2024

In the world of microservices and integrations, the ongoing challenge of enhancing, maintaining, auditing, and securing services has been routine and ever-present. While these aspects may not influence the functional requirements of your services, they play a vital role in supporting non-functional requirements such as monitoring, compliance, service management, and scalability capabilities. Various iPaaS platforms like MuleSoft Anypoint Platform offer out-of-the-box solutions to address these challenges through their API Gateways and Policies. However, not all out-of-the-box solutions cater to every business need, which leads us to build a custom solution or policy to integrate within their platform.

Before we proceed, it’s essential to understand the respective roles of API Gateway and Policies. An API Gateway serves as a single entry point for all incoming requests, while the policies play the crucial role of enforcing security measures, rate limits, transformations, access controls, and other functions within your API.

Recently, MuleSoft has introduced Anypoint Flex Gateway and PDK. The Flex Gateway is an API Gateway that enables us to manage and secure Mule or any other APIs running anywhere. Whereas the PDK (Policy Development Kit) is an SDK provided to build custom policies, extending MuleSoft’s out-of-the-box policies. In this article, we will build a custom policy using MuleSoft PDK, run it locally, and publish it to Anypoint Exchange.

Note: Mule API Gateway and Flex Gateway have different underlying architectures or runtime environments. Mule API Gateway is typically based on the Mule runtime engine, which is Java-based, while Flex Gateway uses Envoy Proxy. Hence, the Policy built with PDK applies only to Flex Gateway and cannot be applied to Mule API Gateway.

Custom Policy Functionality:

To simplify, let’s consider that the business requires a method to measure the duration of API requests. They wish to include a custom header for both the request and response to accomplish this. This header will facilitate tracking the initiation and completion times of each request.

Setup

For developing a PDK custom policy you need to have the following installed:

Docker (Local Debugging)
Anypoint CLI v4 (1.4.4 or later)
Rust v1.74.0
WebAssembly System Interface
Visual Studio Code (Anypoint Code Builder )

Creating Custom Policy

1) Project creation:

To generate a custom policy starter template project and run the following commands:


anypoint-cli-v4 pdk policy-project create --name tracking-logger-policy # Creates project
cd tracking-logger-policy # Move inside the folder
make setup # Setup PDK Build Environment
code . # Open the project in VS Code

2) Setup Parameters:

Inside the definitions/gcl.yaml file, We’ll create two parameters named startHeaderName and endHeaderName, which will be dynamically injected into the header of each incoming API request and Response accordingly.

---
apiVersion: gateway.mulesoft.com/v1alpha1
kind: Extension
metadata:
  labels:
    title: tracking-logger-policy
    category: Custom
spec:
  extends:
    - name: extension-definition
      namespace: default
  properties:
    startHeaderName:
      type: string
      default: tracking-start-time
    endHeaderName:
      type: string
      default: tracking-end-time
  required:
    - startHeaderName
    - endHeaderName

After defining the necessary parameters, execute the following command in the terminal to generate or update the src/generated/config.rs file. This will read the defined input parameters and declare them in the config.rs file.

make build

3) Implementing Functionality:

Please refer to the below rust code snippet for implementation. Here is the Github repo link for reference.

Implementing injecting headers into request and response

In the provided code, the #[entrypoint] annotation marks the application’s entry point. Within the configure function, we declare a filter to manage both incoming requests and outgoing responses. Upon receiving a request, the request_filter function is invoked, and on completion, the response_filter function is invoked.

Inside the request_filter and response_filter, both perform a similar operation, each of them will inject a header with the current timestamp based on the provided property in the definitions/gcl.yaml file. For reference, please go through the below snippet for the response_filter.

response_filter for inject response headers

4) Anypoint Flex Gateway & Deployment

Within the project, the PDK generates a `playground` folder, housing a docker-compose file with the Anypoint Flex Gateway and a sample API service.

All we need to do is to create a registration file, simply execute the command provided, and save the resulting “registration.yaml”. Move it to the “playground/config” folder.

flexctl registration create --client-id CONNECTED_APP_CLIENT_ID --client-secret CONNECTED_APP_CLIENT_SECRET --environment ENVIRONMENT_ID --organization ORGANIZATION_ID FLEX-GATEWAY-NAME

Now to test the policy locally, run the following command to build and then run the project accordingly.

make build # Builds the MuleSoft Policy
make run # Builds and Deploys the MuleSoft policy to your Flex Gateway

Open Postman or other API Clients and trigger the endpoint defined in the playground/config/api.yaml — spec.address => http://0.0.0.0:8081. In the next two images, please notice the header Tracking-Start-Time field is injected to the API Service from our policy, and the Response header tracking-end-time field is populated on response.

Tracking-Start-Time Field is injected to Request Headers

tracking-end-time field is injected in Response Headers

Cool, Right!

5) Publishing to Exchange

Now to make this custom policy available within your organization run the following command.

make publish # Publishes a development stable asset
make release # Publishes a Release Stable Asset

Thoughts

In my journey of developing Custom Policies for Mule API Gateway using XML and MuleSoft PDK with Rust for Flex Gateway, I’ve found that MuleSoft PDK offers a more comprehensive solution. Unlike the previous approach, which lacked local and unit testing capabilities, MuleSoft PDK provides a complete development experience. The starter kit includes a playground, offering a Docker environment with a flex gateway enabling the deployment of policies locally, facilitating iterative development before final publication as an asset. Moreover, the flexibility extends to writing units and E2E test cases. However, there’s a twist — everything is in Rust.

Rust is a new programming language and uncharted territory for me. I faced some challenges setting up, grasping the environment, putting together the logic, and so on. Even upon completion, I wouldn’t say I fully understand, but the experience has reminded me of my initial C++ days.

That said, I find building Custom Policies with MuleSoft PDK for Flex Gateway an enriching experience. However, it would’ve been ideal, if we could apply the PDK policies on Mule API Gateway (not possible, please check the above note).