Rate limits within a "policy" are determined by the user class (the requests ratelimit class). The class is currently set in a Lua filter in Envoy, but should eventually come from a JWT. There is a risk of misalignment between classes in requests and classes for which we have limits defined. We need a catch-all limit definition so unknown classes don't just bypass ratelimiting.
Description
Description
Details
Details
Related Changes in Gerrit:
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| rest-gateway: define catch-all rate limit | operations/deployment-charts | master | +15 -20 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T399291 Epic: API Rate Limiting Architecture | |||
| Open | None | T412585 Epic: Enforce API rate limits (WE5.1.3c) | |||
| Open | daniel | T398919 Epic: API rate limiting dry run (WE5.1.3b) | |||
| Resolved | daniel | T409543 rest-gateway: define a catch-all rate limit |
Event Timeline
Comment Actions
Envoy's ratelimit service configuration supports catch-all rules, but unfortunately they don't play well with metrics keys. relevant upstream ticket: https://github.com/envoyproxy/ratelimit/pull/996. Looks like someone is working on it.
Comment Actions
Change #1202998 had a related patch set uploaded (by Daniel Kinzler; author: Daniel Kinzler):
[operations/deployment-charts@master] rest-gateway: define catch-all rate limit
Comment Actions
Change #1202998 merged by jenkins-bot:
[operations/deployment-charts@master] rest-gateway: define catch-all rate limit