Wasm I Right or Wasm I Wrong? a Review of the Wasm Ecosystem - Taylor Thomas & David Justice

Wasm I Right or Wasm I Wrong? a Review of the Wasm Ecosystem

Speakers: Taylor Thomas, Engineering Director, Cosmonic; David Justice, Engineering Lead, Microsoft

Conference: KubeCon EU

YouTube: https://www.youtube.com/watch?v=KK0FKiQ7nis

Overview

In this insightful talk, "Wasm I Right or Wasm I Wrong? a Review of the Wasm Ecosystem," Taylor Thomas and David Justice, both co-chairs of the CNCF WASM working group, present an unvarnished truth about the current state, evolution, and future trajectory of WebAssembly (Wasm) in the cloud-native landscape. They meticulously dissect Wasm's inherent advantages, such as its robust security model, unparalleled portability, and impressive performance characteristics, drawing direct parallels to the challenges faced by traditional container-based deployments. The presentation serves as a critical update for anyone interested in the future of application development and deployment, particularly within the cloud-native ecosystem.

The speakers, leveraging their deep involvement in the Wasm community and standard specifications, articulate why Wasm is rapidly gaining traction as a compelling alternative to containers. They highlight its ability to address persistent issues like cold starts in serverless functions, the security vulnerabilities often associated with shared kernels in containers, and the complexities of achieving true "write once, run anywhere" portability. The talk is not merely a promotional piece but a candid exploration of Wasm's strengths, its current limitations, and the significant community efforts underway to mature its ecosystem, especially through the crucial WebAssembly Component Model.

This discussion is particularly vital for developers, architects, and security professionals navigating the complexities of modern distributed systems. As the cloud-native landscape continues to evolve, the need for more secure, efficient, and flexible deployment paradigms becomes paramount. Thomas and Justice position Wasm as a technology uniquely poised to meet these demands, offering a pathway to applications that are not only faster and smaller but also inherently more secure and composable across diverse languages and environments. Their review underscores Wasm's potential to redefine how we build, deploy, and secure cloud-native applications, moving beyond the limitations of current container-centric approaches.

Background

▶ Watch: Speakers introduce themselves and the talk topic (0:00)

WebAssembly's journey began with ASM.js around 2013-2014, eventually evolving into a core W3C standard. Its initial purpose was to bring high-performance, near-native execution speeds to web browsers, enabling complex applications like Autodesk and Adobe suites to run directly in the browser. The factors that made Wasm successful in the browser environment – being an open W3C standard, sandboxed by default, small, fast, polyglot (supporting languages like C, C++, Rust), and inherently portable across different operating systems and browsers – are precisely the qualities sought after in the cloud.

The speakers draw a stark contrast between Wasm and traditional container technologies in the cloud. While containers offered significant improvements over previous deployment models, they often fall short on several fronts that Wasm inherently addresses. For instance, the claim that containers are "so secure" has frequently been undermined by CVEs that exploit shared kernel vulnerabilities. Wasm, by design, offers a stronger isolation model, running untrusted code in a secure sandbox without direct access to the host system. Similarly, the "portability" of Docker images is often illusory; developers must build separate images for different architectures and operating systems, a process that Wasm's single binary format simplifies dramatically. For Functions-as-a-Service (FaaS), Wasm's small footprint and rapid startup times significantly mitigate the dreaded "cold start" problem, offering superior performance.

However, core Wasm, at its fundamental level, is a low-level instruction set operating with basic types like i32s, pointers, and lengths – what the speakers jokingly refer to as "numbers and trench coats." While this provides immense flexibility, it necessitates the creation of custom Application Binary Interfaces (ABIs) to handle high-level data types (e.g., strings, complex objects) when interoperating between Wasm modules and host environments or other modules. This process is tedious, error-prone, and leads to vendor lock-in or fragmentation, as each custom ABI binds a module to a specific runtime or library.

To overcome this fundamental limitation, the WebAssembly Component Model emerged as a critical innovation. Inspired by solutions like Protobuf for gRPC, the Component Model introduces wit files (WebAssembly Interface Type files). These wit files provide a high-level language to describe interfaces, allowing for the automatic generation of ABIs across various programming languages. This standardization enables true polyglot composition, where components written in different languages (e.g., Rust and Go) can seamlessly communicate and be composed together without needing to understand each other's underlying language implementation, fostering a truly modular and interoperable ecosystem.

Key Findings

▶ Watch: WebAssembly fulfills the 'write once, run anywhere' promise (4:00)

The talk highlights several pivotal findings regarding WebAssembly's current state and future impact:

• Wasm as a Superior Cloud-Native Runtime: Wasm's core attributes—inherent sandboxing, minimal footprint, rapid startup, and true portability—make it exceptionally well-suited for cloud-native applications, particularly for serverless functions, edge computing, and microservices. It directly addresses security vulnerabilities and performance bottlenecks (like cold starts) associated with container-based deployments.
• The Transformative Power of the Component Model: The WebAssembly Component Model is identified as the linchpin for Wasm's broad adoption and success. By standardizing ABIs through wit files, it resolves the complex challenge of inter-language communication and module composition. This model enables polyglot development, allowing developers to combine components written in different languages (e.g., Rust and Go) into a single, cohesive application, fostering unprecedented flexibility and reusability.
• Rapid Evolution Towards Stability: The Component Model and WASI (WebAssembly System Interface) are actively evolving. The current WASI 0.2.0 is progressing with non-breaking changes, with WASI 0.3.0 on the horizon, promising features like native async support and ergonomic improvements. The ultimate goal is a stable 1.0.0 release, which will solidify the foundation for building production-grade applications.
• "Worlds" for Ecosystem Bootstrap: The concept of Worlds—collections of interfaces (e.g., Wasloud, Wasi TLS)—is crucial for bootstrapping developers into the Wasm ecosystem. These predefined interface sets provide common functionalities, allowing developers to build upon existing standards or define their own without resorting to custom, incompatible ABIs.
• Widespread Production Adoption: The talk showcases a diverse array of projects and companies already leveraging Wasm in production, demonstrating its practical utility across various domains. Examples include:
• WASMCloud (orchestration for Wasm components)
• Spin (microservice applications with Wasm components)
• RenderLit (graphics rendering pipelines using web GPU)
• Zed (code editor extensions)
• Kubewarden (Kubernetes policy enforcement)
• Hyperlight Wasm (hypervisor-level isolation for Wasm)
• Google Cloud Service Extensions (proxy Wasm filters)
• Inspector Gadget (eBPF instrumentation with Wasm support)
• NGINX Unit (high-performance server extensions)
• WasmEdge (edge runtime with AI capabilities)
• Various databases (e.g., Postgres, Redis, MongoDB, MySQL, Cassandra) for user-defined functions (UDFs) and stored procedures.
• Wasm as the Ultimate Plugin Model: The speakers envision Wasm as the "plug-in model to end all plug-in models." Its self-describing nature and sandboxing capabilities enable secure, fine-grained control over plugin behavior, offering a superior alternative to arbitrary binaries for extending systems like kubectl or implementing Kubernetes webhooks.
• Critical Need for Go Support: A significant call to action is the urgent need for robust, pure Go support for the Component Model. Given the prevalence of Go in the CNCF ecosystem, enhancing Go's ability to build and run Wasm components without Cgo or shared library linking (TinyGo limitations, Wasmtime's Rust core) is essential for Wasm's wider adoption and integration within cloud-native projects.

Technical Deep Dive

▶ Watch: Understanding core WebAssembly's low-level interface limitations (4:40)

At its core, WebAssembly (Wasm) is a low-level binary instruction format designed for efficient execution. It operates on fundamental types like i32s and i64s, representing integers, and manipulates memory through raw pointers and lengths. This "numbers and trench coats" approach grants Wasm its exceptional performance and compactness but also necessitates a sophisticated layer for handling higher-level data structures and inter-module communication.

This is where the WebAssembly Component Model becomes indispensable. The Component Model acts as a thin, highly efficient veneer around standard Wasm modules. It doesn't fundamentally change the underlying Wasm binary format but rather provides a standardized way to describe and interact with a module's imports and exports. This layer performs lifting and lowering operations:

• Lifting: Converts raw Wasm types (like pointers and lengths) into concrete, high-level types understood by the host programming language (e.g., a (pointer, length) pair becomes a string in Rust or Go).
• Lowering: Converts concrete language types back into raw Wasm types for execution within the Wasm module.

This process introduces minimal overhead, typically not a bottleneck for general-purpose use cases, making it suitable for performance-sensitive applications.

The practical implementation of the Component Model, while complex to develop once for a runtime, delivers immense benefits across the entire ecosystem. It uses wit files (WebAssembly Interface Type files) to define interfaces. A wit file specifies the data types and functions a component imports or exports, much like Protobuf schema defines messages and services for gRPC. From a wit file, language-specific bindings (ABIs) can be automatically generated, allowing components written in different languages (e.g., a Rust component exporting a function and a Go component importing it) to interoperate seamlessly without any language-specific knowledge. This polyglot composition is a cornerstone of the Component Model's power, enabling developers to mix and match the best tools for the job.

The WebAssembly System Interface (WASI) works hand-in-hand with the Component Model by standardizing common system-level functions, such as file system access, network communication, and environment variables. These functionalities are not built into Wasm itself; rather, they are provided by the host runtime that executes the Wasm module. The Component Model's evolution, currently at WASI 0.2.0 and progressing towards 0.3.0 (introducing native async capabilities and ergonomic improvements) and ultimately a stable 1.0.0, aims to solidify these interfaces. The concept of Worlds further organizes these interfaces into logical collections (e.g., Wasloud, Wasi TLS), providing ready-to-use sets of capabilities for specific application domains.

A critical security implication of the Component Model is its self-describing nature. Every Wasm component explicitly declares what interfaces it imports and exports. This transparency allows the host runtime to inspect a component's requirements before execution. For instance, if a component attempts to import a file system interface, the host can:

1. Deny the access entirely.
2. Virtualize the access, providing an in-memory file system or a restricted view of the host's file system (e.g., limiting access to a specific directory path).
3. Audit and log all file system operations.

This fine-grained control over capabilities represents a significant security enhancement over opaque binary plugins, where malicious code could perform arbitrary actions.

This concept of enhanced isolation is further exemplified by projects like Hyperlight Wasm, a CNCF project developed at Microsoft. While Wasm's sandbox is provably secure at the module level, the host runtime that provides WASI interfaces (e.g., handling HTTP requests or file system calls) is still part of the trusted compute base. Bugs in this host layer can lead to CVEs, similar to how vulnerabilities in a shared kernel can impact containers. Hyperlight Wasm addresses this by providing a hypervisor boundary around Wasm components. It essentially treats Wasm modules as micro-VMs, offering an additional layer of defense-in-depth, particularly vital for highly sensitive workloads in public clouds where maximum isolation is paramount. This robust security model, combined with the Component Model's interoperability, positions Wasm as a powerful and secure foundation for the next generation of cloud-native applications.

Demo / Proof of Concept

▶ Watch: WIT: a high-level language for describing WebAssembly interfaces (5:40)

While the talk did not feature a live, interactive demo or a traditional proof of concept, the speakers effectively illustrated Wasm's capabilities and security benefits through practical examples and a conceptual demonstration of its plugin model. They extensively highlighted numerous real-world projects and companies already leveraging Wasm in production, serving as a comprehensive demonstration of its applicability across diverse use cases.

Key projects mentioned that implicitly serve as "proofs of concept" for Wasm's utility include:

• WASMCloud: An orchestration layer that allows developers to program entire platforms using Wasm components, demonstrating its utility for building composable, distributed systems.
• Spin: A framework for building microservice applications with Wasm, showcasing developer experience and rapid iteration.
• Kubewarden: Enables writing Kubernetes policies in any preferred language, compiled to Wasm, to enforce cluster policies securely.
• Hyperlight Wasm: A CNCF project offering hypervisor-level isolation for Wasm components, illustrating advanced security paradigms.
• Inspector Gadget: Integrates Wasm to allow custom eBPF gadgets for instrumenting and collecting data, highlighting its extensibility for observability.
• NGINX Unit: Provides Wasm support for building high-performance server extensions, demonstrating its use in critical infrastructure.
• Various databases (e.g., Postgres, Redis) that use Wasm for user-defined functions (UDFs) and stored procedures, proving its capability for bringing compute closer to data.

Furthermore, a conceptual example of using Wasm for kubectl plugins served as a powerful illustration of Wasm's security advantages. In a traditional scenario, a kubectl plugin is an arbitrary binary downloaded from the internet, posing significant security risks (e.g., curl | sudo bash leading to unauthorized file system access like /etc/passwd). With a Wasm-based plugin, the Component Model's self-describing nature means the plugin explicitly declares its required imports (e.g., file system access). The host runtime can then inspect these declarations and:

1. Deny access to sensitive resources.
2. Virtualize access, providing a restricted file system view or an in-memory file system.
3. Provide specific interfaces, such as a Kubernetes:client interface, allowing the plugin to interact with the cluster securely without pulling in heavy client libraries like client-go.

This conceptual "demo" effectively conveyed how Wasm, through its sandboxing and explicit interface definitions, can transform insecure plugin architectures into robust, auditable, and highly controlled extension mechanisms, significantly enhancing the security posture of extensible systems.

Defensive Implications

▶ Watch: Component Model: enabling interoperability and avoiding vendor lock-in (6:40)

WebAssembly introduces several profound defensive implications that fundamentally enhance the security posture of cloud-native applications, addressing many inherent vulnerabilities found in traditional containerized environments.

1. Enhanced and Provable Sandboxing: Unlike containers, which rely on a shared kernel and can be susceptible to CVEs that exploit kernel vulnerabilities, Wasm provides a provably secure sandbox by default. A Wasm module has no inherent access to the host's file system, network, or environment variables. All system interactions are mediated through explicit WASI interfaces provided by the host runtime. This drastically reduces the attack surface and isolates untrusted code, making it far more challenging for a compromised module to escape its sandbox and affect the host system or other modules.

1. Fine-Grained Capability Control: The WebAssembly Component Model empowers host runtimes with unprecedented control over module capabilities. Each Wasm component is self-describing, meaning it explicitly declares all interfaces it intends to import (e.g., file system access, network requests). Defenders can inspect these declarations and implement granular policies:

• Denial: Completely block access to sensitive resources (e.g., deny all file system access).
• Virtualization: Provide a virtualized or restricted version of a resource. For example, a Wasm module requesting file system access can be given an in-memory file system or a restricted view of a specific directory, preventing access to the broader host file system. This mitigates risks like relative pathing vulnerabilities mentioned in the talk.
• Policy Enforcement: Tools like Kubewarden leverage Wasm to write and enforce Kubernetes admission policies. This allows organizations to define custom security rules in a polyglot manner and apply them to cluster resources, ensuring compliance and preventing misconfigurations.

1. Reduced Supply Chain Risk for Plugins and Extensions: The self-describing nature of Wasm components significantly improves the security of plugin ecosystems. Instead of relying on arbitrary, opaque binaries (as seen in the kubectl plugin example), Wasm components declare their capabilities. This allows platforms to perform static analysis or runtime checks to ensure a plugin only requests necessary permissions. This transparency helps mitigate risks associated with downloading and executing untrusted code, moving away from dangerous practices like curl | sudo bash.

1. Defense-in-Depth with Hypervisor Isolation: For extremely sensitive workloads, projects like Hyperlight Wasm provide an additional layer of isolation. While Wasm's sandbox is robust, potential bugs in the host runtime's implementation of WASI interfaces (e.g., how it handles an HTTP request or file system call) could still be exploited. Hyperlight Wasm places a hypervisor boundary around Wasm components, effectively treating them as micro-VMs. This offers an unparalleled level of isolation, akin to Firecracker for containers, ensuring that even if a vulnerability exists in the host's WASI implementation, the Wasm module remains isolated. This is crucial for environments like public cloud functions or multi-tenant systems requiring maximum security.

1. Secure Observability and Instrumentation: Wasm's integration with tools like Inspector Gadget (which uses eBPF) allows for highly secure and customizable observability. Security teams can write Wasm-based gadgets to collect specific data from the kernel, ensuring that the instrumentation logic itself is sandboxed and does not introduce new attack vectors, while still providing critical insights into system behavior.

In essence, WebAssembly provides a powerful toolkit for defenders, enabling them to build inherently more secure applications and platforms by offering superior isolation, granular capability control, transparent plugin architectures, and advanced defense-in-depth strategies.

Key Takeaways

• Wasm Redefines Cloud-Native Security and Performance: Wasm offers a provably secure sandbox, unparalleled portability, and significantly faster cold-start times compared to traditional containers, making it an ideal runtime for serverless, edge, and microservice architectures.
• The Component Model is Crucial for Interoperability: The WebAssembly Component Model, using wit files, standardizes Application Binary Interfaces (ABIs), enabling seamless polyglot composition and communication between components written in different languages (e.g., Rust and Go).
• Rapid Evolution Towards a Stable Standard: The Component Model and WASI are actively progressing through versions 0.2.0 and 0.3.0 (with native async), aiming for a stable 1.0.0 release to provide a solid foundation for production-ready applications.
• Wasm is Already in Production: Numerous projects and companies, including WASMCloud, Spin, Kubewarden, Hyperlight Wasm, NGINX Unit, WasmEdge, and various databases, are actively using Wasm in production today, demonstrating its practical utility and growing ecosystem.
• Superior Plugin Model with Enhanced Security: Wasm provides a self-describing and sandboxed plugin model that allows hosts to inspect, deny, or virtualize capabilities requested by plugins, significantly improving security over arbitrary binary extensions (e.g., for kubectl or Kubernetes webhooks).
• Community Contribution is Key, Especially for Go: The Wasm ecosystem, particularly the Component Model, requires continued community effort. Robust, pure Go support for components is a critical need to unlock Wasm's full potential within the Go-heavy CNCF landscape.

About the Speaker(s)

Taylor Thomas is an Engineering Director at Cosmonic, a startup focused on the WebAssembly space. He is a prominent figure in the Wasm community, serving as a co-chair for the CNCF WASM working group. His involvement with Wasm, especially in the context of Kubernetes, dates back to 2019, and he is a long-time contributor to various standard specifications within the ecosystem.

David Justice is an Engineering Lead at Microsoft and also a co-chair for the CNCF WASM working group. He is a maintainer of several CNCF-based WebAssembly projects, including RunWasi and SpinCube. David is the author of "Go for Dev Ops" and a dedicated contributor and champion for multiple WASI specifications, bringing a wealth of experience in Go development and cloud-native infrastructure to the Wasm community.