1

I'd like to use a GitLab Runner in a docker container as explained in the doc mostly to easily deploy it to another machine. I'm wondering how to use it to safely run the CI/CD jobs that GitLab sends to the runner.

GitLab Runner documentation warns that using shell as an executor is unsafe, because all code runs with the GitLab runner user permissions and can thus access everything that user has access to on the host machine.

Is it safe, however, to use a shell executor with a GitLab Runner running in a docker container? My intuition is that all security concerns fall back to the docker container: if it's not running with --privileged mode and the system resources are not exposed via a binding to the container, the job can't be any threat to the host. Multiple jobs run by the GitLab Runner can still access one-another's data, but the host system is out of reach. Are there other concerns I should be aware of?

Alternatively, is there a safe way to run GitLab runner in a docker container and have the ci/cd jobs to build, test and deploy also run in their own docker container? The Docker-in-Docker approach seems to do it but requires the GitLab Runner container to run with the --priviledged mode, which I'd rather avoid, mostly out of ignorance of the security issues that may come with it.

Guillaume Chérel
  • 1,478
  • 8
  • 17

1 Answers1

2

To my understanding, untrusted code that is run via the shell executor can read GitLab Runner environment variables, which contain a token allowing the access of potentially protected repositories on the GitLab instance. Also, untrusted code could overtake the GitLab Runner itself.

Further, relying on the usual e.g. runc-based Docker containers for isolation is brave, this is why e.g. gVisor (https://github.com/google/gvisor) and Kata Containers (https://katacontainers.io/) exist.

If you want to run a GitLab Runner in Docker and run jobs in their own containers without --privileged, you probably have to find a custom solution.

Having said that: A common alternative would probably be to run the GitLab Runner with the Docker executor in a VM and not in a Docker container itself. Docker-in-VM works way more securely than the privileged Docker-in-Docker approach.

Speaking of using non-Docker technologies for the outer container: If using a container outside the Runner is really desired, the following solution adds some security by letting the outer container run without root privileges: It would be to wait for the Podman executor GitLab is working on (https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27119) or create a custom executor with Podman, and then one can run the Podman executor inside Podman - rootless Podman-in-Podman is e.g. demonstrated in the last code line of https://www.redhat.com/sysadmin/podman-inside-container . The outer Podman should only run trusted code (i.e. the Runner configured with Podman executor itself) though, since the outer container to my understanding does not provide useful isolation.

Maybe gVisor- or Kata-based Podman or Docker can be nested though without that many security compromises? I wouldn't want to bet on that though.

2xB
  • 296
  • 1
  • 11