-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Feature Request: Add caching for ExtAuthZ responses #37449
Comments
How would you identify which requests are a cache hit vs cache miss? The ext_authz service currently receives nearly all information about a request, but Envoy doesn't know what fields it actually uses to decide whether a request is authorized or not. |
I was thinking if we could take a similar approach to what the HTTP Cache filter does by introducing an option to specify an allowlist of headers that can be varied. Everything else could be used to decide whether a response should be cached. What do you think? |
It wouldn't just be headers: it could be any property including client IP address, TLS session properties, time request is received, http protocol version, etc. |
cc @yanavlasov and @krajshiva, I think we have planned this ext_authz cache work internally. |
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions. |
This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions. |
Title: Feature Request: Add caching for ExtAuthZ responses
Description
Currently, we have the Simple HTTP Cache, which can be used to cache responses from the final upstream, thereby improving processing speed for subsequent requests with identical state. Similarly, there is a caching mechanism for JWT Authentication to store the JWKS received from the server.
Would it make sense to extend caching to the ExtAuthZ filter based on similar principles? This would eliminate the need to query the ExtAuthZ server for every subsequent request, significantly improving performance and reducing latency.
While it is technically possible to achieve this today by routing ExtAuthZ requests to a separate Envoy listener and applying the HTTP Cache filter there, this approach introduces complexity. It can lead to confusing logs and additional challenges in diagnosing failures.
Proposal
Integrating caching directly into the ExtAuthZ filter would provide a simple solution as it would simplify configurations by avoiding the need for a separate listener. It'll help enhance the efficiency by handling caching natively within the filter.
The text was updated successfully, but these errors were encountered: