Encrypted secrets in workflows on PRs from forks

[wangela]

Select Topic Area

Product Feedback

Body

I saw see in the documentation for Using encrypted secrets in a workflow that "With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository."

This is a problem for us, as we need to inject an API key to run tests on PRs. The API key is stored in encrypted secrets, but if the test workflows cannot access the secret when run from a forked PR (i.e. any open source contributor who is not an admin), then we cannot ensure that the PRs pass tests before merging them.

The documentation linked above does not offer a workaround or alternative approach. Is support for encrypted secrets in workflows on fork PRs a feature request that you have on your backlog or do I need to find an alternative method for securely injecting API keys into open source test workflows?

Example

https://github.com/googlemaps/android-maps-compose/blob/main/.github/workflows/instrumentation-test.yml#L48 is meant to access a key from encrypted secrets. This test workflow runs as a check on every incoming PR.

You can see in the run history it passes on main and on branches, but fails on forks because the secret is returned as null.

[artis3n]

I have this issue as well. I don't have a solution that I like, but I have one that works. You can use a pull_request_target trigger to run a workflow from the context of your repo's main branch, but check out the fork PR's code. Limitation: changes to the workflow itself will not be seen until hey are in your default branch, but this will run the workflow that exists on your default branch against any changes on the fork PR, using your repo's secrets.

This is dangerous

To make this safe, run any job that uses secrets and is trigged by pull_request_target under a GitHub Environment, like https://github.com/artis3n/ansible-role-tailscale/blob/main/.github/workflows/pull_request_target.yml#L78. Make sure the environment is configured for a team or set of maintainers to be required to review.

This blocks execution of those jobs until a repo maintainer inspects the code, verifies it isn't going to do anything malicious with the secrets, then "approves" the environment deployment. Then the jobs will run under the fork PR's code with access to your secret.

My biggest gripes about this:

• That manual approval every time a new commit is pushed, but that's a tradeoff to allowing folks access to the secret, don't really see a way around that
• The UI of your jobs deploying to the environment sucks. If you have a lot of jobs, or simply a lot of commits in a PR, your PR comments will be wiped away by a million lines of how many jobs were deployed to the environment - see feat: Allow ignoring auth key change artis3n/ansible-role-tailscale#320 for what I'm talking about. I wish there was a way to disable this UI component.

But, at the end of the day with this method you are able to run jobs on forks with secrets safely.

I would love some better UX to allow contributions from forks when a project has secrets it needs to inject into its CI checks in PRs.

[jsoref]

If you can structure your secret to be relatively harmless if compromised, then you can use pull_request_target, set permissions to read as required (thus blocking write) and check out the desired PR head using actions/checkout.

The workflow changes thing can be addressed by having an extra check that reports when the workflow is changed in a PR from a fork combined with a secondary repository that has a similar token and to which you promote the PR'd content for testing the modified workflow -- I'd personally do this manually, but you could use automation (a deploy key). Imagine two organizations my-org and my-org-untrusted where my-org/repository is forked as my-org-untrusted/repository. When someone makes a PR into my-org/repository, you can (manually or automatically) copy the contents of the PR into a branch in my-org-untrusted/repository, and then potentially create a PR (in my-org-untrusted) to test the modified workflow.

[RomanBredehoft]

Definitively agree, I'm encountering the same exact issue : whenever an external user opens a PR from a fork, our workflow that runs checks fails because it does not have access to secrets 😞

I'm still really surprised that such a feature, which looks like a pretty common thing for open-source projects, is not supported. After hours trying to find some solutions, I more or less concluded that the best solution is indeed what @artis3n suggests, so thanks ! Still, it would be much better if GitHub could provide a proper solution for this.