Add functionality for allow self-hosted runner to protect workflow file and allow only execution only for collaborators for PRS #494
Comments
MalloZup
changed the title
|
@TingluoHuang that could be awesome thx! |
|
This would likely solve the security concerns of self-hosted runners |
|
yes this is the goal 🌞 |
|
@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. |
TingluoHuang
added
Service Feature
|
@chrispat yes I agree with you partially. Is like when developing a CLI command line. If an user use the CLI command line arguments, this 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 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). Thanks for your answer and time ping me for any info or I can help. |
|
@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. |
|
@chrispat do you know where I could open this issue for the github workflow engine? Thank you in advance |
|
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:
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. 💀 |
|
@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! |
|
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. |
|
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. |
|
@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. |
|
@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... |
|
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. |
|
@qinsoon this feature could be implemented on the runner. SO yes it is possible to protect the workflow file without having to wait of for reference take this comment: This is why I was also thinking that implementing it on the backend, is a more low-hanging fruit which will help the 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. 👍 |
|
as I imagine the feature , it could be like this in the minimal way:
only the user of github users can modify the workflow file. The logic would be to have something #494 (comment) like stated on that comment. I am not familiar to C# code and also maybe the runner itself would be need some |
|
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. |
|
thx @chrispat fair enough. lets keep this issue open and maybe give update it here. enjoy. |
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? |
|
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. |
|
How about this: An example: Let's say .github/workflows/pull-request.yml exists, and the suggested checkbox above is checked, and Workflow ".github/workflows/pull-request.yml" will not be executed if:
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? |
This addresses actions#494 at the runner level to give "just enough protection" to allow using self-hosted runners with public repos. By default, the current behaviour is unchanged -- all jobs passed to the runner are executed. If the `.runner` config file has this block added to it: ``` "pullRequestSecurity": {} ``` Then by only PRs from "CONTRIBUTORS" (as defined by the field in https://docs.github.com/en/free-pro-team@latest/graphql/reference/objects#pullrequest -- nothing for us to have to work out ourselves.) It is also possible to explicitly list users that are allowed to run jobs on this worker: ``` "pullRequestSecurity": { "allowedAuthors": ["ashb"] } ``` Or to _only_ allow the given users, but not all contributors: ``` "pullRequestSecurity": { "allowContributors": false, "allowedAuthors": ["ashb"] } ``` Owners of the repo are always allowed to run jobs.
This addresses actions#494 at the runner level to give "just enough protection" to allow using self-hosted runners with public repos. By default, the current behaviour is unchanged -- all jobs passed to the runner are executed. If the `.runner` config file has this block added to it: ``` "pullRequestSecurity": {} ``` Then by only PRs from "CONTRIBUTORS" (as defined by the field in https://docs.github.com/en/free-pro-team@latest/graphql/reference/objects#pullrequest -- nothing for us to have to work out ourselves.) It is also possible to explicitly list users that are allowed to run jobs on this worker: ``` "pullRequestSecurity": { "allowedAuthors": ["ashb"] } ``` Or to _only_ allow the given users, but not all contributors: ``` "pullRequestSecurity": { "allowContributors": false, "allowedAuthors": ["ashb"] } ``` Owners of the repo are always allowed to run jobs.
This addresses actions#494 at the runner level to give "just enough protection" to allow using self-hosted runners with public repos. By default, the current behaviour is unchanged -- all jobs passed to the runner are executed. If the `.runner` config file has this block added to it: ``` "pullRequestSecurity": {} ``` Then by only PRs from "CONTRIBUTORS" (as defined by the field in https://docs.github.com/en/free-pro-team@latest/graphql/reference/objects#pullrequest -- nothing for us to have to work out ourselves.) It is also possible to explicitly list users that are allowed to run jobs on this worker: ``` "pullRequestSecurity": { "allowedAuthors": ["ashb"] } ``` Or to _only_ allow the given users, but not all contributors: ``` "pullRequestSecurity": { "allowContributors": false, "allowedAuthors": ["ashb"] } ``` Owners of the repo are always allowed to run jobs.
This addresses actions#494 at the runner level to give "just enough protection" to allow using self-hosted runners with public repos. By default, the current behaviour is unchanged -- all jobs passed to the runner are executed. If the `.runner` config file has this block added to it: ``` "pullRequestSecurity": {} ``` Then by only PRs from "CONTRIBUTORS" (as defined by the field in https://docs.github.com/en/free-pro-team@latest/graphql/reference/objects#pullrequest -- nothing for us to have to work out ourselves.) It is also possible to explicitly list users that are allowed to run jobs on this worker: ``` "pullRequestSecurity": { "allowedAuthors": ["ashb"] } ``` Or to _only_ allow the given users, but not all contributors: ``` "pullRequestSecurity": { "allowContributors": false, "allowedAuthors": ["ashb"] } ``` Owners of the repo are always allowed to run jobs.
This addresses actions#494 at the runner level to give "just enough protection" to allow using self-hosted runners with public repos. By default, the current behaviour is unchanged -- all jobs passed to the runner are executed. If the `.runner` config file has this block added to it: ``` "pullRequestSecurity": {} ``` Then by only PRs from "CONTRIBUTORS" (as defined by the field in https://docs.github.com/en/free-pro-team@latest/graphql/reference/objects#pullrequest -- nothing for us to have to work out ourselves.) It is also possible to explicitly list users that are allowed to run jobs on this worker: ``` "pullRequestSecurity": { "allowedAuthors": ["ashb"] } ``` Or to _only_ allow the given users, but not all contributors: ``` "pullRequestSecurity": { "allowContributors": false, "allowedAuthors": ["ashb"] } ``` Owners of the repo are always allowed to run jobs.
This addresses actions#494 at the runner level to give "just enough protection" to allow using self-hosted runners with public repos. By default, the current behaviour is unchanged -- all jobs passed to the runner are executed. If the `.runner` config file has this block added to it: ``` "pullRequestSecurity": {} ``` Then by only PRs from "CONTRIBUTORS" (as defined by the field in https://docs.github.com/en/free-pro-team@latest/graphql/reference/objects#pullrequest -- nothing for us to have to work out ourselves.) It is also possible to explicitly list users that are allowed to run jobs on this worker: ``` "pullRequestSecurity": { "allowedAuthors": ["ashb"] } ``` Or to _only_ allow the given users, but not all contributors: ``` "pullRequestSecurity": { "allowContributors": false, "allowedAuthors": ["ashb"] } ``` Owners of the repo are always allowed to run jobs.
This addresses actions#494 at the runner level to give "just enough protection" to allow using self-hosted runners with public repos. By default, the current behaviour is unchanged -- all jobs passed to the runner are executed. If the `.runner` config file has this block added to it: ``` "pullRequestSecurity": {} ``` Then by only PRs from "CONTRIBUTORS" (as defined by the field in https://docs.github.com/en/free-pro-team@latest/graphql/reference/objects#pullrequest -- nothing for us to have to work out ourselves.) It is also possible to explicitly list users that are allowed to run jobs on this worker: ``` "pullRequestSecurity": { "allowedAuthors": ["ashb"] } ``` Or to _only_ allow the given users, but not all contributors: ``` "pullRequestSecurity": { "allowContributors": false, "allowedAuthors": ["ashb"] } ``` Owners of the repo are always allowed to run jobs.
This addresses actions#494 at the runner level to give "just enough protection" to allow using self-hosted runners with public repos. By default, the current behaviour is unchanged -- all jobs passed to the runner are executed. If the `.runner` config file has this block added to it: ``` "pullRequestSecurity": {} ``` Then by only PRs from "CONTRIBUTORS" (as defined by the field in https://docs.github.com/en/free-pro-team@latest/graphql/reference/objects#pullrequest -- nothing for us to have to work out ourselves.) It is also possible to explicitly list users that are allowed to run jobs on this worker: ``` "pullRequestSecurity": { "allowedAuthors": ["ashb"] } ``` Or to _only_ allow the given users, but not all contributors: ``` "pullRequestSecurity": { "allowContributors": false, "allowedAuthors": ["ashb"] } ``` Owners of the repo are always allowed to run jobs.
This addresses actions#494 at the runner level to give "just enough protection" to allow using self-hosted runners with public repos. By default, the current behaviour is unchanged -- all jobs passed to the runner are executed. If the `.runner` config file has this block added to it: ``` "pullRequestSecurity": {} ``` Then by only PRs from "CONTRIBUTORS" (as defined by the field in https://docs.github.com/en/free-pro-team@latest/graphql/reference/objects#pullrequest -- nothing for us to have to work out ourselves.) It is also possible to explicitly list users that are allowed to run jobs on this worker: ``` "pullRequestSecurity": { "allowedAuthors": ["ashb"] } ``` Or to _only_ allow the given users, but not all contributors: ``` "pullRequestSecurity": { "allowContributors": false, "allowedAuthors": ["ashb"] } ``` Owners of the repo are always allowed to run jobs.
|
My use case would be running hardware tests using Github Actions, the only workaround I can see right now is using https://github.blog/changelog/2020-12-15-github-actions-environments-environment-protection-rules-and-environment-secrets-beta/ to have a protected environment. But these approvals depend on the service where you deploy rejecting the request if someone makes a PR where the environment section is removed from the workflow. You could use this by having the runner under a restricted user and use the environment secrets to elevate it's access, but you would have to make sure they can't do anything malicious under the restricted user which is probably very hard. |
Different use case, but same worry is exactly the reason why I've been "carrying" my own patch for this for running Apache Airflow - #783 |
|
We have added some additional settings that may be a good solution to this problem. Please take a look at https://github.blog/changelog/2021-07-01-github-actions-new-settings-for-maintainers/ and see what you think. |
|
The run approval doesn't change anything about our worflow on the Apache Airflow team -- we are happy with the existing behaviour for PRs (run for non-committers on public runners) -- we just want to not have our release process held up in the shared queue with the apache org, and don't want to have to worry about doing detailed (security) review of a PR before running it on our self-hosted runners. |
|
It's really surprising to me that GitHub sets users up for failure here. All I really want is to have the workflow configuration always pulled from HEAD on my main branch and then run against the PR. I get that this makes it a little harder to iterate on workflows, but that's not the common case of workflow runs at all and I don't think it makes sense to optimize for it. Alternatively I'd take options to require approval when the PR modifies .github. As it is, I am actively looking to move my organization off of GitHub Actions which is really unfortunate. |
|
From my understanding, the conditions for a potential security breach are like so:
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** repoThe 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. I want to echo that it would be great if there was a way to lock down a self-hosted runner and not allow it to every run on PRs. |
|
What about:
|
|
I opened a feature that would solve this and seems fairly simple to implement, see https://github.com/orgs/community/discussions/53430 |
|
Hey @MalloZup, Thank you for your interest in the runner application and taking the time to provide your valuable feedback. We kindly ask you to redirect this feedback to the GitHub Community Support Forum which our team actively monitors and would be a better place to start a discussion for new feature requests in GitHub Actions. For more information on this policy please read our contribution guidelines. @13013SwagR already opened the ticket here but you can add new one to the GitHub Community Support Forum. |
and others
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-requestworkflows.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
The text was updated successfully, but these errors were encountered: