1
0
mirror of synced 2026-02-01 03:01:50 -05:00

Issue #4283 rewording section

Issue #4283 
Line 80 has been changed from 

Users have specific permissions for each repository, so having the GITHUB_TOKEN for one repository grant access to another would impact the GitHub permission model if not implemented carefully.

to

Users have specific permissions for each repository, so allowing the GITHUB_TOKEN for one repository to grant access to another would impact the GitHub permission model if not implemented carefully.
This commit is contained in:
Rami Zackary Shamir
2021-03-05 07:30:44 -05:00
committed by GitHub
parent 6f7d96a5fe
commit b963d7c471

View File

@@ -77,7 +77,7 @@ This means that a compromise of a single action within a workflow can be very si
### Considering cross-repository access
{% data variables.product.prodname_actions %} is intentionally scoped for a single repository at a time. The `GITHUB_TOKEN` grants the same level of access as a write-access user, because any write-access user can access this token by creating or modifying workflow files. Users have specific permissions for each repository, so having the `GITHUB_TOKEN` for one repository grant access to another would impact the {% data variables.product.prodname_dotcom %} permission model if not implemented carefully. Similarly, caution must be taken when adding {% data variables.product.prodname_dotcom %} authentication tokens to a workflow, because this can also affect the {% data variables.product.prodname_dotcom %} permission model by inadvertently granting broad access to collaborators.
{% data variables.product.prodname_actions %} is intentionally scoped for a single repository at a time. The `GITHUB_TOKEN` grants the same level of access as a write-access user, because any write-access user can access this token by creating or modifying workflow files. Users have specific permissions for each repository, so allowing the `GITHUB_TOKEN` for one repository to grant access to another would impact the {% data variables.product.prodname_dotcom %} permission model if not implemented carefully. Similarly, caution must be taken when adding {% data variables.product.prodname_dotcom %} authentication tokens to a workflow, because this can also affect the {% data variables.product.prodname_dotcom %} permission model by inadvertently granting broad access to collaborators.
We have [a plan on the {% data variables.product.prodname_dotcom %} roadmap](https://github.com/github/roadmap/issues/74) to support a flow that allows cross-repository access within {% data variables.product.product_name %}, but this is not yet a supported feature. Currently, the only way to perform privileged cross-repository interactions is to place a {% data variables.product.prodname_dotcom %} authentication token or SSH key as a secret within the workflow. Because many authentication token types do not allow for granular access to specific resources, there is significant risk in using the wrong token type, as it can grant much broader access than intended.