Enriching Tyk with OSS API traffic visibility & security reporting

API Clarity is “an open source cloud native visibility tool for APIs”.  What does that mean though?  You mean the super-long title isn’t clear enough?!

API Clarity is a K8S solution that monitors REST API requests in your cluster and compares them against your OAS (OpenAPI specification) documentation, and then reports discrepancies, ie. if your APIs are being used in ways that are NOT expected.

If your APIs do not have OAS documentation, APIClarity generates OAS documentation by aggregating API metadata based on consumption.

Let’s play with Tyk OSS + APIClarity and see what we get.

Hands On

For this, we’ll be using a GitHub repo that deploys OSS Tyk & APIClarity in a few commands. (If you’d like to try the integration step-by-step, check out the APIClarity documentation)

 

1> We follow the README to run Tyk & APIClarity, and port-forward to both services so we can access them locally.

2> Now, let’s generate some API requests against Tyk using the included script:
$ ./generate-apicalls.sh
Generating load against two APIs.
Finished generating load against two APIs.

3> Now, let’s open up APIClarity on our browser via http://localhost:9999

We see that Tyk has reported telemetry data to APIClarity from two APIs.

4> Let’s upload the included OAS spec in “./oas/jsonplaceholder.json” into APIClarity

This loads all our endpoints for this API into APIClarity.  APIClarity will now compare this with realtime API traffic and alert us to unusual behaviour. 

Yes, it really was that simple to get full-on anomaly detection alongside Tyk’s secure API Management.  

APIClarity, like Tyk and all good OSS software, is aligned with OSS standards.  This means that your teams will be rewarded for already using best-practices such as OAS for your REST APIs.

OAS Reconstruction

Let’s pretend we don’t have a spec for HTTPBin. 

Here’s how we can have APIClarity generate OAS documentation from our API traffic:

That’s all we had to do to generate OAS documentation!  We can now visit the Swagger sandbox right from the UI and view it in real-time.

Real-time anomaly detection

Now, let’s re-generate more API requests and see what insights APIClarity gathers for us.

$ ./generate-apicalls.sh

Generating load against two APIs.

Finished generating load against two APIs.

After refreshing the APIClarity page, we see some alerts:

Here we can see that APIClarity has identified 5 API requests that fall outside of the OAS spec for the Jsonplaceholder API.  We can even click into an item for details on that request:

All-in-all, very powerful stuff. 

The team at APIClarity managed to deliver a powerful tool with a very small footprint that sits inside our k8s cluster to give us more visibility and insight into our API traffic.  Moreover, in months to come, the APIClarity functionality will be expanded with more testing and analytics tools that have their basis in OWASP API top 10 issues.

From an AppSec or SecOps perspective, this is quite low-hanging fruit!

Keeping in mind that the API Gateway pattern involves all traffic passing through a singular “front-door” into your ecosystem, you’ve added another layer of protection globally by integrating APIClarity with Tyk.  Another bodyguard to bolster the ones already in place!

Though, are we telling you to RUN and install this in your production environments?  Of course not.  There are many factors to consider.

  • How is the telemetry data handled?
  • Is it blocking or non-blocking?
  • How does that affect latency?
  • Is this set up compliant with highly regulated environments?

And so on.

This blog is simply intended to get the brain juices running on an otherwise very lightweight and powerful piece of Open Source Technology, something we’re huge advocates for.