Support specifying the default permissions for a GitHub Action token

[eclipse-csi-bot]

In GitLab by @sschrock on May 12, 2023, 03:44

By default, the GITHUB_TOKEN present in a GitHub Action workflow is overly permissive and contain write access to repository contents and releases. This presents a risk as developers may not realize the token they're passing to a linter could be used to modify the repository.

GitHub supports restricting the default GITHUB_TOKEN permissions at the enterprise/org/repo level.
https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

OtterDog would benefit from adding support for this setting, and considering restricted permissions as a secure default. This setting provides a quick win for repository security without needing to change every workflows. Note: some workflows may need to add permissions which were previously granted by default, but this follows least privilege.

[eclipse-csi-bot]

In GitLab by @netomi on May 12, 2023, 06:52

Ty for your report though I am not sure to what workflow you refer to.
Currently we use such a validate workflow that runs automatically for PRs to validate the configuration and highlight actions that otterdog will perform due to the changes. An example of this workflow can be seen here (its normally in private repos as we keep the configuration on organization level private atm):

https://github.com/OtterdogTest/eclipsefdn-template/blob/main/.github/workflows/validate.yml

There we specify the permissions for the GITHUB ACTION token:

content: read
pull-requests: write as we want to add a comment to the PR for the result of the validation

[eclipse-csi-bot]

In GitLab by @sschrock on May 12, 2023, 07:55

Ah sorry for any confusion. This wasn't relating to any workflow in particular. I just didn't see "workflow permissions" as a supported org/repo setting on the README. I attended the OtterDog talk at OSS NA which talked about configuring branch protection, and thought it would be a setting that OtterDog could use when configuring orgs or repos.

You can set the default permissions for the GITHUB_TOKEN in the settings for your organization or your repositories

I can give an example though. Take this GitHub workflow under the eclipse foundation:
https://github.com/eclipse/mosquitto/blob/65a6ed43a5a4806dc1ea12f9a52ed57ad6de1c5a/.github/workflows/delete-old-workflow-runs.yml

As it doesn't specify any permissions, the GITHUB_TOKEN sent to Mattraks/delete-workflow-runs@v2 has the permissive default permissions mentioned in my first comment. While the action needs actions: write to delete the workflow runs, it doesn't need the contents: write or packages: write that also come with the token. If the action were ever compromised, it could do more damage to the project than if it only had actions: write.

If the org/repo was instead configured with the restricted default permissions, this sort of over privileged token could be prevented. Although in this case the workflow would need to have the actions:write permission added to continue working.

Of course, the eclipse foundation could already enforce restricted default permissions on its tokens, so this example could be invalid. But being able to specify an org or repo default permission in an OtterDog config seems like it would be useful for you all.

[eclipse-csi-bot]

In GitLab by @netomi on May 12, 2023, 08:09

Ah now I understand, you refer to these settings:

They exist on organization and repo level. Unfortunately, they are not accessible via any programmatic API so far, so otterdog would have to access it via the web UI (which it already does for some other settings). It makes certainly sense, will work on that. Ty for the report!

[eclipse-csi-bot]

In GitLab by @netomi on May 12, 2023, 10:13

mentioned in commit 18e79e7

[eclipse-csi-bot]

In GitLab by @netomi on May 12, 2023, 10:16

Added support for a new setting 'default_workflow_permissions' on organization level which can either be 'read' or 'write'.

We dont use the web ui yet for repo level settings as this would make the tool rather slow when you have lots of repos in your organization. For now I would omit the very same setting on repo level, if you specify e.g. read on org level you can not be more permissive on repo level anyway. The default should be read on org level and then enable for each workflow individually if it requires more permissions.