7 ms·
Mmm so application-level sandboxing. Lovely. And I’m assuming your worker runtime is a process in a container on a shared node? What happens if the agent explo
by nullpoint420 1mo ago
Mmm so application-level sandboxing. Lovely.
And I’m assuming your worker runtime is a process in a container on a shared node? What happens if the agent exploits your runtime?
Does it get access to the whole container? VM? Node?
Why should I ever choose this over MicroVMs? I have to design my architecture around your JS runtime. This isn’t an OS.
- teacpde 1mo agoWorkers are in the same process but have separate heap, global vars, gc etc, the isolation is managed and achieved by V8. It is much lightweight compared to micro VM or containers. But the downside is you have to use JS because of V8.
- nullpoint420 1mo agoI get that but it’s much less secure. ie. If an agent finds a bug in V8 it’s over
- nolist_policy 1mo agoLet me quote the workers GitHub: > WARNING: workerd is not a hardened sandbox > workerd tries to isolate each Worker so that it can only access the resources it is configured to access. However, workerd on its own does not contain suitable defense-in-depth against the possibility of implementation bugs. When using workerd to run possibly-malicious code, you must run it inside an appropriate secure sandbox, such as a virtual machine. The Cloudflare Workers hosting service in particular uses many additional layers of defense-in-depth. Sandstorm was great because it did proper sandboxing. This is pretty weak by comparison.