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?
Thanks!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.
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?
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.
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.
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!
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.
@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?
hi… did you figure out why this happens? I have the same issue.
btw, I found a solution by reading the documentation of:
it is important to either set the persist-credentials: false for the checkout action, or to use your own token for the checkout action.
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.
