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

feat: Multiple Rate Limiting option (again) #4449

Open
s0uky opened this issue Oct 15, 2024 · 2 comments
Open

feat: Multiple Rate Limiting option (again) #4449

s0uky opened this issue Oct 15, 2024 · 2 comments
Labels

Comments

@s0uky
Copy link

s0uky commented Oct 15, 2024

Description:
This feature request is follow up from Slack discussion with @arkodg .

The functionality for defining multiple rate limits was previously available through RateLimitFilters. However, these filters were removed from the codebase around version 0.6.0. A new CRD named BackendTrafficPolicy was introduced, and the rateLimit field now belongs to this CRD.

It would be beneficial to be able to define multiple rate limits again for entire paths within BackendTrafficPolicy. This would allow for a use case where a "basic" rate limit could be applied to unauthenticated clients, while a stricter "proper" rate limit could be applied to users with valid JWT authentication (basic authentication is a separate consideration).

@s0uky s0uky added the triage label Oct 15, 2024
@arkodg
Copy link
Contributor

arkodg commented Oct 15, 2024

this should be possible with https://gateway.envoyproxy.io/docs/tasks/traffic/global-rate-limit/

Option 1 - match on :path
sometthing like

  rateLimit:
    type: Global
    global:
      rules:
      - clientSelectors:
        - headers:
          - name: :path
            value: /app
        limit:
          requests: 3
          unit: Hour

Option 2
Create 2 HTTPRoutes (same hostname but different rules for different path matches) and apply a unique BTP for each HTTPRoute

@arkodg
Copy link
Contributor

arkodg commented Oct 15, 2024

keeping this issue open so we can consider adding path and method (relates to #4448) as first class fields in the API so users dont need to rely on the pseudo headers

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

No branches or pull requests

2 participants