GitHub Workflows security hardening

[sashashura]

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.

[cla-bot[bot]]

Realm welcomes all contributions! The only requirement we have is that, like many other projects, we need to have a Contributor License Agreement (CLA) in place before we can accept any external code. Our own CLA is a modified version of the Apache Software Foundation’s CLA. Our records show that CLA has not been signed by @sashashura. Please submit your CLA electronically using our Google form so we can accept your submissions. After signing the CLA you can recheck this PR with a @cla-bot check comment. The GitHub usernames you file there will need to match that of your Pull Requests. If you have any questions or cannot file the CLA electronically, make a comment here and we will be happy to help you out.

[sashashura]

@cla-bot check

[cla-bot[bot]]

The cla-bot has been summoned, and re-checked this pull request!

[fealebenpae]

Hey @sashashura, thank you for the contribution!

It totally makes sense to assign the smallest needed permission set, but I am trying to understand the security implications of the change - since we don't use the pull_request_target trigger and require manual approvals for outside contributor PR workflows, the only other benefit I can think of is preventing third-party actions that receive the GITHUB_TOKEN secret in our own workflows to misuse it beyond its intended purpose, right?

[sashashura]

Yes, the threat model in this case is a compromise of a building tool. Your case is a little more specific since you call only actions. There are other ways to protect from a compromised action, like hash pinning, but the general principle still applies - run program with least needed privileges (like do not run with sudo unnecessarily). An example of currently assigned permissions: