Menu
I have a private repo with a GitHub Action that pushes the code to an AWS S3 bucket when there's a new push to the master branch. I need a pair of access keys to be able to push the contents and I'm storing them as GitHub Secrets and referencing them as environment variables in the build script. Now I would like to make this repo public in the near future, and I was wondering if it's a safe thing to do. The workflow (.github/workflows/main.yml) itself for the action is indeed publicly visible and what it does, but it only has the single command aws s3 cp myfile s3://my-bucket and absolutely no access keys in the code itself.
Is it safe to use GitHub Secrets for the Actions in a public repo? I am the sole owner and only contributor, this will not change in the future. I might switch to CodePipeline with a webhook later but wanted to try GitHub Actions first. Thanks.
480
GitHub uses a libsodium sealed box to help ensure that secrets are encrypted before they reach GitHub and remain encrypted until you use them in a workflow. For secrets stored at the organization-level, you can use access policies to control which repositories can use organization secrets.
GitHub ties repository secrets to only one repository. They're available to anyone with the collaborator role to use in actions. You can store 100 secrets per repository.
Using third-party actions Consequently, there is significant risk in sourcing actions from third-party repositories on GitHub. For information on some of the steps an attacker could take, see "Potential impact of a compromised runner."
GitHub Secrets are encrypted and allow you to store sensitive information, such as access tokens, in your repository.
On GitHub, navigate to the main page of the repository. Under your repository name, click Settings. In the left sidebar, click Secrets. Click New repository secret.
For 1., there is no 100% guarantee. Of course, the big hosters like GitHub and Bitbucket won't share your code intentionally with third parties, but there is always the possibility that some hacker manages to get the content of your private repositories.
Yes, it appears so. According to Github, you have organization-level access control policies to who can access your secrets. For secrets stored at the organization-level, you can use access policies to control which repositories can use organization secrets.
Git acts as the central point of truth for a project, so it makes sense, at least from a convenience point of view, that secrets are stored inside a private git repository to make distribution and access easy. But storing secrets like this is playing with fire, it only takes a very small incident to get burnt.
Yes, secrets are safe to use in public repositories but there are some things you should be careful about.
All secrets are automatically masked in build logs and show as ***. However, if during your workflow you create a sensitive credential from a secret (e.g. base64 an API key) then you should mask the new value so it doesn't leak in the build log.
echo "::add-mask::My sensitive value"
If you are very concerned about the security of your secrets, I would also suggest not using third party GitHub actions directly by following the action's tags or branches. Fork the action and use your fork in workflows. This will prevent the possibility of someone modifying an action you are using to capture secrets being used by the action, and send them to some external server under their control.
Alternatively, use the action directly and reference the commit hash for the version you want to target.
- uses: thirdparty/foo-action@172ec762f2ac8e050062398456fccd30444f8f30
Use two-factor authentication (2FA) on your account. If your account is compromised, it's trivial for an attacker to create a workflow and export your secrets.
Repository collaborators or any organization users with write access are able to create a workflow to export secrets. So manage access to your repository carefully.
Points related to pull requests:
pull_request events triggered by forks do not have access to secrets, except for the default GITHUB_TOKEN. Additionally, The GITHUB_TOKEN has read-only access when an event is triggered by a forked repository. These are intentional restrictions enforced by GitHub Actions to prevent an attacker creating a pull request containing a workflow that captures secrets, or uses secrets to perform operations.pull_request_target event does not have secret restrictions for events triggered by forks. By default it checks out the last commit on the base branch, but it is possible to checkout the pull request HEAD. Choosing to do this requires extreme caution. Passing secrets to any code that could be modified in a pull request could allow an attacker to write code to export secrets.
107
Yes, it appears so. According to Github, you have organization-level access control policies to who can access your secrets.
For secrets stored at the organization-level, you can use access policies to control which repositories can use organization secrets. Organization-level secrets let you share secrets between multiple repositories, which reduces the need for creating duplicate secrets. Updating an organization secret in one location also ensures that the change takes effect in all repository workflows that use that secret.
Whether the repository is public or private does not affect this, and that makes sense. Public projects need secrets, too.
39
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
