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.

Sign up for GitHub

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

Jump to bottom

Feature Request: Add caching for ExtAuthZ responses #37449

Open
agrawroh opened this issue Dec 2, 2024 · 4 comments
Open

Feature Request: Add caching for ExtAuthZ responses #37449

agrawroh opened this issue Dec 2, 2024 · 4 comments
Labels
area/ext_authz enhancement Feature requests. Not bugs or questions.

Comments

@agrawroh
Copy link
Contributor

agrawroh commented Dec 2, 2024

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.
@agrawroh agrawroh added enhancement Feature requests. Not bugs or questions. triage Issue requires triage labels Dec 2, 2024
@ggreenway
Copy link
Contributor

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.

@ggreenway ggreenway added area/ext_authz and removed triage Issue requires triage labels Dec 2, 2024
@agrawroh
Copy link
Contributor Author

agrawroh commented Dec 2, 2024

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?

@ggreenway
Copy link
Contributor

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.

@tyxia
Copy link
Member

tyxia commented Dec 3, 2024 •
edited
Loading

cc @yanavlasov and @krajshiva, I think we have planned this ext_authz cache work internally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/ext_authz enhancement Feature requests. Not bugs or questions.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ggreenway @agrawroh @tyxia