Applying policies to APIs exposed by MuleSoft Flex Gateway and running on top Oracle Container Engine for Kubernetes (OKE)

Taken from https://www.mulesoft.com/platform/api/flex-api-gateway

As we’ve shared in our previous articles:

1. Understanding MuleSoft’s Universal API Management and a first glimpse of the new Flex Gateway
2. Deploying the Flex Gateway on top of Oracle Container Engine for Kubernetes
3. Exposing a microservice API through the Flex Gateway running on top of Oracle Container Engine for Kubernetes

MuleSoft has a very strong Universal API Management approach. With this, MuleSoft’s API Manager can manage APIs deployed pretty much everywhere.

We wanted to create content for Kubernetes, and in specific with Oracle, because it is a great option for you in case you are creating services or microservices that need to be exposed as APIs.

But now is time to take an additional step, which is to apply policies to our API exposed by the Flex Gateway and running inside OKE (Oracle Container Engine for Kubernetes) just as we are used to with any other API with MuleSoft.

Remember that we started with a simple microservice developed in Go that uses REDIS for caching purposes (take a look at it here). That microservice was available for other applications but inside the cluster (Oracle Container Engine for Kubernetes — OKE) but not for external purposes. In case we wanted to expose that as part of an API (a managed API), we were not able to do it until this point when we deployed the Flex Gateway into OKE, and use it to expose the microservice API for external purposes.

Now imagine we need to apply a Rate limiting policy. We want to apply that to control the number of requests the consumers are going to generate.

Let’s go to the API Manager Console:

The one highlighted in yellow is the one we’ve created in our previous article.

But as you can see on the screen, you may have APIs deployed on:

1. Flex Gateway
2. MuleSoft Runtime standalone
3. Mulesoft Runtime Fabric
4. MuleSoft Cloudhub
5. MuleSoft Private Cloud Edition

A single centralized API Manager to manage, control, monitor and apply policies.

Let’s do it for our Session API.

Click on it and you will be taken to this screen:

You will get access to the API status, and also to the Menu on the left side of the window where we can apply policies. But before that, let’s take a look at the bottom of the screen:

You have statistics on the number of requests, average response time, and also errors.

Alright, let’s go to apply our first policy. Click on the Policies link on the left side of the window:

As you can see there are no applied policies so far. Neither automated nor API-level policies.

Automated policies are the ones that, as Administrators, we can decide to apply automatically to every API we want to manage. And the API-level policies are the ones that we apply individually to specific APIs. We are going to apply our first API at the API level.

As you can see on the screen there is a plus (+) sign where we can click to add a policy. Let’s click on it:

The categories are:

• Security
• Quality of service
• Transformation
• Troubleshooting
• Compliance

If you click on any of the categories, the screen will show you the specific policies for that category. In our case, the Rate-Limiting policy is in the Quality of Service category. Let’s click on it:

Select Rate Limiting:

We need to configure the number of requests during a period and specify the time unit. For example, in our case:

5 requests during 1 minute.

With that, we are ready to apply the policy and test it, but before proceeding takes a look at this configuration:

If you click on that check-box, you can return customized HTTP headers that will tell the consumer relevant information about the rate-limiting. For example number of requests remaining before you hit the limit. We will select that option to show you how that works. Click on the apply button and now you will see this policy applied:

Now let’s test it with curl, and after five requests you will get this:

The result will be that: Too May Requests, error.

If you test it using Postman, for example, you can get the response headers:

You can see the exposed headers that we’ve mentioned in the previous paragraphs.

And just that easy we are managing and applying policies to our APIs through the Flex Gateway running on top of Oracle Container Engine for Kubernetes.