Allowing github-actions[bot] to push to protected branch

[robozevel]

Hello,

I’m using Github Actions to auto approve and merge pull requests. I wasn’t able to allow github-actions[bot] to push to a protected branch using the settings page though, so I ended up using the REST API instead.

Would it be possible to allow this using the settings page? or enable it by default?

protected-branch.png1430×676 68.2 KB

Thanks!

[chrispat]

If we enabled GitHub Actions to push to a protected branch then any collaborator in your repo could push any code to any branch they wanted simply by creating a branch and coding the workflow to push to to some other branch.  Using the REST api to merge the PR is the right flow and overtime hopefully there will be actions that make that easier to implement.  

[robozevel]

Thanks!

Do you know of any possible solution to allow auto-merging as part of a workflow? I think it’s a common issue.

I’ve looked into automerge-action and it seems to suffer the same issue, the docs suggests using a pesonal access token but from my understaing it’s just as vulnerable.

Could there be any way of maybe limiting GitHub Actions to merge/push to the branch that invoked the workflow? or scoping secrets by branch? or auto-merge outside of GitHub Actions once all check runs are done?

[merlinnot]

I found a partial solution to this, it allows you to have protected branches that require 1 approval and a green CI. See https://github.com/ridedott/dependabot-auto-merge-action.

[bradleat]

The same thing applies for other bots. I don’t understand why you don’t allow the CodeOwner feature to prevent updating workflows, and then allow the github action bot to push to the same branch that triggered it.

Right now practically I have to choose between protecting branches and using Github Actions on that branch.

[mtesch-um]

This is kind of not a solution to the problem, it’s not necessarily true that any collaborator could do what you say, why should the workflow have the same permissions as an Action?  The collaborator would also have to be able to control the specific Action and what it does, not the whole runner.  Consider the following extremely common scenario:

• master is a protected branch, pushable by only administrators

• master furthermore has “require review” enabled

• feature branches are submitted as PRs

• when a PR is accepted, it gets pushed to master

• when a PR is pushed to master we want an auto patch version bump and tag of that version, on master

If a malicious collaborator wanted to run arbitrary code through a commit, they would have to get this arbitrary code through the review process.  It seems a bit paranoid to not create this feature based on the argument that a reviewer might make a stupid mistake, that is true regardless of whether the feature exists or not.

What we need to make this last step above work is for Actions to have their own permission set (or a way to make an imported action get the permissions of an App?  Or an App to work like an action?)  With a small modification to @robozevel 's suggestion, it seems like a good solution.  If there’s a way to do that already, I haven’t been able to find it, but would be more than happy to hear it!

[Crymzix]

I agree with this. @chrispat 's answer completely overlooks this common workflow and it would be great if there was a way to allow this to happen by allowing the GitHub token to have more fine-grained permissions.

[hipstersmoothie]

@chrispat I have created a token with every scope and I still can’t publish from a GitHub action. Everything works fine locally using this token. What could possibly be going wrong?

[tripodsan]

hi… did you figure out why this happens? I have the same issue.

[tripodsan]

btw, I found a solution by reading the documentation of:

GitHub

cycjimmy/semantic-release-action

GitHub Action for Semantic Release. Contribute to cycjimmy/semantic-release-action development by creating an account on GitHub.

it is important to either set the persist-credentials: false for the checkout action, or to use your own token for the checkout action.

[robtayl0r]

Personal Access Tokens are an anti-pattern here. When that user moves teams or leaves the company the actions will begin to fail.

The concept of a service account/user is the subject at hand here and it is not a new concept. The GITHUB_TOKEN used by Actions (a [THE] service) is how it authenticates with the repository service.Any traditional CI platform would allow you to assign specific roles and permissions to (one or many) service account as you would any user.

The fact that Github doesn’t allow this is a short coming. If you are inclined to create an entire Github user, inviting it to your team, this may work, but is not an ideal solution. Aside from the extra $4/mo cost to have this (service) user, a downside is you are now adding to your attack surface area for security breaches. Lock that user down with MFA? Great, now who owns the one time password/mfa registration? You are left in the same spot the PAT problem up top.

tldr; It’s absurd that the Github repository settings will not allow you to define how you want to trust it’s own internal service’s (Github Actions) token.

[icopp]

Is there still no option here that doesn’t require the anti-pattern of creating a bot user just to work around Github limitations?

[crazy-matt]

@chrispat Could you please explain us what could go wrong with the workflow described by @mtesch-um, I sum-up: PR reviews enforced including for administrators?
You throw up your answer but avoid answering to someone who got a real point here. What do we do to use Github with reviews including for administrators + automation?
As the others, I’m genuinely asking because we have a real use case that is explained and you don’t explain your view actually.

[jorhett]

@chrispat Now that this feature has merged, all we need is that GitHub Actions job runner could be selected for this Allow bypassing required pull requests | GitHub Changelog

This can be secure if you always run the master branch version of the jobs, and you have CodeOwners on the .github/workflows/ directory.

[chrispat]

This still wouldn’t be secure as the GitHub Actions user isn’t branch specific. So adding it to this list would mean that anyone could push from any branch using a workflow and bypass all branch protection rules.

In fact we are currently rolling out a change to prevent the GitHub Actions user from being included as a valid code reviewer for the required reviewers rule.

At the moment I can’t think of any mechanism that could safely enable force pushing to a protected branch using code that is inside the repo.

[austinsasko]

Well at present, users are inserting personal access tokens to do what the GITHUB_TOKEN secret should. Even making it so that ONLY on the main branch the token can override protected branches would be a huge step forward.

[vincent-mirian-google]

Hi,

We have the following action: https://github.com/google/xls/blob/c0a0011a044ec07bf9f3a23d269dcf9b0b0e4380/.github/workflows/build-mkdocs-commit-html.yml

The action produces the following error:

remote: error: GH006: Protected branch update failed for refs/heads/main.        
remote: error: You're not authorized to push to this branch. Visit https://docs.github.com/articles/about-protected-branches/ for more information.        
To https://github.com/google/xls.git
 ! [remote rejected]   main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/google/xls.git'
Error: Process completed with exit code 1.

The ‘xls-github-bot’ user has write access to the repo (Role is not Admin or Maintain).

Solutions that were tried but did not work:

1. Change permission of ‘xls-github-bot’ user to ‘Maintain’ and 'Admin
2. Add ‘xls-github-bot’ user to Restrict who can push to matching branches list in the branch rules section.

Questions:
1- Some posts suggest using a Personal Access Token (PAT). Would a PAT solve the issue? If so, can the ‘xls-github-bot’ user create a PAT named ‘XLS_GITHUB_TOKEN’ in their account and reference it via a ${{ secrets.XLS_GITHUB_TOKEN}}?

Any recommendations or suggestions to solve this issue would be appreciated.

Thank you in advance.

[vincent-mirian-google]

Update:

I found this post: How to push to protected branches in a GitHub Action. However, the issue is still present. Any help would be appreciated.

[Naatan]

I really don't understand the concern raised that this is a security issue. Isn't the whole point of this feature to allow users to configure how they want to secure their branches? It's up to users to decide whether your security concerns are relevant to their workflow.

Now we have to work around this silly limitation which likely raises far more security concerns.