Self-hosted runner security with public repositories

[annulen]

Documentation [1] says:

We recommend that you do not use self-hosted runners with public repositories.

Forks of your public repository can potentially run dangerous code on your self-hosted runner machine by creating a pull request that executes the code in a workflow.

Do I understand correctly that if self-hosted runner is only used in workflow which is triggered by push, it’s completely secure?

[1] https://help.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners#self-hosted-runner-security-with-public-repositories

[Yanjingzhu]

Yeah, you are right. If your workflows is not triggered by pull request event, then dangerous code on fork repos could not run on your self-hosted runner.

Only collaborators has permission to push to your public repositories directly. If you could make sure your collaborators are safe , then workflows triggered by push event is secure.  

[rtjohnso]

I've just tested this out, and I believe this answer is incomplete. As others have pointed out, someone can fork your repo and create a PR that adds a trigger on pull_request to a workflow. As long as you've approved a PR from them in the past, then, to my surprise, their modified workflow will run on the original repo!

But suggestion 1 from @karussell below (https://github.com/orgs/community/discussions/26722#discussioncomment-3751971) seems to solve the problem.

I haven't tested, but based on my reading of the documentation, his suggestion based on CODEOWNERS will not prevent workflows from running.

[simcrack]

I haven't tested, but based on my reading of the documentation, his suggestion based on CODEOWNERS will not prevent workflows from running.

So there is still no solution to this issue?

[annulen]

Thanks! Then I suggest to change wording in documentation to be less scaring, and maybe add validation in runner which prints big bold warning whenever self-hosted runner is triggered in PR event in public repo.

[dfalbel]

I’m not sure this is safe. What happens if someaone creates a PR modifying the workflow to run on pull_requests?

[vivekteega]

Once a repo has been forked you aren’t in control of changes on the fork right? So it seems fine to me as long as the malicious code is not run on the main repo

[Yanjingzhu]

@vivekteega Yeah, you are right. Please pay attention to pull requests from fork repo to your main repo. A workflow on pull_request event will get premerged code of forked repo to main repo and the codes in forked repo could be run in your self-hosted runner. 

[karussell]

The problem is that everyone, even outside users, can change the workflow to use "on pull_request" and create a pull request and then the pipeline will run.

To my knowledge there are two things that could prevent this:

1. Adjust "Fork pull request workflows from outside collaborators" (under "Actions") to a stricter value
2. If you want to limit this to only one or a few members then you need CODEOWNERS file. Or will the pipeline still run and this setting just requests a pull request review!?

[karussell]

And what if a malicious user sends a pull request with run-on: self-hosted?

[kousu]

Thank you for this info. I was very spooked as well by the big warning in the docs. I’m considering deploying a self-hosted running and just making a big comment in the workflow to say “DO NOT TRIGGER ON PRs”.

But it seems pretty fragile to me to “just” not run on PRs. That is a very easy thing to change without someone realizing that they’ve just opened themselves up a cybersecurity hole.

The rule I would expect from Github is: a self-hosted runner can only be triggered by code in repos where the self-hosted runner is active. So, basically, a hard-ban on PR/issue/etc triggers.

---

For a data point of comparison, Azure Pipelines makes you manually click a Permit button the first time a pipeline accesses a new runner. So it …should be? … impossible for it to have the same problem?

[karussell]

The rule I would expect from Github is: a self-hosted runner can only be triggered by code in repos where the self-hosted runner is active. So, basically, a hard-ban on PR/issue/etc triggers.

👍

[philmcmahon]

We’re investigating using self hosted runners at my work, but we’ve got hundreds of public repos so this issue is quite a blocker for us - something like @kousu suggests where you can prevent forked repos using self hosted runners at an organisation level would be very helpful.

[VanDavv]

What with a situation, where we have a public repository and would like to run the tests with some physical device, e.x. webcamera?
My original thought was to create a self-hosted runner and attach the device physically to it, but as the docs specified, it’s dangerous to use self-hosted instances on public repositories.
Are there any alternatives?

[Yanjingzhu]

I am sorry to tell you that there is no alternatives. To test with physical device , you need to use self-hosted runner.
If it is possible for you, I would suggest you to use a private repo.

[bdevierno1]

I think a good feature is if in the future we could trigger a workflow when an authorised user comments on an open PR. At the current moment it is hard to see how to deploy a self hosted runner in my development as ideally I would like to run CI before I push any new code to any of my branches.

[drpaneas]

Yeah I like the suggestion from @bdevierno1 . I would be great if the action can be triggered only by comment (e.g. /test) that is coming from one of the people that are part of the OWNERS file. Would that be possible?

or

what about blocking merging unless 1 approval from an owner is required? If that’s the case I would be great to have an action that can be triggered based on the “approved” status of a PR.

[annulen]

I think it would also be useful to have different event types for “internal” and “external” pull requests, where “internal” means pull request originates from the same repo with workflow. If workflow is triggered by internal PRs only it would require having write access to repo to run code on self-hosted runner.

[hellt]

But isn’t it more dangerous that was discussed before in this thread?

According to this thread How to prevent GitHub Actions workflow being triggered by a forked repository events? - Stack Overflow if you have a self-hosted runner, than anyone can create a workflow that targets self-hosted runner and create a PR.

This will trigger the workflow to be executed on a self-hosted runner even if you haven’t accepted the PR?

[akikanellis]

You are correct, I tested this myself.

The conditions for a potential security breach are like so:

• The repo is public
• Any self-hosted runner is accessible in the repo (either via repo or organisation settings)
• The repo has defined at least one workflow file with pull_request trigger
• The repo maintainer has not checked Require approval for all outside collaborators

Then a malicious actor can simply open a PR from a forked repo where they add a new workflow file like so:

name: Malicious Workflow
on:

pull_request:

branches: [ main ]
jobs:

malicious-job:

runs-on: self-hosted
steps:
  - name: Run a malicious script
    run: |
      echo Malicious script running from **forked** repo

The script will run on the available self-hosted runner of the maintainer’s repo.

The best (and most cumbersome) way to prevent this is to check Require approval for all outside collaborators in the repo settings as explained here. Then you have to manually approve workflows running on each PR, after you have first checked the PR for any changes to workflow files.

Another way to mitigate the risk would be to have a private “companion” repo to your public repo that the self-hosted runner is assigned to as explained here but I haven’t tried this myself.

[sjmiller609]

I don't understand what is not safe about running on self hosted when it's not a fork, but a commit to a branch or PR from a branch on the same repository. And I thought there were already such conditionals in the case of github actions secrets.

In order to protect public repositories for malicious users we run all pull request workflows raised from repository forks with a read-only token and no access to secrets.

https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/

[alshdavid]

I'm using a standard GitHub provided runner for PRs where it runs tests and validates that a Linux build passes.

For releases I build binaries in my pipelines and publish them to a github release. Right now I am using on: workflow_dispatch but I may soon move to on: push: branches: ['main'].

1. Can I use a self hosted runner safely on a public repo with a workflow_dispatch setting?
2. Can I use a self hosted runner safely on a public repo with a [workflow_dispatch](on: push: branches: ['main']) setting?