We are excited to release a public beta of actions-permissions, a tool which monitors your GitHub Actions workflows and recommends the minimum permissions required to run them.
Every GitHub workflow receives a temporary repository access token (GITHUB_TOKEN). These tokens originally had a very broad set of permissions with full read and write to the repository (except for pull requests from forks). In 2021, we introduced a more fine grained permission model for workflow tokens and today the default permissions for new repositories and organizations are set to read-only. However, a significant number of workflows still use a write-all token due to default workflow permission settings without actually requiring write permissions. If you want to check if you are using a broad default permission for your workflow tokens, you can go to the repository (or organization) settings->actions and check the “Workflow permissions” section:
While changing this setting to read-only is a best security practice, it may potentially break existing workflows which currently “just work” with write-all permissions. Applying the least privilege security principle and assigning the minimal needed permissions for the repository token in every workflow case by case can also be a potentially breaking change because complex workflows may include multiple actions and it is easy to miss a permission required for the workflow to function properly. Because workflows can execute a variety of steps, pending error and success criteria, it is also challenging to uncover the full privilege set required for more complicated workflow definitions.
To help you more smoothly navigate the transition to a least-privilege workflow token model, we have published a set of GitHub Actions that allow you to monitor and enumerate the set of privileges that are required by a given GitHub workflow.
The Monitor action installs a local proxy (no information is sent to any third parties) into your workflow runner, collects information about any GitHub API interactions initiated by the workflow, and then displays the recommended minimal permissions as part of a workflow run summary:
The Advisor action, which you can also use as a local tool, is able to summarize the recommendations from multiple runs of the workflow:
Once you apply the recommended permissions in the workflow you can stop using the tools. Any newly required permissions for future iterations of your workflow can be added as needed.
We are excited to make the beta of our permission monitoring GitHub Actions available to you and hope they will help you transition to a more secure workflow permission model. Please give them a try and share your feedback with us!
Tags:
Written by
Related posts
From object transition to RCE in the Chrome renderer
In this post, I’ll exploit CVE-2024-5830, a type confusion in Chrome that allows remote code execution (RCE) in the renderer sandbox of Chrome by a single visit to a malicious site.
Configure GitHub Artifact Attestations for secure cloud-native delivery
Introducing the generally available capability of GitHub Artifact Attestations to secure your cloud-native supply chain packages and images.
3 ways to get Remote Code Execution in Kafka UI
In this blog post, we’ll explain how we discovered three critical vulnerabilities in Kafka UI and how they can be exploited.