consider setting up a shared runner to make CI building easier for users
Anyone can run a specific runner, which is nice because it doesn't require us to do anything. However, specific runners are limited because if you are not a 'master' level member of a project, you don't get access to the specific runners that are configured for a project. That means that any random person who comes along and wants to do MRs and is not already trusted to be part of the group with those permissions, wont have their MR code built/tested by the CI automatically.
Running a shared runner has some security risks associated with it. So I wanted to consider what is involved and what we can do to mitigate these risks. If we can do that, then it might be worth setting up.
A shared runner should use Tags, according to the documentation:
You must setup a runner to be able to run all the different types of jobs that it may encounter on the projects it's shared over. This would be problematic for large amounts of projects, if it wasn't for tags. By tagging a Runner for the types of jobs it can handle, you can make sure shared runners will only run the jobs they are equipped to run. For instance, at GitLab we have runners tagged with "rails" if they contain the appropriate dependencies to run Rails test suites. Prevent runner with tags from picking jobs without tags You can configure a runner to prevent it from picking jobs with tags when the runner does not have tags assigned. This setting is available on each runner in Project Settings > Runners.
I'm unsure how much this matters if we can make a docker runner that allows people to install whatever packages are necessary for their build, and then destroys it afterwards...
The documentation also says that "If you can run a build on a runner, you can get access to any code it runs and get the token of the runner. With shared runners, this means that anyone that runs jobs on the runner, can access anyone else's code that runs on the runner. In addition, because you can get access to the runner token, it is possible to create a clone of a runner and submit false builds, for example."
I am unsure if this applies for docker runners that get destroyed after the build. Need to determine this.
If we are to do this, a VM would be created only for this purpose, it would not have any other service run on it because it would be considered untrusted.
The options for running shared runners are to run it with docker, shell, or parallels. Since the shell mechanism is insecure, and parallels is proprietary, the only option is docker.
The runner documentation on security considerations says this about docker runners:
Docker can be considered safe when run in non-privileged mode. To make such setup more secure it's advised to run jobs as user (non-root) in Docker containers with disabled sudo or dropped SETUID and SETGID capabilities. On the other hand there's privileged mode which enables full access to host system, permission to mount and umount volumes and run nested containers. It's not advised to run containers in privileged mode. More granular permissions can be configured in non-privileged mode via the cap_add/cap_drop settings.
A docker setup would allow us to have a clean build each time, and allow builds to have some build environment control.