Envoy Gateway Support

[alexsnaps]

While there isn't first class support for Wasm extensions yet in Envoy Gateway, it might be feasible to use EnvoyPatchPolicy to achieve some of our goals right now, possibly with the use of the Extension Manager.

This issue's goal is to track the work and/or dependencies so we can support Envoy Gateway as Gateway API provider.

Initial Tasks

• Spike investigation in using EnvoyPatchPolicy and/or Extension Manager to register our extensions and configure things according to the state of the cluster's network objects (we would initially need to watch all resources ourselves as far as I can tell, just like with Istio/OSSM) #567
• Spike into seeing what's missing to add support for Policy Attachment to Envoy Gateway, just like it does for ExtensionFilters.
• Have Istio optional #645
• istio-optional: iteration 2 #681
• Wasm binary served from kuadrant operator workload  #686

Tasks

• envoygateway dev environment install #678
• Rate limit policy implementation: Rate Limit EnvoyExtensionPolicy controller
• Authorization policy implementation: SecurityPolicy controller

Further questions

• How would EG calling back into the Kuadrant Operator about topology changes be addressed and what would it mean for our DAG proposal?
• Are there issues in having out-of-order changes handled by EG and Kuadrant mutations of the config thru EnvoyPatchPolicy
• Are there unresolved dependencies in EG for us to get this done at all?

[eguzki]

Added #567 to report findings

[eguzki]

How would EG calling back into the Kuadrant Operator about topology changes be addressed and what would it mean for our Kuadrant/architecture#29?

That's the Envoy Extension Manager and EnvoyGateway has already APIs (CRDs) to do the same. No need to implement service endpoint to patch envoy xDS resources. Actually, the clean way to go for WASM is the EnvoyExtensionPolicy where WASM will eventually be supported. It is just not there yet. This envoyproxy/gateway#3164 already merged PR needs to be shipped in a release. Hopefully in v1.1

Are there issues in having out-of-order changes handled by EG and Kuadrant mutations of the config thru EnvoyPatchPolicy

TL;DR: we need to investigate when EnvoyExtensionPolicy API is there available. WE need to enforce that rate limiting happens after external auth filter.

Are there unresolved dependencies in EG for us to get this done at all?

EnvoyExtensionPolicy API. But we can start using it by patching configuration in raw mode using EnvoyPathPolicy, which requires advanced users who are well versed in Envoy xDS API and its capabilities. Furthermore, the API might remain unstable across versions due to potential changes in the Envoy Proxy API or Envoy Gateway’s xDS translation