spikeArrest as a solution to provide privileged access to API
Hi there,
In the Foundation Training > Securing your API > SpikeArrest from academy.apigee,com, video min 06:13, it is mentioned that spikeArrest can be used as a business usecase where "you have a spikeArrest set to a particular value for particular applications that are associated with particular products. Product A has 100tps against this backend while Product B has 50tps they can do against this backend".
I don't understand how exactly the <identifier> can be used in such case to provide privileged access to APIs. Can you please post a working example?
Thank you a lot,
Emilia
Answer by sudheendras
·
Jul 12, 2016 at 01:23 AM
Hi @Emilia Ipate Welcome to Apigee Community!
If you use a simple SpikeArrest policy (like below) without an identifier, it's applied to all API calls.
<SpikeArrest name="SpikeArrest"> <Rate>20ps</Rate> </SpikeArrest>
Using <Identifier> tag you can uniquely identify and apply spike arrest against individual apps or developers. For e.g. This spike arrest policy restricts 30 transaction/second, per App (identified by API key).
<SpikeArrest async="false" continueOnError="false" enabled="true" name="Spike-Arrest-1">
<DisplayName>Custom label used in UI</DisplayName>
<Rate>30ps</Rate>
<Identifier ref="request.queryparam.apikey"/>
</SpikeArrest>
As you can see the <Rate> element is hardcoded to 30 per second. You can also make this dynamic by referring to custom variable defined in an API Product E.g. In this configuration, we are referring to a custom attribute called 'spikearrestlimit' and applying it on individual apps.
<SpikeArrest async="false" continueOnError="false" enabled="true" name="Spike-Arrest-1">
<DisplayName>Custom label used in UI</DisplayName>
<Rate ref="verifyapikey.Verify-API-Key-1.apiproduct.spikearrestlimit"/>
<Identifier ref="request.queryparam.apikey"/>
</SpikeArrest>
To support your scenario, you would set spikearrestlimit to '100ps' for Product A and '50ps' for Product B.
Hope this helps!
Hi @sudheendra1,
Thank you for your answer. I understand it but it raises some extra questions for me.
Let's say I use the spikeArrest policy as a business usecase to allow application App1 to make 30ps on backend Bk1 and 50ps on backend Bk2, while application App2 to make 20ps on backend Bk1 and 40ps on backend Bk2.
Then, if I understand correctly, I need at the application level 2 custom attributes: "spikearrestlimit_for_bk1" and "spikearrestlimit_for_bk2".
Using these custom attributes can easily become unmaintainable when dealing with allowing privileged access to 10 backend services because:
- I need to specify unique attribute name for each backend.
- the operation person who will manually indicate the values for each application needs to type correctly each custom attribute.
- the spikeArrest policy needs a complex javascript to check which policy applies: if filled in then the custom attribute on the app level otherwise if filled in the custom attribute on the product level otherwise the default level in the target endpoint.
There must be an easier solution to solve this situation by organizing better the API proxies, products. Could you please advise?
Thank you,
Emilia
Hi @Emilia Ipate It's recommended to use a SpikeArrest policy to protect your target backend against severe traffic spikes and denial of service attacks. If your requirements are around business use cases then use the Quota Policy instead. The Quota policy gives you more flexibility. You can apply a Quota at both API Product and API proxy level. Like SpikeArrest you can apply Quota based on Apps & Developers as well.
Typically you group your APIs into Products and apply a limit. Let's say based on the subscription level : Gold, Silver and Platinum and apply three different quota limits. If you like to set different limits per API proxy, then configuration might become messy & soon become unmaintainable as you rightly indicated.
You can place policies sequentially and put a conditional statement to see a policy needs to be executed or not. You don't need to do this check in JS. You need to be careful though. As the combinations increase your proxy configuration becomes complex.
Hi @sudheendra1,
You suggest that I can put policies sequentially... I don't fully understand this solution:
- I should add a quotaLimit policy which runs if the "limit" custom attribute at application level is filled in
- I should add a quotaLimit policy which runs if the "limit" custom attribute at product level is filled in
But it's possible that both attributes are filled in and then both policies will run when in practice I want only the limit set at the application level to run because it overrides the product quota.
