Deploy staging branch action fails on forks and dependabot

[srallen]

The deploy staging branch action fails for forked branches that have opened a pull request. See:

https://github.com/zooniverse/Panoptes-Front-End/pull/5933 https://github.com/zooniverse/Panoptes-Front-End/pull/5931 https://github.com/zooniverse/Panoptes-Front-End/pull/5930

When opened from a forked repository from a person, the behavior is to not use repository or organization secrets.

Secrets are environment variables that are encrypted. Anyone with collaborator access to this repository can use these secrets for Actions.

Secrets are not passed to workflows that are triggered by a pull request from a fork. Learn more.

Dependabot since its update is being treated like a fork even though it create branches. Explanations:

https://github.blog/changelog/2021-02-19-github-actions-workflows-triggered-by-dependabot-prs-will-run-with-read-only-permissions/ https://securitylab.github.com/research/github-actions-preventing-pwn-requests/

Preventing the usage of our secrets as well as not deploying to our blob storage from forks are both reasonable rules to maintain. Many kinds of potential exploits could be imagined if we allowed this:

• a compromised npm module is distributed, dependabot opens a PR, which runs the action, scoops our secrets, and deploys nefarious javascript to our blob storage
• a bad actor opens a pull request, which auto deploys and has an XSS exploit in the javascript and uses our domain to distribute the bad code

We will lose a convenience, but considering the potential exploits, we probably shouldn't have been doing this with Jenkins either.

Going forward, what we can do while maintaining this security standard are:

• If you are a trusted organization member with the correct permissions, then open pull request using branches on origin
• Conditionally run the branch deployment only for branches on origin, so that we don't have failed checked notices that we start to ignore
• Consider dropping branch deployments altogether and have an action that just checks that the build can run.

[eatyourgreens]

We could also run branch builds for PRs that have been explicitly labelled as safe by a reviewer.

Add a condition to the pull_request_target to run only if a certain label is assigned the PR, like safe to test that indicates the PR has been vetted by someone with write privileges to the target repository:

https://securitylab.github.com/research/github-actions-preventing-pwn-requests/

[eatyourgreens]

At the moment, I'm running builds for dependabot PRs by pressing the re-run all jobs button on those PRs, which re-runs the workflows with my permissions, as far as I can tell. I think having that manual safety check is a good idea. Our Jenkins set-up also requires you to log in to Jenkins and manually run builds for PRs from untrusted sources.

[eatyourgreens]

Adding to the list of exploits above, if you run npm install or yarn install locally, a malicious dependency can steal local secrets such as API tokens or ssh keys from your work machine. That can be mitigated by running builds with Docker, so that installed packages only have access to the container environment. Here's an example of npm packages installing backdoors.