Securing Deployment Workflows

Opening a new ticket because ticket here was closed:

https://github.community/t5/GitHub-Actions/Protecting-github-workflows/m-p/48499#M7189

If you have an automated workflow for production set up, it doesn’t seem like there’s a way to protect against malicous devs with write access to your repo from modifying the production deployment workflow yaml file, and deploying to production.

I investigated possibly requiring internal devs to fork our repo, however it seems like PRs from forked PRs don’t run any workflows, so we aren’t able to automatically tell if the changes passed testing/linting.

Any easy solution around this that still allows for automated production deployment workflows?

2 Likes

Hi @kceb ,

When you create a pull request from a forked repository to the base repository, GitHub sends the ‘pull_request’ event to the base repository and no pull request events occur on the forked repository.

Workflows don’t run on forked repositories by default. You must enable GitHub Actions in the  Actions  tab of the forked repository, then other event like push, release… etc will be triggered on forked repo.

Additionally, for deployment, typically there would be a password to access the target server, you can create a secret with password for the deploy. The secrets is not transferred to forked repo, it’s safe.

If the dev has write access to your repo, he can create own workflow yaml file and trigger the workflow. Hence, if you don’t want the dev to trigger the workflow, please don’t give him the write access.

Another option is,  you can set ‘Branch protection rule’ in ‘https://github.com/{org}/{repo}/settings/branches’.

For instance, your code is on master branch. You can create a branch protection rule for ‘master’ branch then ‘collaborators’(devs) cannot commit code directly in master branch. They can edit the dev or forked-repo branch and create pull request to master. The code reviewer will check the confirm the code and then approve/deny merge.

Thanks.

I think Github is missing some sort of Deployment Restriction feature. For example, this is what Bitbucket has: https://bitbucket.org/blog/build-trust-in-your-deployment-workflow-with-deployment-permissions

It only allows specific branches to trigger a deployment. With Github, although you can limit write permissions to specific branches, any branch can trigger a deployment so as long as a developer modifies the workflow to get triggered on their branch.

4 Likes

Thanks @kceb for your clarification! Currently deployment Restriction feature is not supported in Github. According to the policy, it’s recommended to raise your idea here where github product manager will take a review, thanks.

any update on this feature? I still think is a massive important feature for the future of github action.

Let distinguish this feature for 2 many use-case.

what @kceb is talking is about workflow on pull-request.

From my understanding there is no secure way to prevent a user to modify code or the workflow .yaml

So a X user can fork the repo and redirect output for self-hosted workers.

I think a possible solution is that the github action should have the following feature:

from the repo, I should be able to say run all workflow only for collaborators. This should be the correct fix from a user perspective or something similar