Page MenuHomePhabricator

Deploy an "sbuild" tier outside of the cluster
Closed, ResolvedPublic

Description

For building Phabricator itself for Harbormaster v2 / Drydock v1, we need an isolated build tier ("secure build") outside of the cluster with no privileges. This is "build, for secure", not "build, that is secure". We might have a cluster "build" tier eventually for normal instances.

Although builds will be isolated from services, they won't be isolated from one another. That is, anyone who can run a build can interfere with anything else happening on the same machine. Two attacks I can come up with are:

  1. Add a bitcoin miner to phabricator/, add a "unit test" that runs the miner indefinitely, arc diff it, mine bitcoins huehuehwahue~~~11
  2. Add a script which looks at other builds for secret stuff and emails it to you (or whatever).

To prevent (1), I think we can do autobuilds only for Community members. This could get more subtle eventually.

To prevent (2), we can't build important things on this tier, but none of the important things (like rKEYSTORE) have unit tests anyway so this is sort of moot.

Event Timeline

epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley added projects: Almanac, Drydock, Phacility, Ops.
epriestley added a subscriber: epriestley.

Although builds will be isolated from services, they won't be isolated from one another. That is, anyone who can run a build can interfere with anything else happening on the same machine.

Won't it be envisageable for build to have the possibility to run them in an lxe/docker/openvz container, like quite all CI does today.
As stated in T6454: Implement support for KVM-based hosts in Drydock you plan to do it like in v5, but this would solve 2nd problem, isn't it .

Some day you'll be able to spin up a container or host per build and tear it down afterward, but doing so creates a performance/efficiency tradeoff because you have to build and tear down more state per build. I suspect this tradeoff is undesirable for this project even if the code existed to make it (because host startup / teardown would likely overwhelm build cost).

epriestley claimed this task.

This tier now exists and rCORE knows how to deploy hosts inside it.

Some day you'll be able to spin up a container or host per build and tear it down afterward, but doing so creates a performance/efficiency tradeoff because you have to build and tear down more state per build. I suspect this tradeoff is undesirable for this project even if the code existed to make it (because host startup / teardown would likely overwhelm build cost).

I have to agree with you. However, docker and AUFS for instance minimize subsequent container spin by far (reusing an union fs for inchanged step => which are by far the longest).

fyi libvirt takes just a little over a minute to spin up a Linux build machine using copy-on-write disks (this includes waiting for SSH to come up and connect)