The permissions for packages are either repository-scoped or user/organization-scoped.
Permissions for repository-scoped packages
A repository-scoped package inherits the permissions and visibility of the repository that owns the package. You can find a package scoped to a repository by going to the main page of the repository and clicking the Packages link to the right of the page.
The GitHub Packages registries below use repository-scoped permissions:
- Docker registry (
docker.pkg.github.com) - npm registry
- RubyGems registry
- Apache Maven registry
- NuGet registry
Granular permissions for user/organization-scoped packages
Packages with granular permissions are scoped to a personal user or organization account. You can change the access control and visibility of the package separately from a repository that is connected (or linked) to a package.
Currently, only the コンテナレジストリ offers granular permissions for your container image packages.
Visibility and access permissions for container images
コンテナイメージへの管理権限を持っているなら、そのコンテナイメージへのアクセス権限をプライベートもしくはパブリックに設定できます。 パブリックイメージは匿名でアクセスでき、認証や CLI 経由でサインインすることなくプルできます。
あなたが管理者であれば、Organization レベルおよびリポジトリレベルに設定した権限とは別に、コンテナイメージに対してアクセス権限を付与することもできます。
ユーザアカウントが所有し公開しているコンテナイメージには、任意のユーザにアクセスロールを付与できます。 Organization が所有し公開しているコンテナイメージには、Organization 内の任意の Team にアクセスロールを付与できます。
| 権限 | アクセス権の内容 |
|---|---|
| 読み取り | パッケージをダウンロードできます。 メタデータの読み取りができます。 |
| 書き込み | このパッケージをアップロードおよびダウンロードできます。 パッケージのメタデータの読み取りおよび書き込みができます。 |
| 管理 | このパッケージのアップロード、ダウンロード、削除、管理ができます。 パッケージのメタデータの読み取りおよび書き込みができます。 パッケージに権限を付与できます。 |
For more information, see "Configuring a package's access control and visibility."
About scopes and permissions for package registries
To use or manage a package hosted by a package registry, you must use a token with the appropriate scope, and your user account must have appropriate permissions.
For example:
- To download and install packages from a repository, your token must have the
read:packagesscope, and your user account must have read permission. - To delete a package on GitHub, your token must at least have the
delete:packagesandread:packagesscope. Thereposcope is also required for repo-scoped packages. For more information, see "Deleting and restoring a package."
| Scope | Description | Required permission |
|---|---|---|
read:packages | Download and install packages from GitHub Packages | read |
write:packages | Upload and publish packages to GitHub Packages | write |
delete:packages | Delete packages from GitHub Packages | admin |
repo | Upload and delete packages (along with write:packages, or delete:packages) | write or admin |
When you create a GitHub Actions workflow, you can use the GITHUB_TOKEN to publish and install packages in GitHub Packages without needing to store and manage a personal access token.
For more information, see:
- "Configuring a package’s access control and visibility"
- "Publishing and installing a package with GitHub Actions"
- "Creating a personal access token"
- "Available scopes"
Maintaining access to packages in GitHub Actions workflows
To ensure your workflows will maintain access to your packages, ensure that you're using the right access token in your workflow and that you've enabled GitHub Actions access to your package.
For more conceptual background on GitHub Actions or examples of using packages in workflows, see "Managing GitHub Packages using GitHub Actions workflows."
Access tokens
- To publish packages associated with the workflow repository, use
GITHUB_TOKEN. - To install packages associated with other private repositories that
GITHUB_TOKENcan't access, use a personal access token
For more information about GITHUB_TOKEN used in GitHub Actions workflows, see "Authentication in a workflow."
GitHub Actions access for container images
To ensure your workflows have access to your container image, you must enable GitHub Actions access to the repositories where your workflow is run. You can find this setting on your package's settings page. For more information, see "Ensuring workflow access to your package."