We are curious about this set of solutions for allowing clients to run their own code on our system.
For example, a client wants to write a workflow but has a custom step that integrates with their system only. They can write the code and run as part of our workflow without us worrying about them writing something nefarious and breaking out of the sandbox.
That said, the workerd github says that this can't (yet?) be relied on to be a security sandbox.
workerd ensures that a Worker cannot access protected resources by accident or negligent programming. What it can't protect against (on its own) is intentional exploitation of security bugs.
If your clients are people whom you've spoken to face-to-face and signed contracts with, then you can probably trust that they won't exploit a V8 zero-day to break the workerd sandbox, because if they did, it would clearly be a crime and you could prosecute them.
If your clients are random people who can sign up on the internet without talking to anybody, then they may be able to evade such identification and therefore prosecution. In that case you need a stronger sandbox to contain them.
It’s people we talk to and have contracts with but the devs they might have working on it, lesser known quantity.
But still isn’t the Wild West.
It would likely be more of a “this person wrote crappy code that’s bringing down everyone else’s worker” or “this client wants to know if we have proper guards on their data”
I guess it's not a problem I've encountered so far. Perhaps I just haven't worked in a company big enough? Only on the scale of hundreds so far.
Branching, agreeing on interfaces and tests have been sufficient to allow linking, in my experience.