GitHub Workflows security hardening#1162
Uh oh!
There was an error while loading. Please reload this page.
Conversation
Signed-off-by: Alex <[email protected]>
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 8e1855e:
|
Codecov Report
@@ Coverage Diff @@## main #1162 +/- ## ========================================= Coverage 100.00% 100.00% ========================================= Files 4 4 Lines 181 181 Branches 36 36 ========================================= Hits 181 181
Flags with carried forward coverage won't be shown. Click here to find out more. 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
| - '!all-contributors/**' | ||
| pull_request: {} | ||
| permissions: | ||
| actions: write # to cancel/stop running workflows (styfle/cancel-workflow-action) |
There was a problem hiding this comment.
Could you include a summary of the permissions before and after for each change?
There was a problem hiding this comment.
Before the change for all jobs (as seen here https://github.com/testing-library/react-testing-library/actions/runs/3633193928/jobs/6129924592):
GITHUB_TOKEN Permissions Actions: write Checks: write Contents: write Deployments: write Discussions: write Issues: write Metadata: read Packages: write Pages: write PullRequests: write RepositoryProjects: write SecurityEvents: write Statuses: write After the change
For the release job (not mention permissions are none):
GITHUB_TOKEN Permissions Actions: write Contents: write Metadata: read For all others:
GITHUB_TOKEN Permissions Actions: write Contents: read Metadata: read 
eps1lon commented Feb 16, 2023
This was missing |
2 participants
What:
This PR adds explicit permissions section to workflows.
Why:
This is a security best practice because by default workflows run with extended set of permissions (except from
on: pull_requestfrom external forks). By specifying any permission explicitly all others are set to none. By using the principle of least privilege the damage a compromised workflow can do (because of an injection or compromised third party tool or action) is restricted.How:
It is recommended to have most strict permissions on the top level and grant write permissions on job level case by case.
Checklist:
docs site N/A