Why WebAssembly won’t replace Kubernetes but makes Helm more secure
My gut reaction has often been to compare WebAssembly to Kubernetes. Flash back to over four years ago: Then, I put this concept to the test by comparing WebAssembly to Kubernetes in an article.
Not long after the article’s publication, I attended a workshop generously hosted by Cosmonic to use the WebAssembly cloud and learn how to deploy applications with WasmCloud. I got my first hands-on experience with WebAssembly.
As Cosmonic CTO Bailey Hayes helped me play around with WasmCloud during the workshop, I really thought, “Wow, I can deploy things without having to change the underlying infrastructure, essentially anywhere I want, with just a CPU instruction set through a single endpoint.” I did that by setting up microservices with WebAssembly, in that case with WasmCloud, all simultaneously with just one command line. Boom — it was there everywhere. I thought, “Well, maybe that could be something. Isn’t that what Kubernetes is supposed to do? Plus, it’s simple.”
As I learned more about WebAssembly, I realized that wasn’t really the case — they are two different things. Still, I had that inkling in the back of my head. Then came Helm, supporting WebAssembly modules directly. I thought, “Oh, here we go again. We can run WebAssembly modules with Helm; maybe we won’t need Kubernetes.” Wrong again.
This has been part of my learning journey, but it helped me realize that now, with Helm 4 supporting direct WebAssembly modules thanks to the Extism WebAssembly plugin, the isolation previously missing in Helm 3 is provided. You can implement many policy considerations, multi-language elements, and other features in these modules and deploy them on Kubernetes.
So no, WebAssembly is not going to replace Kubernetes, and that is missing the point of the concept: WebAssembly is almost always an extender of existing systems. In this case, you use WebAssembly through Helm to deploy, manage, and distribute workloads to a theoretically infinite number of endpoints that can run a CPU instruction on Kubernetes.
That was the topic of the talk “Helm Meets WebAssembly: Secure Extensibility Without Replacing Kubernetes,” which I gave this week in Barcelona at the Wasm I/O conference as the co-presenter with Shivay Lamba. Lamba had to cancel his trip due to geopolitical issues that disrupted his flight from India, but delivered his part of the talk via video.
As Lamba said during his talk, the Existim plugin provides a lightweight framework for building WebAssembly-based systems. To lock these rules in place, instead of simply running the code, Helm 4 uses a built-in tool — with the help of Extism — to instantly build an invisible, isolated sandbox inside of its own system. Helm then drops the plugin’s code into this safe box. In this environment, the plugin is completely blind and disconnected from the actual computer, Lamba said.
“Helm takes the command you have typed, packages the data up safely, and slides it into the sandbox to be executed so the plugin can start working. Since the plugin is isolated, it cannot directly touch your computer’s hard drive or the internet,” Lamba said. “If the plugin needs to download a file to do its job, it must formally ask the host function standing outside of the sandbox. If the security rules specify that the plugin is allowed to download a file from github.com, then the host guard will go out.”
However, if the plugin tries to access something that it does not have permission to reach, the guard will immediately block it, Lamba said. “Once the plugin finishes its work, it packages up the final result and sends it back to Helm. As soon as Helm gets the result, it immediately destroys the sandbox — which is the WebAssembly module — and wipes out any temporary files that the plugin was using,” Lamba said. “In this way, with the help of Extism, Helm ensures that plugins only get what they need to do their jobs and absolutely nothing more.”
Little protection, big protection
My demo partially failed. I did manage to show with Helm 3, the WebAssembly plugin (Extism in this case) is not “sandboxed.” A simple script with my full permissions that lists my home directory and other info is listed. Obviously, you do not want that.
It’s an unbounded security risk:
The “executable not found” error is exactly why the Extism provided protection is so important. Helm 4 refuses to run the plugin because it can’t find the secure sandbox runner.
It would rather fail than run the code insecurely:
Once I restored the secure path, the “guard” went back up and protected the system:
There you have it. Our talk shows how and why the Extism Wasm plugin improves supply chain and runtime security through mandatory signing and verification, clearer provenance, while still keeping Helm “batteries included” for default behavior.
Again, no, it is not going to help WebAssembly replace Kubernetes, but it will help make Kubernetes through Helm more secure and computationally efficient.
