Forum Discussion
Cypher
Cirrus
CirrusHow to do API Protection with 3scale API Manager?
Hi everyone,
I want to protect API calls via the API protection with F5. It uses a swagger OpenAPI Spec file 2.0 or 3.0 to control all the methods - urls and more.
The API calls are managed by the Red Hat 3Scale API Manager, but we can't seem to find this swagger file. How would we best approach this? Also, let's say we have the swagger file, and something changes to it, how do we update that? While also retaining custom addition/signature exclusions? for this, the more automation the better :).
I found that F5 and 3Scale did some kind of colaboration but verry little is found to actually implement it. https://www.f5.com/pdf/partners/red-hat-3scale-api-gateways.pdf
Any input is welcome on how to tackle this problem. Thanks in advance!
Hi Cypher ,
The approach I would take to a scenario like this is to include responses in your Policy Builder (if you have that set for the policy).
This will mean that you have a way of 'tracking' the URIs that are sent in the responses.
At a very basic level, API discovery technologies will have a API schema (which in your case you don't), and then monitor the responses sent back from the origin servers. The drift between these is the 'shadow APIs'. This is not all of the mechanisms in API discovery, but just giving you some ideas on how you can implement a similar type of control with AWAF.
By the way your comment about APIs being onboarded and offboarded is a concern, this is the very thing that needs to have a level of control - at least to a transparent/logging level. In most not all scenarios, you should not be creating too many Hostname or differfent URI endpoints in production regularly, as it may be the services that host those URIs that can change daily, etc. But if you are in a situation where the URI endpoints and Hostnames terminating on the API gateway change quite frequently, then definitely having a policy that tracks responses is a good measure as a start.
Also, to point out, that the gateway vendor should not matter in this scenario as at a foundational level you are in front of something that speaks HTTP, URIs, JSON, etc.
- shsingh
Employee
Hi Cypher is there a particular deployment type for protection you were looking into for API protection? BIG-IP Advanced WAF? NGINX App Protect? Distributed Cloud WAAP?
Let's take for example if you wanted to use BIG-IP Advanced WAF, we have a guided configuration which takes you through a few steps from API definition (Swagger) through to enforcement. https://techdocs.f5.com/kb/en-us/products/big-ip_apm/releasenotes/product/relnote-guided-config-8-0.html#overviewasmIf you have an existing BIG-IP Advanced WAF, you should see this under the Guided Configuration option in Advanced WAF.
If you are looking at NGINX App Protect or Distributed Cloud WAAP, then they both have different scenarios for enforcement of API schemas as well.
CypherHi shsingh,
Thanks for your reply. Deployment type is indeed BIG-IP Advanced WAF. I am aware of the guided configuration, and that is the approach i want to take. The thing is, i can not obtain a swagger file from this 3scale API manager for the applications behind it. It is in itself a reverse proxy for api calls.. API calls get onboarded and offboarded frequently, and how would i manage this, while maintaining current ASM exclusions? I wonder how F5 sees the deployment https://www.f5.com/pdf/partners/red-hat-3scale-api-gateways.pdf. Is it just placing the F5 in between acting as reverse proxy + advanced WAF functionality, or is it possible to work with guided configurations and a swagger file. Maybe i got off track because it said API protection (referring to advanced WAF and not guided configuration-api protection) in the design in the document.
I know these are very specific questions
- shsingh
Hi Cypher ,
The approach I would take to a scenario like this is to include responses in your Policy Builder (if you have that set for the policy).
This will mean that you have a way of 'tracking' the URIs that are sent in the responses.
At a very basic level, API discovery technologies will have a API schema (which in your case you don't), and then monitor the responses sent back from the origin servers. The drift between these is the 'shadow APIs'. This is not all of the mechanisms in API discovery, but just giving you some ideas on how you can implement a similar type of control with AWAF.
By the way your comment about APIs being onboarded and offboarded is a concern, this is the very thing that needs to have a level of control - at least to a transparent/logging level. In most not all scenarios, you should not be creating too many Hostname or differfent URI endpoints in production regularly, as it may be the services that host those URIs that can change daily, etc. But if you are in a situation where the URI endpoints and Hostnames terminating on the API gateway change quite frequently, then definitely having a policy that tracks responses is a good measure as a start.
Also, to point out, that the gateway vendor should not matter in this scenario as at a foundational level you are in front of something that speaks HTTP, URIs, JSON, etc.