Permissions for the GITHUB_TOKEN
For information about the API endpoints GitHub Apps can access with each permission, see GitHub 앱에 필요한 권한.
When a workflow is triggered by the pull_request_target event, the GITHUB_TOKEN is granted read/write repository permission, even when it is triggered from a public fork. For more information, see 워크플로를 트리거하는 이벤트.
Dependabot 끌어오기 요청에 의해 트리거되는 워크플로 실행은 포크된 리포지토리에서 온 것처럼 실행되므로 읽기 전용 GITHUB_TOKEN을 사용합니다. 이러한 워크플로 실행은 비밀에 액세스할 수 없습니다. 워크플로의 안전한 유지를 위한 전략의 자세한 내용은 GitHub Actions에 대한 보안 강화을(를) 참조하세요.
The following table shows the permissions granted to the GITHUB_TOKEN by default. People with admin permissions to an enterprise, organization, or repository, can set the default permissions to be either permissive or restricted. For information on how to set the default permissions for the GITHUB_TOKEN for your enterprise, organization, or repository, see 엔터프라이즈에서 GitHub Actions에 대한 정책 적용, 조직의 GitHub Actions 사용 안 함 또는 제한, or 리포지토리에 대한 GitHub Actions 설정 관리.
| Scope | Default access (permissive) | Default access (restricted) | Maximum access for pull requests from public forked repositories |
|---|---|---|---|
| actions | read/write | none | read |
| attestations | read/write | none | read |
| checks | read/write | none | read |
| contents | read/write | read | read |
| deployments | read/write | none | read |
| discussions | read/write | none | read |
| id-token | none | none | none |
| issues | read/write | none | read |
| metadata | read | read | read |
| models | read | none | none |
| packages | read/write | read | read |
| pages | read/write | none | read |
| pull-requests | read/write | none | read |
| security-events | read/write | none | read |
| statuses | read/write | none | read |
How permissions are calculated for a workflow job
The permissions for the GITHUB_TOKEN are initially set to the default setting for the enterprise, organization, or repository. If the default is set to the restricted permissions at any of these levels then this will apply to the relevant repositories. For example, if you choose the restricted default at the organization level then all repositories in that organization will use the restricted permissions as the default. The permissions are then adjusted based on any configuration within the workflow file, first at the workflow level and then at the job level. Finally, if the workflow was triggered by a pull request from a forked repository, and the Send write tokens to workflows from pull requests setting is not selected, the permissions are adjusted to change any write permissions to read only.