A CI job can execute in a container on a shared host, in a virtual machine created for it, or directly on a shared bare-metal machine. What does each boundary actually contain, and what leaks across it?

## Why the boundary matters in CI specifically A CI job runs code that people change every day, including code from contributors you have never met. The question "what can this job touch" therefore has two separate audiences: security (can this job reach another team's secrets, or the host) and reproducibility (can this job see leftovers from the last one). The isolation boundary answers both. ## Bare process on a shared machine The weakest arrangement is the agent running jobs directly on a host, as its own operating-system user, in a working directory it reuses. Nothing here is a boundary in the security sense. Every job runs as the same user, so every job can read every file that user can read: the previous job's checkout, its `~/.docker/config.json`, its `~/.npmrc`, its git credential store, its ssh-agent socket. Jobs can see and signal each other's processes, bind the same ports, and modify globally installed tools. If you run two teams' pipelines on one such machine, you have not separated those teams at all. Giving each job its own OS user helps a little — file permissions then apply — but it does not contain a job that can install packages, does not stop port collisions, and does not clean anything up. ## Container on a shared host A container is a normal process on the host kernel with a set of restrictions applied. Linux namespaces give it a private view of a subsystem — mount namespace for the filesystem, PID namespace for the process table, network namespace for interfaces and ports, and optionally a user namespace to map root inside the container to an unprivileged UID outside. Control groups (cgroups) cap CPU, memory and I/O. Seccomp filters restrict which system calls it may make. For CI this is usually the right default: each job gets a clean filesystem from an image, cannot see other jobs' processes, cannot bind a port another job is using, and cannot exhaust the whole host's memory. Reproducibility improves too, because the toolchain comes from the image rather than from whatever is installed on the host. What it does not contain: the kernel is shared, so a kernel vulnerability reachable from inside a container is a host compromise. More importantly in practice, most CI container escapes are not exploits at all — they are configuration: ```bash # Both of these hand the job the host, not a sandbox: docker run -v /var/run/docker.sock:/var/run/docker.sock build-image docker run --privileged build-image ``` Mounting the host's container socket lets the job ask the daemon to start a new container with the host root filesystem mounted — that is root on the host, obtained through an API call rather than an exploit. `--privileged` drops the capability and device restrictions that made the container a boundary in the first place. Both appear constantly in CI because image builds and Docker-in-Docker seem to need them; the answer is a rootless or daemonless image builder, not a privileged container. ## Virtual machine per job A VM runs its own kernel on virtual hardware provided by a hypervisor. The interface between guest and host is much narrower than the system-call surface a container shares, which is why every large multi-tenant CI provider isolates customers at the VM level rather than the container level. The historical objection was cost: a full VM took tens of seconds to boot. MicroVM technology such as Firecracker, and sandboxed container runtimes such as gVisor (which intercepts system calls in userspace) and Kata Containers (which runs each container inside a lightweight VM), have narrowed that gap enough that per-job VM-grade isolation is practical. The tradeoff is startup latency and resource overhead per job — you pay boot time and a duplicated kernel and page cache for every job, which matters when jobs are short and numerous. ## Choosing The decision follows the trust model, not the technology preference. Jobs from a single trusted team, on a machine only that team uses, are adequately served by containers. Jobs from multiple teams with different secrets, or from outside contributors, want a VM-grade boundary and a fresh instance per job. And whichever you choose, audit what you hand the job: privileged mode, the host container socket, host path mounts, and host networking each individually erase the boundary you thought you had.