Tighten up the GitHub Actions workflow permissions

[johnbillion]

This change uses the principal of least privilege to tighten up the permissions that are granted to the GITHUB_TOKEN access tokens that get granted and used during GitHub Actions workflow runs.

This minimises the impact that a token leak can have and allows the "Workflow permissions" setting on https://github.com/WordPress/Requests/settings/actions to be switched to read-only from its current read and write setting.

Further reading:

• https://github.com/johnbillion/awesome-github-actions-security
• https://developer.wordpress.org/coding-standards/wordpress-coding-standards/github-actions/

Pull Request Type

• I have checked there is no other PR open for the same change.

This is a:

• Bug fix
• New feature
• Documentation improvement
• Code quality improvement

Context

The security team are working on publishing full guidance, standards, and tools for GitHub Actions workflow hardening across the WordPress organisation on GitHub. This is a hardening measure while that's all being worked on.

[jrfnl]

@johnbillion Thank you for this PR. I've looked into adding these permissions before, but got stuck on insufficient documentation being available on when which permission is needed.

Would you mind explaining how you determined the needed permission for these actions now ?

An example of something which I never really got clarity on, is whether jobs which post an annotation to a PR with feedback need additional permissions or not.

Another thing - as far as I understand it, it is a common best practice to document the permissions added for each job with a small comment. This is also encouraged by tools like zizmor. Is there any particular reason that best practice is not being applied ?

[johnbillion]

I've looked into adding these permissions before, but got stuck on insufficient documentation being available on when which permission is needed.

Yeah we got caught on this when tightening up the wordpress-develop and gutenberg repos last year. There isn't any documentation that allows you to easily correlate existing workflow jobs with the permissions that they require. We went too tight on a few jobs in gutenberg and had to loosen the permissions after the job failed with a permissions error.

Would you mind explaining how you determined the needed permission for these actions now ?

All the jobs with just contents: read are jobs that checkout the codebase but otherwise don't interact with a GitHub service. They can technically run with no permissions at all, but if a contributor operates a private fork then contents: read is needed.

The general approach to determining permissions is to go through each step in each job and identify whether it interacts with a GitHub service, for example by calling a GitHub API endpoint directly, using the gh tool, or using an action that does so. After that it's a bit of experience and research to determine which capabilities are the minimally required ones.

An example of something which I never really got clarity on, is whether jobs which post an annotation to a PR with feedback need additional permissions or not.

This doesn't need any permission, because annotations come directly from the output in the workflow run log.

Another thing - as far as I understand it, it is a common best practice to document the permissions added for each job with a small comment. This is also encouraged by tools like zizmor. Is there any particular reason that best practice is not being applied ?

No reason, which is ironic because I was the person who added that audit to Zizmor. I've just pushed a commit that adds inline comments!