[Discuss] Implement WebAssembly (WASM) in Kibana

[bhapas]

This goal of this issue is to discuss multiple options to implement WASM into Kibana. This focuses on WASM builds from Golang. Implementation details on Golang side are out of scope for this issue since it does not affect the way wasm module is applied in Kibana.

Background

WebAssembly is a high-performance assembly-like language that can be compiled from various languages, including C/C++, Rust, Go and AssemblyScript. Currently, it is supported by Chrome, Firefox, Safari, Edge, and Node.js!

Usecase

This issue focuses on building WASM modules from Golang. There are a few tools in Golang that can be used in Kibana for solving different problems like validations etc.,

WASM build

Currently Golang supports building the Go files/packages into wasm modules using different ports:js/wasm wasip1/wasm etc., Out of these wasip1/wasm uses Experimental WASI features in NodeJS , which means there are potential security concerns around this port usage.

That leaves us with usage of js/wasm port, which means the wasm build comes with file.wasm and JS glue filewasm_exec.js to be added to Kibana distribution.

Usage options

• Instantiate WASM module using WebAssembly in Node. This loads the WASM module which has Go functions. But this approach pollutes the global namespace in JS with the Go functions.
  • To go by this problem , an alternative approach is to try instantiating a Worker Thread in Node that performs the job of Instantiating the wasm module and calling the Go functions , since the Worker thread has its own global and does not pollute the Main thread's global namespace
• Run a HTTP service in WASM module and let Node use fetch API to call the service with request params and get Response/Err.

Risks

• Would we be passing large "objects" between Node.js and the WASM module? For native modules and child-processes, this has been a concern because of the time that it takes to serialize the objects across the boundary.

• These WASM calls appear to be blocking, therefore they'd block the event-loop if they take an exceedingly long duration. How long do we anticipate these calls taking?

• Would the WASM module rely on WASI? Node.js has this marked as experimental per the official docs, the GitHub issue about making this stable makes me think WASI has an uncertain future in Node.js

• Even if it wasn’t experimental (which is already quite problematic on its own), it still interfaces with the host system (file system access, sockets, etc.), which might require much more scrutiny to a degree that we might not feel comfortable with:

  The current Node.js threat model does not provide secure sandboxing as is present in some WASI runtimes. While the capability features are supported, they do not form a security model in Node.js. For example, the file system sandboxing can be escaped with various techniques. The project is exploring whether these security guarantees could be added in future.

• [ ] Does WASM work well when Kibana is run in FIPS mode [ cc: @legrego ]

• [ ] What offerings does this support

  • [ ] ESS
  • [ ] ECK
  • [ ] Serverless
  • [ ] On Prem

cc: @azasypkin @kobelb @elastic/kibana-security

[elasticmachine]

Pinging @elastic/security-scalability (Team:Security-Scalability)

[bhapas]

https://github.com/elastic/kibana/pull/198935 is added to test the wasm execution in an own Worker Thread. This seems to work fine from functionality point of view. Currently it spawns a new thread just to get the validation job done and this shall be a short-lived thread.

Now this shall be measured for performance and latency to see if it is hindered.