Add functionality for allow self-hosted runner to protect workflow file and allow only execution only for collaborators for PRS

[MalloZup]

Description:

Hi all, first of all I really like the github action runner and self-hosted runner.

It has however an issue with working for pull-request workflows.

I think the runner should have a way to be configurable to run only on Pull-requests from collaborator of X org or Repo. The problem to be solved is to protect the github-workflow file and don't be changed by any arbitrary PR ( so there is no output redirection or other code executed) it is a recurring topic in some forums, but there is no solution or any issue about this afaik. let me know, and ping me for any info .

best

[TingluoHuang]

@MalloZup sounds like some policy feature we can add on the service side even before sending the job to the runner.

@chrispat for feedback.

[MalloZup]

@TingluoHuang that could be awesome thx!

[plfiorini]

This would likely solve the security concerns of self-hosted runners

[MalloZup]

yes this is the goal :sun_with_face:

[chrispat]

@MalloZup I don't believe this makes sense as a runner feature but rather something that is enforced on the GitHub.com side. There are scenarios where customers want this type of feature for hosted runners and not just self-hosted.

[MalloZup]

@chrispat yes I agree with you partially. I believe globally it make sense to have it on GIthub.com side. However I think that also the runner can still have it own way to setup this.

Is like when developing a CLI command line. Let assume the Github.com is our configuration file, from which the user setup option for our CLI. ( the CLI is the runner)

If an user use the CLI command line arguments, this overwrite the configuration file input (github.com).

In any ways, even if it you will implement globally you will need to instruct and implement the mechanism on the runner, afaik and correct me if I'm wrong.

Do you have a link where there is the Github.com UI source code where I can open such issue for the global part?

I think we could continue with this issue implementation on the runner side, since lot of user are depending on this to have a pragmatic/secure CI.

Personally the UI github.com implementation, from my perspective is the last part and imho it will take much more to implementation time then implementing such feature on the runner ( which is just a partial feature). Having such feature on the runner side, is just a step imho that it will need to be done also if the options are passed from github.

Thanks for your answer and time ping me for any info or I can help. :sunflower:

[chrispat]

@MalloZup Given the architecture of Actions the runner is not the best place to implement this feature. The runner is a relatively small part of the overall Action system and is designed to be a remote execution daemon for the Actions workflow.

In the case of GitHub hosted runners, self-hosted runners or runners that spin up on demand you waste a lot of time and money by spinning up a runner on a VM or in a container to make a simply policy check that should be done by the GitHub Actions workflow engine.

[MalloZup]

@chrispat do you know where I could open this issue for the github workflow engine?

Thank you in advance

[iagomelanias]

That feature would be extremely valuable to our team. 👍

We use Github Actions Runner labels to decide which infrastructure will be responsible for processing the job, some servers have more permissions than others. Here are some examples:

• There are runners which are responsible for provisioning resources using Terraform. It's possible to do literally anything inside of them.
• Some runners are responsible for deploying code to our stage environment.
• Some runners are responsible for deploying code to our prod environment.
• Other runners are responsible for only running tests using some cloud resources (storage, messaging, etc).

If a developer can change the labels and the jobs that are executed, all these security policies are thrown away. It would be possible to simply change the label of a test workflow to use a terraform runner and do anything there - delete a database, get access to any server or obtain any kind of sensitive data, like database passwords or private API keys. 💀

[MalloZup]

@chrispat or @TingluoHuang I could not find a place where I can move the issue in more appropriate place. If you have any feedback regarding this , it would be extremely welcome. thx!

[chrispat]

We don’t have a great place to track enhancements to the orchestration side of things as that is not open source.

We hope to have a public roadmap soon but the granularity of that may or may not account for these types of features.

[Penagwin]

We've been waiting for this feature since December. Our devs work out of forked repos, so we're unable to run tests on pull request because they're separate forks, even though everyone is apart of the organization that's private.

This means we have no feedback before merging stuff in.

[chrispat]

@Penagwin that is a different issue and it is something we are working on enabling. There will be some additional settings in your org and repos that you will be able to enable that will allow runs from forks of private repos.

[Penagwin]

@chrispat Is there an issue number I can track or an eta? I know covid threw a wrench in everything, but we've been waiting 8 months now...

[qinsoon]

We are eager to see this feature as well. I am also wondering if there is a workaround/hack for now to protect workflow files from unprivileged contributors. I found none... If anyone has a suggestion, I am happy to dig it deeper.

[MalloZup]

@qinsoon this feature could be implemented on the runner. SO yes it is possible to protect the workflow file without having to wait of unknown Feature coming from the github gui, which imho will not come really soon.

for reference take this comment: https://github.com/actions/runner/issues/494#issuecomment-640346592

This is why I was also thinking that implementing it on the backend, is a more low-hanging fruit which will help the github action to become useful for people in short-term, without compromising the design of longterm ( taking this from gui).

So even if forking is always sub-optimal, I guess it would be ok to try it.

if anyone is willing to do this, create a LINK here so people can try it at least. :+1:

[MalloZup]

as I imagine the feature , it could be like this in the minimal way:

1. add a flag called like github_users="GINO;BAMBY;SUPERMAN" this flag is added to the action runner when started; ( if an user removal or addition, the admin of the worker need to restart the worker with new flag, but I guess this is not really time consuming)

only the user of github users can modify the workflow file.

The logic would be to have something https://github.com/actions/runner/issues/494#issuecomment-640346592 like stated on that comment.

I am not familiar to C# code and also maybe the runner itself would be need some developer documentation in order to explain its design and make it more accessible for the community to contribute, imho.

[chrispat]

These features can't be implemented in the runner in an efficient and secure way. We need to check these sorts of permissions before we allocate a VM. Also the runner is a hostile environment that can execute arbitrary code from an end user and really should not be considered for any sort of security boundary.

Unfortunately, there is no way for me to give you an issue to track for new features in the GitHub.com code base.

[MalloZup]

thx @chrispat fair enough. lets keep this issue open and maybe give update it here. enjoy.

[michhyun1]

We've been waiting for this feature since December. Our devs work out of forked repos, so we're unable to run tests on pull request because they're separate forks, even though everyone is apart of the organization that's private.

This means we have no feedback before merging stuff in.

I think this in itself needs to be its own issue. What's the point of a rep owner creating CI workflow github actions if that workflow doesn't run when an external customer submits a PR from a forked repo branch? I noticed the docs say 'private' base repo, but does it work for a public base repo?

Is there a GH issue for this that is currently being tracked?

[derekbelrose]

I was thinking the best way to handle this is to have a check box or something that requires CODEOWNER approval before running any webhooks in branch protections. This is a problem that exists not with just Github Actions but with Travis and CircleCI. A change to the respective workflows in a PR can trigger the workflow and they all use the PR as the basis for the workflow tasks.

So, I think being able to defer the triggering of webhooks until approval is a mitigation step. Make it off by default so not to break existing workflows.

[eladchen]

How about this:

An example:

Let's say .github/workflows/pull-request.yml exists, and the suggested checkbox above is checked, and user John / DEV team is configured.

Workflow ".github/workflows/pull-request.yml" will not be executed if:

• A pull request is created based of a forked repository
• The pull request changed files include .github/workflows/pull-request.yml
• The pull request is not authored (triggered?) by user John / a member of DEV team.

This allows contributors to create pull requests, and have workflows provide them (and maintainers) with feedback on the changes introduced by the pull request, and, in the same time preventing untrusted parties from changing a workflow, thus preventing any security issues that might arise.

WDYT?

[derekbelrose]

@eladchen Im not sure how much work that is on the github end but that’s almost exactly what I need!

[eladchen]

I am not a 100% sure but I have a feeling a dedicated github app can be written to accommodate my suggestion, while waiting for a response/solution from the github folks.

IMO this would be a killer feature given many (and I mean many) people fail to recognise this is a potential security risk, especially open source ones.

[problame]

Also interested in this feature, pretty much as outlined above.

My use case: I maintain an open source project and want to automate building Debian packages, including pushing them to packagecloud. Right now, I can't do that with GitHub Actions because, to my understanding, any malicious PR could change the .yml file and steal the packagecloud credentials.

[allejo]

I think https://github.com/github/roadmap/issues/99 may be GitHub's solution to this problem?

[MalloZup]

@allejo thx for sharing! it cannot be considered a solution. I guess is okaish workaround, the real solution would be policies on users/group/org

If my repository has 100 PRS I Need 100 manual operation to approve manually to run and then wait. Where in travis or similar, I just view the results.

But I think imho could be better then nothing

[MalloZup]

@allejo do you know what is the workflow? when the PR there is merged means the feature is ready? or how that roadmap works? tia

[derekbelrose]

@allejo that actually doesn’t fix this unless the setting to not trigger the workflow or to set a manual approval exists outside of the workflow. Any PR could change the workflow and it would override the existing rules, otherwise.

My needs require a workflow not to trigger if the workflow files have been changed in the PR or the push.

[dkurt]

I believe that there is a way to make Runner.Listener protect self-hoster runners using Secrets. From the description:

Secrets are not passed to workflows that are triggered by a pull request from a fork.

So repository owner can define a pair which can be verified at runner's side:

./config.sh --url https://github.com/username/repository --token *** --secret MY_SECRET:MY_VALUE

please take a look at this proposal here: https://github.com/actions/runner/issues/631