Navigation Menu

Skip to content
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

ci: add minimum GitHub token permissions for workflows #1792

Merged
merged 1 commit into from Oct 3, 2022

Conversation

varunsh-coder
Copy link
Contributor

Description

This PR adds minimum token permissions for the GITHUB_TOKEN in GitHub Actions workflows using https://github.com/step-security/secure-workflows.

GitHub Actions workflows have a GITHUB_TOKEN with write access to multiple scopes.
Here is an example of the permissions in one of the workflows:
https://github.com/spf13/cobra/runs/8125223301?check_suite_focus=true#step:1:19

After this change, the scopes will be reduced to the minimum needed for each workflow.

Motivation and Context

Signed-off-by: Varun Sharma varunsh@stepsecurity.io

Signed-off-by: Varun Sharma <varunsh@stepsecurity.io>
@CLAassistant
Copy link

CLAassistant commented Sep 1, 2022

CLA assistant check
All committers have signed the CLA.

@github-actions github-actions bot added the area/github For changes to Github specific things not shipped in the library label Sep 1, 2022
@github-actions github-actions bot added the size/S Denotes a PR that chanes 10-24 lines label Sep 1, 2022
@umarcor umarcor mentioned this pull request Sep 4, 2022
jobs:

golangci-lint:
permissions:
contents: read # for actions/checkout to fetch code

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems a little redundant to set the per-job permissions the same as the overall setting above. Are these changes generated from the security tool? If so, I suppose no harm in being a little more verbose.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @stmcginnis, are you asking why contents: read is repeated at workflow level and job level?

The golangci-lint job needs two permissions. If contents: read is not specified at the job level, it will not be granted to the job. GitHub permission model works in a way that if no permissions are specified, the top level ones will apply. But if they are specified at the job level, then the specific ones will apply. So if only pull-requests: read is specified at job level, only that will be granted.

Since this is a public repo, that should also work. The tool that generates these fixes does not distinguish between a public or a private repo...so it ends up being a bit verbose for public repos...

Copy link
Collaborator

@jpmcb jpmcb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow thanks for helping with this! 👏🏼

@jpmcb jpmcb added the lgtm Denotes "looks good to me" from maintainers and signals other collaboratores that a PR is ready label Oct 1, 2022
@jpmcb jpmcb merged commit 23fc5e0 into spf13:main Oct 3, 2022
@marckhouzam marckhouzam added this to the 1.6.0 milestone Oct 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/github For changes to Github specific things not shipped in the library lgtm Denotes "looks good to me" from maintainers and signals other collaboratores that a PR is ready size/S Denotes a PR that chanes 10-24 lines
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants