Support for alternative Gateway API implementations

[aharbis]

We are working on a new Gateway API implementation, and are interested in integrating it with Kuadrant. Reviewing the Kuadrant architecture and documentation, it appears to be tightly coupled to Envoy Gateway/Proxy as the Gateway API implementation.

Is there a roadmap for Kuadrant to support a "bring your own Gateway API implementation" approach to policy enforcement in Kubernetes?

[guicassolato]

Thanks for opening this issue, @aharbis. We're definitely looking into supporting other Gateway API implementations even if not in the roadmap officially yet.

About "bring your own Gateway API implementation", that's an interesting question. Right now, we are somewhat tied to Proxy-Wasm and even some host (Envoy) specific pieces. That doesn't mean being close to the idea however. Quite on the contrary!

[aharbis]

Great. Do you envision proxy-wasm always being a required shim between Kuadrant and Gateway API implementations, or could there be a path to integrate a Gateway API implementation directly (using just Gateway API resources)?

[guicassolato]

Great. Do you envision proxy-wasm always being a required shim between Kuadrant and Gateway API implementations, or could there be a path to integrate a Gateway API implementation directly (using just Gateway API resources)?

That's a good question.

We have no plans to shift away from using proxy-wasm entirely. Most likely, we would maintain it in some form for the foreseeable future.

This doesn't mean in the long term a direct integration without wasm is completely off the table though. In fact, Kuadrant's DNSPolicy and TLSPolicy don't depend on it already, and there's been activity in Gateway API suggesting that it could be possible for the AuthPolicy and RateLimitPolicy too (e.g. GEP-1494, with some degree of speculation.)

[aharbis]

I understand that proxy-wasm is used for injecting the policy enforcement into the Gateway (Envoy Proxy, in this case). I'm wondering if there's a path where, if the Gateway supports a policy attachment that could support the Kuadrant flavor of policies, the proxy-wasm approach could be circumvented. Or, would you envision such an integration to have the prerequisite that those Kuadrant policies must be merged into the upstream Gateway API (e.g., the AuthPolicy example you gave).

Would Kuadrant be open to allowing the Gateway to enforce the Kuadrant policies natively, or is the intent to always offload this enforcement to separate microservices (e.g., via proxy-wasm)?

[aharbis]

@guicassolato have you had a chance to review my last comment / questions?

[guicassolato]

Hi @aharbis. I believe I missed your comment. Sorry about that.

if the Gateway supports a policy attachment that could support the Kuadrant flavor of policies, the proxy-wasm approach could be circumvented.

proxy-wasm seemed once to be the best approach for Kuadrant, given the interoperability goal we had and, most importantly, the limitations from the underlying supported Gateway API implementations to configure the triggers for the Kuadrant policy enforcement components (auth and rate-limit), at the granularity we desired (level of specific HTTPRoute rules.)

That said, there's no hard prerequisite for the integration to be handled via wasm module per se. We do not want or have the capacity to maintain two very different kinds of integration. However, from a technical point of view, there's probably no reason to oppose a more "direct" integration IMO.

A small piece of advice to whoever wants to explore this route: Kuadrant's wasm module is conceptually simple. It basically routes the request to trigger, in a given order, specific sets of policy rules. Its configuration consists of a mapping of HTTP attributes to action types/IDs – e.g., GET /foo/* → (auth:123, rate-limit:456). At the same time, it gives Kuadrant some flexibility to occasionally support different flows, as well as new features and kinds of policies (e.g., pre-auth rate-limit, different kind of HTTP filter). Any alternative architecture should probably take this into account.

Would Kuadrant be open to allowing the Gateway to enforce the Kuadrant policies natively, or is the intent to always offload this enforcement to separate microservices (e.g., via proxy-wasm)?

I certainly cannot speak alone for Kuadrant, but my impression is that replacing the wasm shim is a relatively easy task compared to full enforcement of Kuadrant policies natively (or what I understand by that.) Especially Authorino is a fairly complex piece that I struggle to see replaced entirely by the gateway alone. Offloading the processing to the external service will likely continue to be the preferred approach here.

cc @maleck13 @alexsnaps