Skip to content

GitHub Workflows security hardening #29171

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

Closed
wants to merge 1 commit into from

Conversation

sashashura
Copy link
Contributor

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.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Sep 19, 2022
@bclozel
Copy link
Member

bclozel commented Sep 19, 2022

Thanks, but this is already taken care of.
See #29104 (comment)

@bclozel bclozel added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Sep 19, 2022
@bclozel bclozel closed this Sep 19, 2022
@sashashura
Copy link
Contributor Author

I respectfully disagree. By setting the default repository setting to Read-Only you potentially breaking the backport-bot step, because it may need the permission to create/close issues.
The repo or org level read only setting is good until you actually need write permissions.

@bclozel
Copy link
Member

bclozel commented Sep 19, 2022

Good catch!

@bclozel bclozel reopened this Sep 19, 2022
@bclozel bclozel added type: task A general task and removed status: declined A suggestion or change that we don't feel we should currently apply labels Sep 19, 2022
@bclozel bclozel added this to the 6.0.0-RC1 milestone Sep 19, 2022
@bclozel bclozel closed this in 5277b1d Sep 19, 2022
@bclozel bclozel self-assigned this Sep 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: task A general task
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants