Are secrets used in github actions secure for public projects?

Imagine you have github actions that run on PRs and that use secrets (say to test on AWS). Are these secrets secure? i.e. could the person creating the PR exfiltrate them?

my gut feeling is yes, since they can modify the github action workflow, they can effectively do whatever they want to reveal the secret?

is this correct? if so, is there any way around it? if not, what am I misunderstanding?

Check the documentation on “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.

So someone who forks your repository and submits a pull request won’t be able to access your secrets. Of course if someone suggests changes to your workflow files you need to carefully review those to avoid introducing malicious code that way, but that applies to any other code as well. :wink:

However, someone who has direct push access to your repository might also push a malicious workflow.

so what does that mean?

a PR based off a fork won’t run the github action? or the github action will run, but fail because it doesn’t have access to the secret? (only PRs from branches within the repo would). Therefore making a PR that changes the workflow maliciously wont reveal the secrets, because it wont have access to the secrets

But conceptually the malicious PR that changes the workflow would have negative impacts if it gets accidentally merged, as it would be able to reveal the secrets on future runs of the workflow from the original repo?

it sounds like for an OSS project, one shouldn’t use actions to test PRs if one has to use secrets for testing, one needs some other bot / webhook that will do the test.


Assume I’m NOT part of your team, or a member of your public repo. I fork your public repo, make changes, and submit a pull request.

You have an action on the public repo, that goes out to AWS anytime a PR is submitted. Here’s what happens:

  • Your Action will run (up to the point where it needs AWS)
  • The AWS secret will NOT be available to my initial PR.
  • My PR will probably be in a failed state.

Hence, your secret is safe… however, you have no way of testing my changes. So, it’s probably best to create a separate action for public PRs … so you have an automated way of testing the code

what I have working right now is using the KinD action to setup kuberetes within the action VM and able to test with that. works surprisingly well, have multiple pods, deployments, services et al setup. not “fast” (i.e. the same set of tests run quicker locally, but if one writes the tests and kubernetes resources correctly (i.e. wait on kubernetes saying deployments are ready, serviced have endpoints setup, and the slowness of it exposed some bugs in my original set of tests) its seems to work reliably (i.e. once fixed the test infrastructure bugs, its never had a false negative, let alone one due to lack of performance)

1 Like