ci: add minimum GitHub token permissions for workflows

[varunsh-coder]

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

• This is a security best practice, so if the GITHUB_TOKEN is compromised due to a vulnerability or compromised Action, the damage will be reduced.
• GitHub recommends defining minimum GITHUB_TOKEN permissions.
  https://docs.github.com/en/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token
• The Open Source Security Foundation (OpenSSF) Scorecards also treats not setting token permissions as a high-risk issue. This change will help increase the Scorecard score for this repository.

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

[CLAassistant]

All committers have signed the CLA.

[stmcginnis]

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.

[varunsh-coder]

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...

[jpmcb]

Wow thanks for helping with this! 👏🏼