Bruno Haible <br...@clisp.org> writes: > Simon Josefsson wrote: >> I've found it to only be cost >> effective to setup my own runners for platforms that gitlab doesn't >> support natively, such as arm64 or ppc64el. > > For GitHub runners, hosting your own runners comes with security risks [1]. > > Do GitLab runners have the same security risks? (I.e. If, on GitLab, I fork > one of your projects, add code, then trigger the CI, does my code then run > on your machine?)
I think you have to push your code as a merge request back into the original project to trigger the CI to run on hosted runners on gitlab. Runners are project-specific, so if you fork project gitlab.com/gnu/whatever into gitlab.com/user/whatever the runner associated with the gnu-project till not run for gitlab.com/user pushes. However it will run if you push the commit back into a merge request that ends up on gitlab.com/gnu/whatever. What is actually executed depends on .gitlab-ci.yml content, but that is modifyable by the user too so any user can in theory run code on any runner associated with any public project that enables merge requests. I think the gitlab recommended way to deal with this is to have protected branches, and to setup protected workflows. Then you can provide additional access for protected workflows only. Merge requests will not trigger a workflow on a protected branch. You can probably setup a runner to only run commits on protected branches, which somewhat mitigate this problem. However I think the details are unimportant: when you set up a gitlab/github runner you are fundamentally authorizing gitlab.com/github.com to run code that you cannot audit on that machine. Thus the only reasonable way to approach this is to assume that you will run malicious code. If the code comes from a user on gitlab/github or someone who gained access to gitlab/github internal systems doesn't really matter. My conclusion is that the only responsible way to host a runner is to do it on throw-away machines and be prepared to re-install on a new machine, and to produce an audit trail for everything going through runners. For me, the advantages of using gitlab/github runners (e.g., the entire CI/CD test harness) outweigh the risks here, but there are several unresolved risks to consider. /Simon
signature.asc
Description: PGP signature
