Add Support for WAF

[danehans]

Description:

Add WAF support. The implementation should focus on coraza-proxy-wasm but allow other WAF solutions in the future.

• Create a design doc for the user-facing API. See Add authn policy design with JWT only #529 (draft) as an example.
• Update xds IR.
• Update the Kube provider to reconcile the WAF Custom Resource.
• Update the resource translator to translate the WAF Custom Resource into IRs.
• Update the xds translator to translate the xds IR into xds APIs, e.g. ECDS.
• Add a user-facing doc and link into Sphinx docs, e.g. user_docs.rst.
• Others?

This issue depends on #71 and/or #24.

[nacx]

The coraza-proxy-wasm project leverages the coraza library via WASM so that it can be used in plain Envoy sidecars and gateways. Since Envoy Gateway is already written in Go, support for WAF could be native using directly the Coraza library without the need for the WASM module.

[danehans]

@nacx thanks for providing input on this issue. To make sure I understand your comment, are you suggesting that this feature be implemented as an ExternalProcessor filter instead of a Wasm filter?

[nacx]

My bad. I was mixing the runtime with the control plane, so the suggestion won't apply beyond the fact that coraza is fully written in go and that the project could leverage that, if needed. But at runtime, the wasm module should be the way to go.

[arkodg]

this issue shouldnt depend on #71, both the issues are orthogonal, #71 is about exposing a user facing API for WASM, this issue might use WASM which is an internal implementation detail

[Xunzhuo]

this issue shouldnt depend on #71, both the issues are orthogonal, #71 is about exposing a user facing API for WASM, this issue might use WASM which is an internal implementation detail

Yes, I am willing to design and implement #71 and this issue, since I am familiar with proxy-wasm. But not sure for the issues priorities, maybe this can be done in v0.3.0, but I can not promise this, this depends on the status of issues I already assigned in v0.3.0 and the priority of wasm extension support.

[anuraaga]

Hi all - copying some points from the email thread on this.

It can be useful to align with OWASP as there is a large ecosystem and a lot of history there in applying WAF for compliance such as with payment processing. Coraza is an implementation of OWASP that fully supports its coreruleset and configuration language. It has made Envoy support a priority, accepting changes for building to Wasm with TinyGo and including a TinyGo-based build in CI to prevent regressions when integrated to Envoy.

We will be doing more scientific analysis of coraza-proxy-wasm's performance in the next couple of weeks - for now, we see unscientific numbers of ~3ms of overhead for requests with small payloads. It will be important to get distributions correlated with payload size, and a comparison of WAF via coraza directly in a Go server vs using wasm middleware. Will followup here when having some more useful numbers.

If going with wasm, though, we need to get the wasm support itself in Envoy out of alpha state and need to understand what is required for that and the staffing for it.

[zhshw]

@danehans hi brother, start this plan. write the design document first. Let's implement it together

[danehans]

Let's first get v0.3 released and then review the backlog, prioritize issues, understand capacity, etc. as part of v0.4 planning.