I recommend gvisor: <a href="https:&#x2F;&#x2F;gvisor.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;gvisor.dev&#x2F;</a>If you want to learn more about this subject the keyword you’re looking for is “multitenancy”Docker’s container runtime is not really a safe way to run untrusted code. I don’t recommend relying on it.Also, why would an isolated vm prevent fetch? You can give your users NAT addresses to let them make outbound network calls. I am putting the finishing touches on a remote IDE that does exactly that.

Keep docker. As long as you do not expose volumes back to the host system, it is reasonably safe (despite the misconceptions it comes with good security defaults).If you want to further lock this down, there are many tools such as apparmor and seccomp that you can add custom profiles with but a good starting point would be:docker run --security-opt no-new-privileges --cap-drop ALL untrusted-image

Depending on your criteria, a server like <a href="https:&#x2F;&#x2F;github.com&#x2F;supabase&#x2F;edge-runtime">https:&#x2F;&#x2F;github.com&#x2F;supabase&#x2F;edge-runtime</a> could be a fit.

What is your threat model &#x2F; what are you trying to stop from happening?

Nsjail, firecracker, gVisor, or v8 isolates are all good options with different tradeoffs

Anyone have advise or links for how to dynamically run untrusted code in production? Specifically NodeJS.It looks like the isolated-vm package is the go-to, but understandably it prevents things like fetch or being able to import packages.I’m thinking to use docker and have a single base image that exposes an API that will take an arbitrary string, check for and install imports, then eval (eesh) the code, but before going down the road of implementing it myself and going crazy over properly securing the containers I’m thinking that there has got to be some prior art. How are Codesandbox et al doing it?

I&#x27;m a bit disappointed. I thought the article would have some discussion on how to actually build untrusted container images in a safe way, but it is really just about how to connect to the Depot API and have it do it for you. I imagine there must be something inside there that answers that part (from some of their other articles, maybe that&#x27;s BuildKit? unsure).

Fundamentally building a container involves running a container - each layer is executed in turn as a temporary container.The same risks that running an unknown container has - are had by building one.For reference there have been quite a few CVEs related to container escape: <a href="https:&#x2F;&#x2F;www.paloaltonetworks.com&#x2F;blog&#x2F;cloud-security&#x2F;leaky-vessels-vulnerabilities-container-escape&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.paloaltonetworks.com&#x2F;blog&#x2F;cloud-security&#x2F;leaky-v...</a>

Inside the container though. The whole point of which is that it sandboxes and isolates the running code.

You&#x27;re running untrusted code. Every RUN command in a user&#x27;s Dockerfile is executed during build, which means you&#x27;re executing arbitrary commands from strangers on your own infrastructure. If you&#x27;re not isolating that properly, it&#x27;s a security risk.

Build environments are usually &quot;soft targets&quot; in most environments.Especially ones that utilize a lot of the &quot;CI&#x2F;CD&quot; pipeline approach.Lots of secrets getting pulled from various different places, access to testing environments and testing databases needed for unit testing, access to systems that deploy to testing and prod environments. Sensitive code and secrets from multiple applications being used in the same servers and build infrastructure, etc.So even if you trust containers to containerize securely (which is a bad idea in practice) there are all sorts of holes being poked in them to allow them integrate and access things. Even during building and testing.Most security effort for most organizations involve hardening parts of production systems that are exposed to users and&#x2F;or the internet. This not only involves proofing code and setting up firewalls, WAF, and such things, but also monitoring and whatnot.That is expensive and a lot of work to do, while in build environments it tends to be more slapped together and people ignore them until something breaks.You have similar situations with backup solutions. People need backups to secure data from corruption or deletion and protect businesses that way, but seeing them as a potential security hole isn&#x27;t really thought about in the same way as running a production web server. Again it is something that just enough effort is put into to make sure it works and little attention is given to it unless it breaks.

I&#x27;m confused--what&#x27;s the security risk in building a container?

Building untrusted container images safely at scale