Restrict runners to valid freedesktop projects only
Superseeded by #540
Cc: @daniels @danvet @lyudess @emersion
This is a confidential draft, so we can discuss about it without detailing too much on the technical solutions.
Over the first week of June 2022, we have seen several attempts at mining cryptocurrencies on our runners.
And on March 12 2023, the same hackers came back and went one step further compromising our entire fleet of runners. So we have to take actions.
While we are an open community and try to provide a great free infrastructure for open source development, those attempts are clearly a breach in the trust we give to our users.
This is why we are sad to announce that we have to take actions to restrict how the runners are freely available to anybody.
This restrictions are coming on top of the automated detection and prevention of this kind of use, of course.
What it means for me, a regular user and contributor to gitlab.freedesktop.org?
Starting 2023-03-14, or before if we see a spike in the attacks, only pipelines running in a known, official project will be run on the shared runners we manage at freedesktop.org. Jobs for projects in personal namespaces will not be able to leverage shared runners.
Will there be exceptions?
Yes. The current implementation makes it possible to have exception, but the counterpart is that the list of users requesting for exceptions will be public.
You can apply by submitting a merge request against https://gitlab.freedesktop.org/freedesktop/helm-gitlab-infra/-/blob/main/runner-gating/users.txt.
I do not want to have my username in the exception list, will I be able to continue to contribute to freedesktop.org?
Yes. Projects leveraging the Merge Request Pipelines have their pipelines run in the namespace of the project, for Merge Request.
It just means that to have the CI started, you need to create a MR to the project. Using the Draft feature is recommended then, but CI should be running properly.
But I just want to run [replace-me-with-some-random-project] in my own namespace...
Sorry. This is the only way forward we can see.
If the project you want to use our sponsored runners is freedesktop related, why not contribute?
If the project is not, well, we can not actually let you run your tasks on our shared runners. Just disable the shared runners in your project settings and bring in your owns!
What it means for me, a maintainer of a project part of gitlab.freedesktop.org?
Hopefully nothing. Contributors should still be able to run CI on the MRs, and you can still have your project being tested as previously.
The only thing you have to be aware of, is that you need to have detached MR pipelines. For that, just append the following snippet to your .gitlab-ci.yaml:
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == 'merge_request_event'
- if: $CI_PIPELINE_SOURCE == 'push'Yes, this will create duplicated pipelines, one for regular push, and one for MR. This is expected and you can talk to us on #freedesktop over IRC if you want to enhance the situation.
What it means for me, a maintainer of a shared runner of gitlab.freedesktop.org?
Every shared runner will have to use the following pre-clone script in the [[runners]] section:
[[runners]]
name = "xxx"
url = "https://gitlab.freedesktop.org"
executor = "docker"
...
pre_clone_script = "wget -q --output-document - https://gitlab.freedesktop.org/freedesktop/helm-gitlab-infra/-/raw/main/runner-gating/runner-gating.sh | bash"
[runners.docker]
...note: the URL of the project will likely change, be sure to amend the above when it's decided
This script will prevent the use of the runner outside of its legitimate usage, and will also allow us, sysadmins to change the rules on the fly without have to ask everybody to re-apply changes.