Thank you @jeremyepling 

I will play with codeowners and see if works for me.

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?

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:

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

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. 

@gabriel-kohen-jdas 

How would you achieve the above which you said earlier?

Because I am able to do the exact opposite.

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 on.pull\_request policy. Even tho secrets are not exposed to that PR, it’s still annoying if that PR contains something bad. Also even if base repo workflow contains policy for on.pull_request event, forked PR can still override base repo’s workflows. 

Am I missing something here? I’m not sure this is the desired behaviour.

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.

As is already mentioned in prior comments, this question should not be marked “Solved”.

An example of the problem:
I have enabled GitHub Actions to deploy to my production environment. To do this, GitHub Actions checks for:

if: github.ref != 'refs/heads/master'

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.

I think and agree with @bittelc 

So the issue is not solved.

And this issue should be differianted in 2 category.

• workflow on branches (yes this can be fixed easy)

• workflow on Pullrequests  (this is not fixed)

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.

@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.

I have opened an issue to runner repo regarding this:

<div class="github-info">
  <div class="date">
    opened <span class="discourse-local-date" data-format="ll" data-date="2020-05-20" data-time="16:41:26" data-timezone="UTC">04:41PM - 20 May 20 UTC</span>
  </div>


  <div class="user">
    <a href="https://github.com/MalloZup" target="_blank" rel="nofollow noopener">
      <img alt="MalloZup" src="https://user-images.githubusercontent.com/10886597/181089776-7aa7c28f-db57-4b65-97e5-1e6033d357c9.png" class="onebox-avatar-inline" width="20" height="20">
      MalloZup
    </a>
  </div>
</div>

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.
If you are interested please let me know, and I’ll setup a place for us to talk.

The app has been released.

https://medium.com/@eladchen/protecting-your-github-workflows-b4359683bd69?sk=d59c21f5edc62ffcd5e0d3b14bbedd35

Build software better, together

GitHub is where people build software. More than 50 million people use GitHub to discover, fork, and contribute to over 100 million projects.

Hey there,
any news here because the missing security features is causing some workarounds for us in our project. Does everyone has a good way of prevent specific roles or users to edit the workflow file and so get access to the repo secrets?

Best regards Peter

Hi, so what is the conclusion. I just set up Github actions to deploy to firebase
https://firebase.google.com/docs/hosting/github-integration

But I also noticed that anyone could just edit the PR action to deploy to production instead and make a PR …

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.

Hey everyone, have been any updates on this or is this still an issue?

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 job_workflow_ref as part of trust conditions between GitHub and cloud provider, only trusted workflows will be allowed to access secrets or other cloud resources.

You can’t prevent workflow modification this way but modified workflows would not have access to sensitive data.

I opened a feature request that would solve this and seems fairly simple to implement, see https://github.com/orgs/community/discussions/53430