Set top level permission to remaining workflows #13385
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Joyce <joycebrum@google.com>
Signed-off-by: Joyce <joycebrum@google.com>
Signed-off-by: Joyce <joycebrum@google.com>
Signed-off-by: Joyce <joycebrum@google.com>
Signed-off-by: Joyce <joycebrum@google.com>
|
@joycebrum thanks a lot! Can you please also sign our ICLA: https://netty.io/s/icla |
|
Done! Thanks for the reminder. |
|
@joycebrum I think |
|
It seems that the write permission to create tags and releases is coming from SSH_PRIVATE_KEY_PEM and not GITHUB_TOKEN so GITHUB_TOKEN might not need it. If it was an action used to create the release, for example, (such as softprops/action-gh-release), then it would need to grant permission to GITHUB_TOKEN. |
normanmaurer
pushed a commit
that referenced
this pull request
May 22, 2023
Motivation: Setting minimum permissions on workflow's top level is good practice. Similar changes were previously discussed in #12462. Since some workflows were left out of the previous PR, this PR is a small update to restrict their permissions. Modification: Set top level read only permission to `ci-deploy.yml`, `ci-pr.yml`, `ci-release.yml` and `ci-release5.yml` I wasn't able to test the workflows: - `ci-release.yml` and `ci-release5.yml`: although I wasn't able to test successfully, considering that they are basically using personalized secrets and not the standard GITHUB_TOKEN (github.token), I've considered that no write permission would be needed to it. To avoid errors I've opted for `read-all` instead of `contents: read`. - `ci-deploy.yml` also seems to not be working so I wasn't able to provide a success example either. - `ci-pr.yml` run example https://github.com/joycebrum/netty/actions/runs/4994205584. Not sure why it didn't run on my fork but the errors seems not to be related to any permission. Anyway, I've changed the permission to read-all which certainly will be enough since it runs on pull request (which will always be no more than read-all to external PRs). Result: Similar change discussed at #12462: since github workflow default behavior is to grant write all permission to any workflow it is both a recommendation from [OpenSSF Scorecard](https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions) and the [Github](https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions) to always use credentials that are minimally scoped. --------- Signed-off-by: Joyce <joycebrum@google.com>
|
@joycebrum thanks a lot! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation:
Setting minimum permissions on workflow's top level is good practice. Similar changes were previously discussed in #12462. Since some workflows were left out of the previous PR, this PR is a small update to restrict their permissions.
Modification:
Set top level read only permission to
ci-deploy.yml,ci-pr.yml,ci-release.ymlandci-release5.ymlI wasn't able to test the workflows:
ci-release.ymlandci-release5.yml: although I wasn't able to test successfully, considering that they are basically using personalized secrets and not the standard GITHUB_TOKEN (github.token), I've considered that no write permission would be needed to it. To avoid errors I've opted forread-allinstead ofcontents: read.ci-deploy.ymlalso seems to not be working so I wasn't able to provide a success example either.ci-pr.ymlrun example https://github.com/joycebrum/netty/actions/runs/4994205584. Not sure why it didn't run on my fork but the errors seems not to be related to any permission. Anyway, I've changed the permission to read-all which certainly will be enough since it runs on pull request (which will always be no more than read-all to external PRs).Result:
Similar change discussed at #12462: since github workflow default behavior is to grant write all permission to any workflow it is both a recommendation from OpenSSF Scorecard and the Github to always use credentials that are minimally scoped.