Protecting .github/workflows #25236
-
Hi all, It is mentioned onthis page that it is possible to restrict modifications of the workflow file. However I there is no explanation on how to do it. Is there a doc somewhere? I dig the actions/workflow framework but I am a little worried that anyone can change a workflow with a pull-request and expose secrets or disable checks. Thanks in advance, |
Beta Was this translation helpful? Give feedback.
Replies: 20 comments
-
Those are the old docs for workflows based on HCL. You should look at the docs for the new YAML workflows because a lot has changed. https://help.github.com/en/categories/automating-your-workflow-with-github-actions There are a few ways to control changes to workflows flows:
|
Beta Was this translation helpful? Give feedback.
-
Thank you @jeremyepling I will play with codeowners and see if works for me. |
Beta Was this translation helpful? Give feedback.
-
Hi, Does it mean that if you have an org that folks can contribute to private repository by creating branches and waiting for it to be reviewed before merging the PR to master, can go ahead create a branch, change the a workflow on the branch (allowing them to read secrets), and if the workflow changes live deployments there is no protection we can put. That eliminates the whole development workflow of having contirbutors helping collaborators on a repo and allowing them to make changes without a PR being approved and merged to master. Any way of protecting these? |
Beta Was this translation helpful? Give feedback.
-
OK. I’ve ran few tests. It seems like you first have to make sure you have a workflow that is looking at non-master (or whatever protected branches you have) to be able to run on them. You cannot create a branch, add a workflow in that branch and have it trigger on that branch if it’s not already merged to master(or default) which is great. You just have to make sure you don’t accidently introduce workflow that can change your production env on non master branches(or production branches) -duh :slight_smile: |
Beta Was this translation helpful? Give feedback.
-
Let’s say we have a deployment workflow that uses a secret key stored in github secrets. Can’t a dev with write-access make a branch off master, create a new workflow that runs on push to their custom branch, utilize the secret key that gets passed in, and trigger a deploy? How do you protect against that? Ideally I would like a dev to have write permissions but not deploy permissions I’d like to avoid having all internal devs fork the repo Edit: upon further investigation it seems like forks won’t run any workflows. That is a blocker for us because we need tests/linting to run on PRs |
Beta Was this translation helpful? Give feedback.
-
How would you achieve the above which you said earlier? Because I am able to do the exact opposite. |
Beta Was this translation helpful? Give feedback.
-
I don’t know how to deal with this situation. Let’s say I’ve a single workflow setup that runs on push to master only. But someone just forks the repo, add their own modified version of workflow and creates PR against master with Am I missing something here? I’m not sure this is the desired behaviour. |
Beta Was this translation helpful? Give feedback.
-
I’m on the same boat. I have a public repository that anyone can fork and submitted PRs to and right now anyone can change the .github/workflow files as they please and it’ll get executed just fine. With GitHub-owned runners that is less of a concern but with self-hosted runners this is a major security flaw. In Jenkins, we have a list of pre-approved users that will get their PRs built automatically and anyone else needs an okay from an admin before that happens. I don’t know how to implement this safely in GitHub Actions. I played with some actions that limit builds to a certain user list but, because the user list is inside the workflow file, contributors can simply erase that from the file and be fine. It’s unsettling. I think we need a flag somewhere saying the only workflows that will run are the ones in the master branch and not ones in other branches and/or PR’s. |
Beta Was this translation helpful? Give feedback.
-
As is already mentioned in prior comments, this question should not be marked “Solved”. An example of the problem:
However, there is no way to prevent a malicious PR to my repository which simply removes this line, thereby accomplishing a production deployment without the PR being merged. |
Beta Was this translation helpful? Give feedback.
-
I think and agree with @bittelc So the issue is not solved. And this issue should be differianted in 2 category.
The solution here proposed is only for workflow running on Branches. However if you have a workflow running for pull-request, there is no way by github to proctect a user to change the workflow for PR and redirect output. |
Beta Was this translation helpful? Give feedback.
-
@jeremyepling this issue is very much not resolved today. Here is one example of how the protection around the .github/workflow files are not sufficient. As @mallozup said: If a project has a workflow (example.yml) that is triggered on push to master, and I create a branch in the project and change the workflow example.yml to be triggered on pull_request against master and then change the workflow itself I can circumvent all branch protection and controls on the pipeline and use it to execute whatever I want and utilize the projects secrets. |
Beta Was this translation helpful? Give feedback.
-
I have opened an issue to runner repo regarding this: github.com/actions/runnerAdd functionality for allow self-hosted runner to protect workflow file and allow only execution only for collaborators for PRS
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...
enhancement
|
Beta Was this translation helpful? Give feedback.
-
Hi Everyone, I’ve put together a Github App that will trigger a workflow based on the changed files, and the actor behind the change. I’m looking for a few early adopters to provide feedback before releasing it. |
Beta Was this translation helpful? Give feedback.
-
The app has been released. GitHubBuild software better, togetherGitHub is where people build software. More than 50 million people use GitHub to discover, fork, and contribute to over 100 million projects. |
Beta Was this translation helpful? Give feedback.
-
Hey there, Best regards Peter |
Beta Was this translation helpful? Give feedback.
-
Hi, so what is the conclusion. I just set up Github actions to deploy to firebase But I also noticed that anyone could just edit the PR action to deploy to production instead and make a PR … |
Beta Was this translation helpful? Give feedback.
-
Perhaps PR/test and master/prod should be handled differently. In the PR case, a new PR and use Github actions to spin up a new server and deploy it, using a service account that does NOT have access to production stuff. Then when merging into master, instead, the production server can watch for webhooks and then pull/build/deploy it. This would solve the issue. |
Beta Was this translation helpful? Give feedback.
-
Hey everyone, have been any updates on this or is this still an issue? |
Beta Was this translation helpful? Give feedback.
-
Possible workaround is to use OpenID connect with reusable workflows and external secret storage like Azure KeyVault. If you deploy directly to the cloud you may need no secrets at all. Once you add check for valid You can’t prevent workflow modification this way but modified workflows would not have access to sensitive data. |
Beta Was this translation helpful? Give feedback.
-
I opened a feature request that would solve this and seems fairly simple to implement, see https://github.com/orgs/community/discussions/53430 |
Beta Was this translation helpful? Give feedback.
Those are the old docs for workflows based on HCL. You should look at the docs for the new YAML workflows because a lot has changed. https://help.github.com/en/categories/automating-your-workflow-with-github-actions
There are a few ways to control changes to workflows flows:
master
, it won’t run on master until that PR is merged intomaster
.