9 ms·

It consolidates Go compiled to WASI as an alternative of doing containers. Linux containers don't "Run anywhere." as docker.io says. You need a specific archite

It consolidates Go compiled to WASI as an alternative of doing containers. Linux containers don't "Run anywhere." as docker.io says. You need a specific architecture and kernel features, which is not obvious from afar. There's also other benefits. Example: the team I work on compiled Kyverno, a CNCF K8s policy engine written in Go, to a WASI target. We are building Kubewarden, a CNCF policy engine where policies are Wasm binaries shipped in OCI registries. We strive to build "a Universal Policy Engine". Now, we have an experimental Kubewarden policy `kyverno-dsl-policy` that allows you to reuse Kyverno DSL with us. We also provide WaPC as a target, more performant and secure, hence normal SDKs for Go, Rust, C#, swift, typescript... In addition to supporting Rego, again compiled to Wasm. IMHO you only benefit from the real sandboxing from WaPC, as WASI's posix-like interface allows you to attack the host. The next step for the official Go compiler is to export the function symbols, to allow for WaPC.

rockwotj 3y ago
How is the Universal Policy Engine different than Open Policy Agent?
- viccuad 3y ago
  Just gave a talk on Monday about it in containerdays.io, but the video is not in youtube yet! In a nutshell, with Kubewarden we strive to build the universal policy engine by: - Provide all personas (policy consumer, policy developer, policy distributor, engine admin, engine developer/integrator, etc) with current and future industry-standard workflows, not only a subset of personas, nor more than needed knowledge for those personas. It's a bold statement, and if it would be universal it should indeed cater to everyone. - This is achieved with policies as code, which are Wasm modules: Wasm policies allows us to support Rego DSL (OPA/Gatekeeper), YAML, SDKs for Wasm-compiled languages, and now an experimental Kyverno DSL policy by compiling it to WASM with WASI. Great for using your language and tools of preference. - Wasm modules have first class support In OCI registries, just like container images: Use same tools that you know as artifact distributor: SBOMs, signing and verifying with cosign, airgap, slsa.dev, etc. - Policies can be evaluated out-of-cluster: great for CI/CD, dev loop, integration tests, etc. - Modular architecture informed by using Wasm policies: OCI registry, policy-server, k8s controller, out-of-cluster cli (kwctl), etc. This also helps in adopting future industry-standard workflows. - Usual features of a Policy engine (mutating, context-aware, recurring scanner of already in-cluster resources, etc). Plus ample room for new features thanks to the architecture. E.g: possibility to run the policy-server directly in the k8s apiserver (one colleague already presented that in Kubecon), possibility to evaluate out-of-cluster policies outside of clusters like OPA just by running the policy-server standalone, more DSLs compiled to Wasm, more languages, etc. - Vendor neutral, CNCF project, open source, developed in the open.
Thaxll 3y ago
As if WASI does not need specific architecture and kernel features?
- carbotaniuman 3y ago
  WASI runners are just an application. I guess you need your kernel to run prograns and have syscalls, but that is a low bar.
  - Thaxll 3y ago
    Docker needs the 3.10 kernel which is 10 years old.
    - mbertschler 3y ago
      But it needs Linux, while wasm runtimes are available for all OSes natively
    - est31 3y ago
      It also needs root access, and 3.10 is only the lowest supported kernel. Not a docker expert but I could bet that they only support a subset of features there. What I do know is that docker images are specific to the host architecture, supporting either one architecture, or a blessed list. wasm binaries on the other hand aren't. wasm can theoretically also run on bare-metal embedded scenarios without an OS entirely.
- DanielHB 3y ago
  Technically you don't need a full kernel, edge workers will likely have their own custom trimmed down kernels for running WASM binaries, cutting out a lot of the OS overhead. As long as they implement a limited set of POSIX syscalls they can run WASM binaries, in fact you might even want to limit the WASI syscalls you implement for certain targets.

rockwotj 3y ago

How is the Universal Policy Engine different than Open Policy Agent?

viccuad 3y ago
Just gave a talk on Monday about it in containerdays.io, but the video is not in youtube yet! In a nutshell, with Kubewarden we strive to build the universal policy engine by: - Provide all personas (policy consumer, policy developer, policy distributor, engine admin, engine developer/integrator, etc) with current and future industry-standard workflows, not only a subset of personas, nor more than needed knowledge for those personas. It's a bold statement, and if it would be universal it should indeed cater to everyone. - This is achieved with policies as code, which are Wasm modules: Wasm policies allows us to support Rego DSL (OPA/Gatekeeper), YAML, SDKs for Wasm-compiled languages, and now an experimental Kyverno DSL policy by compiling it to WASM with WASI. Great for using your language and tools of preference. - Wasm modules have first class support In OCI registries, just like container images: Use same tools that you know as artifact distributor: SBOMs, signing and verifying with cosign, airgap, slsa.dev, etc. - Policies can be evaluated out-of-cluster: great for CI/CD, dev loop, integration tests, etc. - Modular architecture informed by using Wasm policies: OCI registry, policy-server, k8s controller, out-of-cluster cli (kwctl), etc. This also helps in adopting future industry-standard workflows. - Usual features of a Policy engine (mutating, context-aware, recurring scanner of already in-cluster resources, etc). Plus ample room for new features thanks to the architecture. E.g: possibility to run the policy-server directly in the k8s apiserver (one colleague already presented that in Kubecon), possibility to evaluate out-of-cluster policies outside of clusters like OPA just by running the policy-server standalone, more DSLs compiled to Wasm, more languages, etc. - Vendor neutral, CNCF project, open source, developed in the open.

Thaxll 3y ago

As if WASI does not need specific architecture and kernel features?

carbotaniuman 3y ago
WASI runners are just an application. I guess you need your kernel to run prograns and have syscalls, but that is a low bar.
- Thaxll 3y ago
  Docker needs the 3.10 kernel which is 10 years old.
  - mbertschler 3y ago
    But it needs Linux, while wasm runtimes are available for all OSes natively
  - est31 3y ago
    It also needs root access, and 3.10 is only the lowest supported kernel. Not a docker expert but I could bet that they only support a subset of features there. What I do know is that docker images are specific to the host architecture, supporting either one architecture, or a blessed list. wasm binaries on the other hand aren't. wasm can theoretically also run on bare-metal embedded scenarios without an OS entirely.
DanielHB 3y ago
Technically you don't need a full kernel, edge workers will likely have their own custom trimmed down kernels for running WASM binaries, cutting out a lot of the OS overhead. As long as they implement a limited set of POSIX syscalls they can run WASM binaries, in fact you might even want to limit the WASI syscalls you implement for certain targets.