Building Docker images provided by untrusted users in a SaaS

Question

I am building a multi-tenant SaaS similar to a Continuous Delivery service and I need to build a Docker image, based on the source code and Dockerfile provided by a user of the service (the user is not part of the organization and can't be trusted in any way).

For example:

1. a user of the service connects his own Git repository
2. our SaaS downloads the source code (Ruby, JavaScript, etc.) to the server and generates the Docker image as an output
3. the docker image is deployed

However I have serious security concerns about step (2)... Is there any secure way, on a server, to execute docker build on untrusted Dockerfile/code?

Is there any configuration option that can make Docker safe?

Is there any tool different from docker build that allows to build an OCI image safely in a shared environment (ie a server of a multi-tenant SaaS)?

Is there any SaaS that already allows you to build third-party code on behalf of your SaaS?

Otherwise I should start and delete a VM (eg DO droplet, EC2, etc.) every time that I need to build a Docker image... but that seems more complex.

Do you have any recommendations? Do you know what strategy is used by CircleCI or Travis to build / run untrusted code?

Answer 1

This is a problem with any kind of build, not just Docker images, but it applies to that too, obviously. A build script (Dockerfile or else) can do pretty much whatever, I don't think there is a way to make it secure if untrusted.

So what these services do is exactly what you also described, they run it in a segregated, one-off environment. These are sometimes called runners. I think your only secure option is to run this on a dedicated, clean (as in "just started") VM, and then tear it down. Even then, be very careful with how you configure that VM, what network connections you allow (to your internal network for example) and so on, because as said above, the build script will potentially have full control of the VM. (Full control might be an overstatement though as you need not run it as root, but then consider the risk of a malicious user breaking out of a segregated sub-environment like a chroot and so on - it's probably best to model it like full control).

It's not straightforward to get this right.