3 ms·

It's not obvious to me how you make capabilities available to the code running inside the WASM virtual environment. The core security advantage of WASM is the

• cpuguy83 5y ago
  It gets setup fairly similarly to how you would run a "normal" runc container. containerd passes along a path to the rootfs of the container (for wasi I'd expect to be just the wasm module) which is built from the OCI image along with a set of mounts the be mounted to the rootfs. The project here goes ahead and performs those mounts to the rootfs path and then maps that rootfs path into wasmtime's WASI config as "/". If you have something like a Kubernetes volume, config map, secret, etc. this is all prepared by Kubelet and winds up as mounts we need to perform as mentioned above.
• voigt 5y ago
  > Included in the repository is a PoC for running a plain wasi host (ie. no extra host functions except to support wasi system calls). Looks like that’s not decided yet. In theory you could use pod.spec.volumes to hand it over to the shim for the wasi preopens.[1] Whether that’s a good idea is the other side of the story… [1] https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-overview.md https://github.com/bytecodealliance/wasmtime/blob/main/docs/...
  • cpuguy83 5y ago
    Volumes are mapped in already. They get mounted to the containers rootfs dir, and that is used as a preopen for wasi. https://github.com/deislabs/runwasi/blob/9a43a31c1f29df653920cdeb5f10f6fa31867b7d/crates/containerd-shim-wasmtime-v1/src/sandbox/shim.rs#L846 https://github.com/deislabs/runwasi/blob/9a43a31c1f29df65392...