Move out of Alpha for Wasm Http filter

[botengyao]

The current HTTP Wasm filter is there around 4+ years. This issue is going to track and gather info until which state we think it is reasonable to move out of alpha to stable based on this extension policy. The key point here to change the status is we want it to be security covered for critical crash bugs and not the performance improvement. And I agree that we need more work to reach there and continuously support it. We already had some valuable discussion on Proxy-Wasm in #35420, here I want to focus on this specific filter.

The following items are a run from extension policy

1. Does the extension have unbounded internal buffering? Does it participate in flow control via watermarking as needed?
   • It is managed by the wasm to isolate the environment.
2. Does the extension have at least one deployment with live untrusted traffic for a period of time, N months?
   • Istio is using Wasm
   • Higress already had 40+ Wasms.
   • Many vendors already run them in prod environment.
3. Does the extension rely on dependencies that meet our extension maturity model?
   As the dependencies, we need to setup the security release and governance. There is a tool that can calculate score, we should run that and see what it identifies. We have C++ and Rust SDKs, and we can treat them separately, to state that e.g., C++ and NullVM is stable as an incremental effort.
   • Proxy_wasm_cpp_host
   • Proxy_wasm_cpp_sdk
   • Com_google_cel_cpp
   • Proxy_wasm_rust_sdk
4. Is the extension reasonable to audit by the Envoy security team?
   • Yes for the filter part.
5. Is the extension free of obvious scary things, e.g. memcpy, does it have gnarly parsing code, etc?
   • No
6. Does the extension have active CODEOWNERS who are willing to vouch for the robustness of the extension?
   • Yes.
7. Is the extension absent a low coverage exception?
   • No, wasm: re-enable envoy wasm coverage build by disabling rust coverage build #36337

Different vendors could use this extension differently, as a first step we need to improve the current status of wasm at least to move out of alpha for the implementations.

• A stable iterated ABI spec from Proxy-Wasm
  • HTTP: add more control over buffering and/or offloading processing to the host proxy-wasm/spec#63
  • https://github.com/proxy-wasm/spec/issues
  • Note: the status of the extension reflects the implementation status not the ABI, we can iterate the ABI versions with more supports.
  • 0.3.0 is on the way
• Security governance of proxy-wasm-cpp-host and proxy-wasm-cpp-sdk as a dependency as a start.
  • scorecard: https://securityscorecards.dev/viewer/?uri=github.com/proxy-wasm/proxy-wasm-cpp-host
  • https://securityscorecards.dev/viewer/?uri=github.com/proxy-wasm/proxy-wasm-cpp-sdk
• Crash bugs in Envoy code from the critical data plane code.
  • large request body result in wasm crash #36989
  • Lifecycle bug in WASM filter #35882
  • WASM Calling proxy_send_local_response twice will stuck remote http client(e.g. curl) forever until timeout or interrupted #28826
  • others?
• Docs for a smooth onboard

I believe the filter itself is a shield of wasm/common + Proxy-Wasm host and SDKs and therefore is stable already IMHO. There's obviously a lot of history here, and I am new to this Wasm field and happy to contribute. The goal here is to create action items to reach consensus so that we can work towards it. Welcome feedback on any/all of the above points.

@mpwarres @martijneken @PiotrSikora @wbpcode @yanavlasov @kyessenov @keith @krajshiva, any thoughts?

[kyessenov]

I'd add that documentation improvement is important for the Wasm filter since it has a difficult ramp-up both for the developers and the operators. And solving the distribution of the Wasm binary in some manner would help here - I believe Envoy Gateway uses HTTP fetch already even thought it is not quite stable (#29824, #33212)