allow self-hosted runner to be restricted to container builds only

Describe the enhancement Right now the security recommendation for self-hosted runners is not to host them on machines where there is any sensitive data. Because third party code can be injected via pull-requests.

It would be nice if self-hosted runner could be configured in a way to accept only jobs which have container: attribute, i.e. only jobs running inside of a docker container. This would allow to host such runners on machines without being afraid for sensitive data. I.e. if third party pull request modifies the workflow by removing the container: attribute then the job will be failed by the self-hosted runner.

[j3parker]

Disclaimer: I’m not a GitHub employee.

This sounds good but unfortunately wouldn’t work, at least without very big redesigns. Docker containers, at least they way GitHub Actions uses them, don’t provide that level of isolation. Here’s a dumb example:

on: push
jobs:
  job:
    runs-on: ubuntu-latest
    container: alpine
    steps:
      - run: poweroff -f || true # will fail
      - run: apk add docker
      - run: docker run --privileged alpine sh -c 'poweroff -f'
      - run: echo hello # won't run

The job runs inside a container. The first poweroff -f will fail with this error:

poweroff: Operation not permitted

but to make uses: work (which often launches containers) GitHub Actions mounts /var/run/docker.sock into the jobs container. This socket lets your docker client communicate with the outside host e.g. to launch containers. So any containers used in uses: run adjacent to your job container, not inside it. Maybe this sounds weird, but Docker unfortunately wasn’t built for nesting (even if some of the technologies like cgroups and namespaces are).

A big consequence of being able to run containers on the host like this is that you’re effectively unsandboxed. Here we run a container with --privlieged and can actually power off the machine (the echo hello will never run.)

But you can do whatever, really. You could mount the root volume and read any file from the host, etc.

So how do you get sandboxing with GitHub Actions? The usual boring way: run one job per VM (tear down the VM after the job is done – #510 is needed to make this good as far as I know) and don’t make the VM’s more privileged than you need (e.g. if you’re running in AWS, pay mind to what VPC they’re running in and what their instance role is.)

TL;DR: job containers aren’t a security feature.

[jeromewaibel]

@j3parker I tried to use rootless docker to avoid your poweroff scenario from above, but, alas, this won’t work either because of https://github.com/actions/runner/issues/827