Changes to the default GITHUB_TOKEN permissions

GitHub have recently announced a default change to the permissions of the GITHUB_TOKEN, from read/write to read only.

When enabling GitHub Actions, a GitHub app is installed on your repository that generates a GITHUB_TOKEN. At the start of each workflow run, the token is retrieved and can be used to authenticate on behalf of the workflow. This token expires at the end of every job and can last up to 24 hours.

When the GITHUB_TOKEN is used in a workflow it can have access to write to multiple scopes. If the token is misused or if an unauthorised user get access to the token, they will have access to modify pull requests, issues, delete packages and more in that repository, which can have an impact on any releases.

To see the full scope of the GITHUB_TOKEN, see the link below:

Automatic token authentication – GitHub Docs

This change will only be enabled for any new GitHub enterprise accounts, organisations not in an enterprise and personal repositories. To ensure all current and future repositories inherit this change, this setting needs to be updated at the enterprise or organisational level.

Modifying GITHUB_TOKEN permissions

To modify the permission of the GITHUB_TOKEN, we can make the change at the enterprise, organisation or repository level.

To do this go to settings, select Actions then General, here we will find the Workflow Permissions sections.

Modifying GITHUB_TOKEN permissions in a workflow

While changing the permission at the enterprise, organisation or repository level it will affect all workflows, to have more fine-grained control over the GITHUB_TOKEN, there is the option to set the permission during the workflow execution.

Using the permission block, we have the option to specify each scope and the permission level required.

name: sample

      - main

  actions: read|write|none
  checks: read|write|none
  contents: read|write|none
  deployments: read|write|none
  issues: read|write|none
  packages: read|write|none
  pull-requests: read|write|none
  repository-projects: read|write|none
  security-events: read|write|none
  statuses: read|write|none

    runs-on: ubuntu-latest

With this approach, once you use the permission block, any scopes not listed will have a default value of none. Permissions will not be inherited from the parent enterprise, organisation or repository.

[mailpoet_form id="1"]

Other Recent Blogs

Level 9, 360 Collins Street, 
Melbourne VIC 3000

Level 2, 24 Campbell St,
Sydney NSW 2000

200 Adelaide St,
Brisbane QLD 4000

191 St Georges Terrace
Perth WA 6000

Level 10, 41 Shortland Street

Part of

Arinco trades as Arinco (VIC) Pty Ltd and Arinco (NSW) Pty Ltd. © 2023 All Rights Reserved Arinco™ | Privacy Policy
Arinco acknowledges the Traditional Owners of the land on which our offices are situated, and pay our respects to their Elders past, present and emerging.

Get started on the right path to cloud success today. Our Crew are standing by to answer your questions and get you up and running.