5

I'm building a server that will build images directly from Dockerfile:

docker build -t arbitrarydocker .

This docker file will be built on the same server as other client Dockerfiles, which may have secrets. How can I lock down the process that does docker build -t arbitrarydocker . so that it doesn't do things like:

ADD /contents/of/host/secrets ./space/in/hacker/docker/container

The best way I can think is to fork the process and run it with a made up user that has limited directory access to only one folder where its own secrets are kept with limited capabilities. Also wondering if there's a way to totally wipe out memory after dockerfile is built so data is not leaked to next client build.

If the only way to do it securely is to have a dedicated build server per client, then I can do that, but I'd like to avoid it.

All builds are done on Centos.

Murmel
  • 214
  • 2
  • 5
Dr.Knowitall
  • 151
  • 4
  • Maybe using seccomp better than selinux, but not sure how to do that now – OscarAkaElvis Jan 10 '18 at 11:07
  • I think the way I'm doing it is that I make my own yaml config dsl... and get rid of Dockerfiles. Its the only way to control what goes into a docker file. Any provisioning would be done in the container itself which would not have access to the docker machine/ client which in theory prevent system compromise. – Dr.Knowitall Jan 10 '18 at 18:48
  • @OscarAkaElvis you can't really do filesystem isolation with only seccomp (although it may be possible with the upcoming eBPF enhancements. SELinux, AppArmor, or mount namespaces would be a better fit (preferably in addition to seccomp). – Tim Allclair May 23 '18 at 01:14
  • On my machine atleast, docker does not allow files from outside the build context: `ADD failed: Forbidden path outside the build context: ../../../../../../../../../../../../../etc/passwd ()` – Daniel Dec 19 '18 at 10:45

2 Answers2

1

I'm going to state the obvious here and just say, "don't include /contents/of/host/secrets in your builder VM." Presumably, though, you've got something going on that makes the obvious answer less obviously correct.

So let's circle back to the other obvious bit, and point out that "arbitrary Docker build" is literally "arbitrary code execution", since the Docker build process is imperative (not declarative), and having your dockerfile do things like downloading and executing arbitrary code off the internet is Totally A Thing™ in the Docker build world.

In other words, the whole Docker build process is potentially malicious, so you should be thinking about it in terms of sandboxing attacker-provided code. You need a strong security boundary between the builder's (attacker's) runtime environment, and virtually everything else. You've heard that docker containers aren't a security boundary, but attacker-controlled docker containers don't even pretend to be a security boundary. The builder needs to run in its own VM, and all the access between it and your own systems needs to be mediated by well-defined communication channels; no back-door access.

With that in mind, lets think back again to /contents/of/host/secrets. The docker build runs on the builder VM. The VM is isolated because you don't trust it, and it has no access to secrets which you haven't intentionally shared with the attacker. There's your sensible solution.

For cleanup: Just delete the VM. Restart it again from your "pristine" HD image.

Since the wheel you're inventing has been invented many times before, I'd recommend looking over the existing solutions for ideas about how they solved the problems that you come up against.

tylerl
  • 82,225
  • 25
  • 148
  • 226
0

You could build the images from within an unprivileged container, which will also add some protection against other threats to the host (e.g. arbitrary command execution). Kaniko is an example of a tool for doing exactly that.

Tim Allclair
  • 111
  • 3