You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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
The text was updated successfully, but these errors were encountered: