1

The GitHub encrypted secrets documentation states:

Using encrypted secrets in a workflow

With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.

In light of this, what is the best-practice to configure GitHub Actions CI to run tests that depend on secret API keys as part of an open source PR review workflow?

I want to run tests that use secrets when PRs are pushed to my open source project. I do not want to do this automatically for all submitted PRs but I would like to do it automatically for PRs from project members and I would like to be able to enable/trigger the CI run for 3rd-party contributions after manual review. I understand that there are security implications to this, and I am prepared mitigate the impacts of a leaked or misused secret.

I hit this problem with the following setup:

I have a public GitHub repo in its own organization (the "main repo"). I have a fork in my personal account (my "developer fork"). I am an owner of the org repo with full permissions.

My integration tests require a third-party secret API key (say FOO_API_KEY) to perform end-to-end tests. In each repo (main, dev fork) I have set up GitHub Secrets environments with the name test_environment. In both repos FOO_API_KEY is set up as an Environment Secret.

The repos have the same GitHub test.yaml workflow available. A simplified version of the workflow is:

name: Run tests

on: [push, pull_request]

jobs:
  test:
    name: Run tests
    runs-on: ubuntu-latest
    environment: test_environment
    steps:
      - uses: actions/checkout@v3
      - name: Set up Python 3.10
        uses: actions/setup-python@v4
        with:
          python-version: 3.10
      - name: Install package and dependencies
        run: pip install .[test]
      - name: Run tests
        env:
          FOO_API_KEY: ${{ secrets.FOO_API_KEY}}
        run: python -m pytest .

When this CI action is triggered by a direct push to either the main repo or my development repo, the tests run successfully. But when the CI action runs in the main repo as part of a PR (from myself), the tests fail due to a missing FOO_API_KEY (as expected, based on the GitHub doc cited above).

I got to this point by inspecting the CI logs and noticing that in a successful CI run, the CI logs for "Set up job" include the line:

Secret source: Actions

Whereas in a failing run, triggered by a PR, the CI logs for "Set up job" include the line:

Secret source: None

This situation is unsatisfactory, because I can not even run CI on my own PRs in the main repo without them failing due to unavailable secrets.

Ross Bencina
  • 3,822
  • 1
  • 19
  • 33
  • The following question asks the related question of how to mitigate secrets leaks: https://stackoverflow.com/questions/75873833/how-to-protect-github-secrets-in-pull-request-actions-from-malicious-pull-reques – Ross Bencina Jul 23 '23 at 03:32

0 Answers0