GitHub Workflows security hardening #2899
Conversation
Signed-off-by: Alex <[email protected]>
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 7d04d43:
|
| @@ -8,8 +8,13 @@ on: | |||
|
|
|||
| concurrency: ${{ github.workflow }}-${{ github.ref }} | |||
|
|
|||
| permissions: {} | |||
There was a problem hiding this comment.
q: is this required if explicit permissions are specified for one of the jobs?
There was a problem hiding this comment.
It is optional. I added it prevent the case when a new job is added and it inherits the default permissions, but as long as there is only one job it will use it's own permissions.
| @@ -6,6 +6,9 @@ on: | |||
| - main | |||
| pull_request: | |||
|
|
|||
| permissions: | |||
| contents: read # to fetch code (actions/checkout) | |||
There was a problem hiding this comment.
shouldn't this only be granted for actions/checkout?
There was a problem hiding this comment.
Permissions are per job unfortunately, not per step. All jobs do checkout, so it makes sense to define it a global.
.github/workflows/release.yml
Outdated
| contents: write # to create release | ||
| pull-requests: write # to create pull request |
There was a problem hiding this comment.
are you a Changeset user? did you have a chance to confirm that those are the only ones needed for this action?
There was a problem hiding this comment.
It is optional. I added it prevent the case when a new job is added and it inherits the default permissions, but as long as there is only one job it will use it's own permissions. Wrong comment
There was a problem hiding this comment.
I didn't have a chance to try it. If it fails it can be expanded.
|
Is it ready to be merged? |
This PR adds explicit permissions section to workflows. 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.It is recommended to have most strict permissions on the top level and grant write permissions on job level case by case.