WASM extensions filter

[szuecs]

Is your feature request related to a problem? Please describe.

I want to have a WASM extension filter to execute safely custom code from users.

Describe the solution you would like

A filter wasm("https://wasm-src.example") would fetch at start the wasm bundle from the given URL. It should run as part of the filter execution. Updating the wasm bundle should be able to achieve in a background goroutine if possible.

some libraries that could help loading WASM:

• https://github.com/tetratelabs/wazero has no dependencies and seems to be an active project
• https://github.com/wasmerio/wasmer-go seems to be outdated and not in active development (last commit 2y ago, last release 08/2021)

Describe alternatives you've considered (optional)

We have lua as script filter extension already, but this has access to filesystem support and it's not easy to disable and such that to secure the runtime from users that can change routes. Users that are able to change routes like kubernetes ingress objects are not having full skipper runtime permissions but with lua they could get this.

[AlexanderYastrebov]

Fetching wasm from remote would be the fastest way to pwn skipper :)

I think the trickiest part would be to define filter context interface between go and wasm.

[szuecs]

Fetching wasm from remote would be the fastest way to pwn skipper :)

What's different to lua and why do you think that wasm will be less safe to execute?
IIRC WASM tries to be ok to run from an hostile environment.

I think the trickiest part would be to define filter context interface between go and wasm.

yes of course!
I just wanted to check out how the first step could look like.

[AlexanderYastrebov]

https://github.com/jcbhmr/awesome-webassembly-runtimes

[szuecs]

This Awesome project as a list of abandoned projects (at least the Go versions are not all maintained) and what we need is a proper runtime to host in Go, which reduces the amount of projects we can use.
I am not sure if every runtime can run any created wasm binary (do they call it binary?) but that's what I suppose to be the case.

[szuecs]

I read https://github.com/tetratelabs/proxy-wasm-go-sdk docs and scrolled a bit their code, examples and overview. For me it seems very "generic" to fit envoy proxy. As also the overview docs show. I think this project is not a good fit to use for a wasm filter in skipper. Envoy creates on VM per Thread and use thread-local memory, they also seem to work on the base http stream api and therefore you have a very low level style of work, which is not necessary in our case. Maybe we can see how to use Go interfaces and something like a table (thinking of the lua table in skipper) to pass around the data that you would need to allow to access from a filter (FilterContext like thing).