-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GitHub Workflows security hardening #2740
Conversation
Signed-off-by: Alex <aleksandrosansan@gmail.com>
Signed-off-by: Alex <aleksandrosansan@gmail.com>
Signed-off-by: Alex <aleksandrosansan@gmail.com>
sgtm, someone else with more extensive Actions experience want to weigh in? I haven't played with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your contribution. I added one small comment. Other than that it looks good to me. For folks looking for the Github Workflow documentation, here's the link.
.github/workflows/release-please.yml
Outdated
@@ -5,8 +5,13 @@ on: | |||
branches: | |||
- main | |||
|
|||
permissions: {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems this line is unnecessary, since there is only one job in this workflow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is optionional. I have removed it now.
Is it ready to be merged? |
* build: harden tests.yml permissions Signed-off-by: Alex <aleksandrosansan@gmail.com> * build: harden release-please.yml permissions Signed-off-by: Alex <aleksandrosansan@gmail.com> * build: harden visual-studio.yml permissions Signed-off-by: Alex <aleksandrosansan@gmail.com> * Update release-please.yml --------- Signed-off-by: Alex <aleksandrosansan@gmail.com>
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_request
from 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.