Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple quotas on a single endpoint #25606

Closed
alexdawn opened this issue Feb 23, 2024 · 1 comment
Closed

Multiple quotas on a single endpoint #25606

alexdawn opened this issue Feb 23, 2024 · 1 comment

Comments

@alexdawn
Copy link

Is your feature request related to a problem? Please describe.
I'm looking to implement a tool that will bulk decrypt emails, there is a valid use case for adhoc queries (e.g. notifications product recalls, shipping delays etc...) each row of personal data is encrypted with a derived key using the vault transit api so to get an email list a tool is needed to decrypt each row with a suitable context.

Describe the solution you'd like
The quota tool looked the ideal way to throttle user usage to give a balance between allowing them to get hold of an email list, while preventing them from getting a complete list, without enough time for logging and monitoring to pick up on the suspicious usage.

However for this to work ideal would like to be able to implement more than one quota. The first quota to operate over short intervals, and the second quota for a larger amount over a longer interval to defeat any user attempting to throttle requests to beat the first quota. An example would be something like a user should be limited to say 1 key a second, but also a second quota of 1,000 keys per day.

However this isn't possible by design: #18164
While it makes sense that having two quotas for the same interval shouldn't be allowed, different quotas operating on different timescales should be valid.

Describe alternatives you've considered
I've considered client side restrictions, but a clever user would be able to tweak the script to give more generous limits.

Explain any additional use-cases
Such a solution would also allow for scaling lock outs, with the larger rate/intervals having a longer lockout.

Additional context
none

@divyaac
Copy link
Contributor

divyaac commented Apr 17, 2024

HI @alexdawn, thanks for the suggestion! Until this is prioritized, might I suggest creating another quota on a parent path? For example, let's say that you have created a very restrict 1 key/second rate limit on the my_namespace/transit/my_key path, you could further create a larger rate limit (ie. 1000 keys/second) on my_namespace/transit so as to limit any requests made to this path as a catch all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants