Skip to main content

パッケージのアクセス制御と可視性の設定

パッケージに読み取り、書き込み、管理アクセス権限があるユーザーと、GitHub 上のパッケージの可視性を選びます。

この機能を使用できるユーザーについて

GitHub Packagesは、GitHub Free、GitHub Pro、組織用GitHub Free、GitHub Team、GitHub Enterprise Cloud、GitHub Enterprise Server 3.0以降で利用できます。
GitHub Packagesは、レガシーのリポジトリごとのプランを使っているアカウントが所有しているプライベートリポジトリでは利用できません。 また、従来のリポジトリごとのプランを使用しているアカウントは、詳細なアクセス許可をサポートするレジストリにアクセスできません。これらのアカウントはリポジトリによって課金されるためです。Enterprise Managed Users には、アカウントの名前空間内でパッケージを発行するための個別のストレージ割り当てはありませんが、organizationの名前空間に発行できます。 Enterprise Managed Users の詳細については、「Enterprise Managed Users について」を参照してください。詳細なアクセス許可をサポートするレジストリの一覧については、「GitHub Packagesの権限について」を参照してください。 詳しくは、「GitHub のプラン」をご覧ください。

パッケージは、その可視性とアクセス許可をリポジトリから継承できますが、詳細なアクセス許可をサポートするレジストリの場合、リポジトリとは別にパッケージの可視性とアクセス許可を設定できます。

細かいアクセス許可をサポートするレジストリの一覧、パッケージ、PAT のパッケージ関連のスコープ、または GitHub Actions ワークフローのアクセス許可の管理については、「GitHub Packagesの権限について」を参照してください。

アクセス許可の継承について

詳細なアクセス許可をサポートするレジストリでは、パッケージのスコープが個人アカウントまたは Organization に指定されます。 これらのレジストリで、パッケージをリポジトリにリンクせずにパッケージを公開し、パッケージの設定でアクセス許可と可視性を設定することで、パッケージにアクセスできるユーザーを決定できます。

リポジトリにリンクされているパッケージを発行すると、既定で、パッケージはリンクされているリポジトリのアクセス許可を自動的に継承します (可視性はしません)。 たとえば、リンク先のリポジトリへの読み取りアクセス権を持つユーザーは、パッケージへの読み取りアクセス権も持つことになります。 パッケージがアクセス許可を自動的に継承する場合、リンク先のリポジトリ内の GitHub Actions ワークフローもパッケージへのアクセス権を自動的に取得します。

パッケージがリンク先のリポジトリのアクセス許可を自動的に継承するのは、org.opencontainers.image.source Docker ラベルをコンテナー イメージに追加するなどして、パッケージを公開する前にリポジトリをパッケージにリンクした場合のみです。 公開されたパッケージをパッケージの設定ページからリポジトリに接続した場合は、パッケージは既存のアクセス許可を保持し、このオプションを明示的に選ばない限り、リポジトリのアクセス許可を継承しません。 さらに、Organization は、スコープが Organization に指定されている新しいパッケージすべてについてアクセス許可の自動継承を無効にできます。 詳細については、後述の「Organization 内のアクセス許可の自動継承を無効にする」を参照してください。

パッケージがリポジトリからアクセス許可を継承する場合、パッケージへのアクセス権を付与または削除するには、リンク先のリポジトリのアクセス許可設定を構成する必要があります。 パッケージにリンクされているリポジトリとは別のアクセス設定をパッケージに設定する場合は、パッケージから継承されるアクセス許可を削除する必要があります。 詳細については、後述の「パッケージがリポジトリからアクセス許可を継承するかどうかを選ぶ」を参照してください。

リポジトリのスコープが指定されたアクセス許可のみをサポートするレジストリにパッケージを公開すると、パッケージはリポジトリに常にリンクされ、リンク先のリポジトリのアクセス許可を常に継承します。

パッケージの可視性とアクセス許可の設定について

パッケージが詳細なアクセス許可をサポートするレジストリに属している場合、パッケージに対する管理者アクセス許可を持つすべてのユーザーは、パッケージをプライベートまたは公開用に設定でき、組織レベルとリポジトリ レベルで設定されたアクセス許可とは別のアクセス許可をパッケージに付与できます。 詳細なアクセス許可をサポートするレジストリの一覧については、「GitHub Packagesの権限について」をご覧ください。

ほとんどのレジストリでは、パッケージをプルするには、パッケージが公開用かプライベートかに関係なく、personal access token または GITHUB_TOKEN で認証する必要があります。 ただし、Container registry では、公開用 パッケージは匿名アクセスを許可し、認証や CLI 経由でのサインインなしでプルできます。

Note

リポジトリにリンクされたパッケージを公開する場合、パッケージは既定でリンクされたリポジトリからアクセス許可を継承します。 パッケージの詳細なアクセス許可の設定にアクセスするには、パッケージの継承されたアクセス許可を削除する必要があります。 Organization の所有者は、自分の Organization を対象とするすべての新しいパッケージで、アクセス許可の自動継承を無効にできます。 詳細については、「パッケージのアクセス制御と可視性の設定」および「パッケージのアクセス制御と可視性の設定」を参照してください。

パッケージを発行すると、パッケージへの管理者アクセス許可を自動的に取得します。 Organization にパッケージを発行する場合、Organization 内の owner ロールを持つすべてのユーザーも、そのパッケージへの管理者アクセス許可を取得します。

個人アカウントにスコープ指定されたパッケージの場合は、任意のユーザーにアクセス ロールを付与できます。 Organization にスコープ指定されたパッケージの場合は、Organization 内の任意のユーザーまたは team にアクセス ロールを付与できます。

GitHub Actions ワークフローを使ってパッケージを管理している場合は、パッケージの設定の [Actions のアクセスの管理] の [リポジトリの追加] ボタンを使用して で、ワークフローが格納されているリポジトリへのアクセス ロールを付与できます。 詳しくは、「パッケージのアクセス制御と可視性の設定」を参照してください。

権限アクセスの説明
Readパッケージをダウンロードできます。
パッケージのメタデータを読み取ることができます。
Writeこのパッケージをアップロードおよびダウンロードできます。
パッケージ メタデータの読み取りと書き込みを行うことができます。
管理者このパッケージのアップロード、ダウンロード、削除、管理ができます。
パッケージ メタデータの読み取りと書き込みを行うことができます。
パッケージのアクセス許可を付与できます。

Note

REST API を使ってパッケージを削除および復元する GitHub Actions ワークフローの機能は、現在 パブリック プレビュー 段階であり、変更される可能性があります。

個人アカウントにパッケージへのアクセス権限を構成する

個人アカウントにスコープが指定されているパッケージに対する管理者権限をお持ちの場合は、他のユーザーに読み取り、書き込み、管理者ロールを割り当てることができます。 これらのアクセス許可ロールの詳細については、「アクセス許可の継承について」を参照してください。

パッケージがプライベートまたは内部向けで、Organization にスコープが指定されている場合は、他の Organization メンバーや Team にのみアクセス権を与えることができます。

  1. 検索したら、管理するパッケージの名前をクリックします。

  2. パッケージのランディング ページの右側にある [ パッケージ設定] をクリックします。

    パッケージのランディング ページのスクリーンショット。 右下隅の [パッケージ設定] がオレンジ色の枠線で強調表示されています。

  3. [アクセスの管理] または [継承されたアクセス] で、 [チームまたはユーザーの招待] をクリックして、アクセス権を付与するユーザーの名前、ユーザー名、またはメール アドレスを入力します。 スコープが個人アカウントに指定されているパッケージへのアクセス権は、チームに付与することができません。

  4. ユーザー名またはチーム名の隣にある [ロール] ドロップダウン メニューを使って、目的のアクセス許可レベルを選びます。

選択したユーザには自動的にアクセス権限が与えられ、招待を承諾する必要はありません。

Organization のパッケージに対するアクセスの構成

Organization にスコープが指定されているパッケージに対して管理者権限がある場合には、他のユーザーや Team に読み取り、書き込み、管理者ロールを割り当てることができます。 これらのアクセス許可ロールの詳細については、「アクセス許可の継承について」を参照してください。

パッケージがプライベートまたは内部向けで、Organization にスコープが指定されている場合は、他の Organization メンバーや Team にのみアクセス権を与えることができます。

  1. GitHubで、Organizationのメインページにアクセスしてください。

  2. 組織名の下にある [パッケージ] タブをクリックします。

    @octo-org のプロファイル ページのスクリーンショット。 [パッケージ] タブがオレンジ色の枠線で強調表示されています。

  3. 検索したら、管理するパッケージの名前をクリックします。

  4. パッケージのランディング ページの右側にある [ パッケージ設定] をクリックします。

    パッケージのランディング ページのスクリーンショット。 右下隅の [パッケージ設定] がオレンジ色の枠線で強調表示されています。

  5. [アクセスの管理] または [継承されたアクセス] で、 [チームまたはユーザーの招待] をクリックして、アクセス権を付与するユーザーの名前、ユーザー名、またはメール アドレスを入力します。 また、Organization のチーム名を入力して、すべてのチーム メンバーにアクセス権を付与することもできます。

  6. ユーザー名またはチーム名の隣にある [ロール] ドロップダウン メニューを使って、目的のアクセス許可レベルを選びます。

選択したユーザや Team には自動的にアクセス権限が与えられ、招待を承諾する必要はありません。

パッケージがリポジトリからアクセス許可を継承するかどうかを選ぶ

既定では、リポジトリにリンクされているパッケージを公開する場合、パッケージはリンク先のリポジトリのアクセス許可を継承します。 パッケージへのアクセスを管理するプロセスが簡素化されるため、パッケージがリポジトリからアクセス許可を継承できるようにすることをお勧めします。

パッケージがリポジトリからアクセス許可を継承する場合、パッケージへのアクセス権を付与または削除するには、リンク先のリポジトリのアクセス許可を構成する必要があります。

リンク先のリポジトリとは別に、詳細レベルでパッケージのアクセス設定を構成する場合は、継承されるアクセス許可をパッケージから削除する必要があります。

Note

パッケージがアクセス許可を取得する方法を変更すると、パッケージの既存のアクセス許可はすべて上書きされます。

スコープが個人アカウントに指定されているパッケージの継承設定を選ぶ

  1. GitHub で、個人アカウントのメイン ページに移動します。

  2. GitHub の右上隅で、プロフィール写真をクリックし、[あなたのプロフィール] をクリックします。

    @octocat のプロファイル写真の下にあるドロップダウン メニューのスクリーンショット。 [自分のプロファイル] が濃いオレンジ色の枠線で囲まれています。

  3. プロファイル ページのヘッダーで、 [パッケージ] タブをクリックします。

  4. 検索したら、管理するパッケージの名前をクリックします。

  5. パッケージのランディング ページの右側にある [ パッケージ設定] をクリックします。

    パッケージのランディング ページのスクリーンショット。 右下隅の [パッケージ設定] がオレンジ色の枠線で強調表示されています。

  6. パッケージでリンクされたリポジトリからアクセス許可を継承するかどうかを選ぶには、[アクセスの管理] または [継承されたアクセス] で、 [リポジトリからアクセスを継承する (推奨)] をオンまたはオフにします。

    Note

    このセクションの名前は、パッケージがリポジトリからアクセス許可を既に継承しているかどうかによって変わります。

スコープが Organization に指定されているパッケージの継承設定を選ぶ

Tip

Organization 所有者である場合は、スコープが organization に指定されている新しいパッケージはすべて、リンク先のリポジトリからアクセス許可を自動的に継承しないようにできます。 詳細については、後述の「Organization 内のアクセス許可の自動継承を無効にする」を参照してください。

  1. GitHubで、Organizationのメインページにアクセスしてください。

  2. 組織名の下にある [パッケージ] タブをクリックします。

    @octo-org のプロファイル ページのスクリーンショット。 [パッケージ] タブがオレンジ色の枠線で強調表示されています。

  3. 検索したら、管理するパッケージの名前をクリックします。

  4. パッケージのランディング ページの右側にある [ パッケージ設定] をクリックします。

    パッケージのランディング ページのスクリーンショット。 右下隅の [パッケージ設定] がオレンジ色の枠線で強調表示されています。

  5. パッケージでリンクされたリポジトリからアクセス許可を継承するかどうかを選ぶには、[アクセスの管理] または [継承されたアクセス] で、 [リポジトリからアクセスを継承する (推奨)] をオンまたはオフにします。

    Note

    このセクションの名前は、パッケージがリポジトリからアクセス許可を既に継承しているかどうかによって変わります。

Organization 内のアクセス許可の自動継承を無効にする

既定では、リポジトリにリンクされているパッケージを公開すると、パッケージは、リンク先のリポジトリのアクセス許可を自動的に継承します。 Organization の所有者として、スコープが Organization に指定されているすべてのパッケージの自動継承を無効にすることができます。

アクセス許可の自動継承を無効にすると、スコープが Organization に指定されている新しいパッケージは、リンク先のリポジトリのアクセス許可を自動的に継承しません。 ただし、Organization のパッケージに対する管理者権限を持っているユーザーであれば、そのパッケージのアクセス許可の継承を有効または無効にすることができます。

  1. GitHub の右上隅で、プロフィール写真を選択し、 あなたの組織をクリックします。
  2. 組織の隣の [設定] をクリックします。
  3. サイドバーの [コード、計画、自動化] セクションで、 パッケージをクリックします。
  4. [既定のパッケージ設定] で、 [ソース リポジトリからアクセスを継承する] の選択を解除します。
  5. [保存] をクリックします。

パッケージへのワークフローのアクセスの確保

個人アカウントまたは Organization にスコープが指定されているパッケージの場合、GitHub Actions ワークフローからパッケージへのアクセスを確保するためには、ワークフローが保存されているリポジトリに対する明示的なアクセスを与えなければなりません。

指定するリポジトリは、パッケージのソースコードが保存されているリポジトリである必要はありません。 パッケージに対して複数のリポジトリワークフローにアクセスを与えることができます。

リポジトリにリンクされているパッケージを公開した場合、Organization によってアクセス許可の自動継承が無効にされていない限り、リンク先のリポジトリ内の GitHub Actions ワークフローで、パッケージへのアクセスが自動的に取得されます。 詳細については、前述の「アクセス許可と可視性の継承について」を参照してください。

Note

  • パッケージをリポジトリ パッケージの設定の [Actions のアクセスの管理] の [リポジトリの追加] ボタンを使用して と同期することは、パッケージをリポジトリに接続することとは異なります。 リポジトリのパッケージへのリンクの詳細については、「リポジトリのパッケージへの接続」を参照してください。
  • permissions キーと packages スコープを使用して、ワークフロー ジョブに対するアクセス許可を制限することができます。 詳しくは、「GITHUB_TOKEN のアクセス許可の制御」をご覧ください。
  • パブリック リポジトリにプライベート パッケージへのアクセスを許可した場合、リポジトリのフォークがプライベート パッケージにアクセスできるようになります。

個人アカウントにスコープが指定されているパッケージに対する GitHub Actions アクセス

  1. 検索したら、管理するパッケージの名前をクリックします。

  2. パッケージのランディング ページの右側にある [ パッケージ設定] をクリックします。

    パッケージのランディング ページのスクリーンショット。 右下隅の [パッケージ設定] がオレンジ色の枠線で強調表示されています。

  3. ワークフローがパッケージに確実にアクセスできるようにするには、ワークフローが保存されるリポジトリを追加する必要があります。 [Actions のアクセスの管理] で、 [リポジトリの追加] をクリックして、追加するリポジトリを検索します。

    パッケージ設定ページの [Actions のアクセスの管理] セクションのスクリーンショット。 [リポジトリの追加] ボタンがオレンジ色の枠線で強調されています。

  4. [ロール] ドロップダウン メニューで、パッケージに対するリポジトリの既定のアクセス レベルを選びます。 を使用する

パッケージへのアクセスをさらにカスタマイズするには、「個人アカウントにパッケージへのアクセス権限を設定する」を参照してください。

Organization にスコープが指定されているパッケージに対する GitHub Actions アクセス

  1. GitHubで、Organizationのメインページにアクセスしてください。

  2. 組織名の下にある [パッケージ] タブをクリックします。

    @octo-org のプロファイル ページのスクリーンショット。 [パッケージ] タブがオレンジ色の枠線で強調表示されています。

  3. 検索したら、管理するパッケージの名前をクリックします。

  4. パッケージのランディング ページの右側にある [ パッケージ設定] をクリックします。

    パッケージのランディング ページのスクリーンショット。 右下隅の [パッケージ設定] がオレンジ色の枠線で強調表示されています。

  5. [Actions のアクセスの管理] で、 [リポジトリの追加] をクリックして、追加するリポジトリを検索します。

    パッケージ設定ページの [Actions のアクセスの管理] セクションのスクリーンショット。 [リポジトリの追加] ボタンがオレンジ色の枠線で強調されています。

  6. [ロール] ドロップダウン メニューで、パッケージに対するリポジトリの既定のアクセス レベルを選びます。 を使用する

コンテナー イメージへのアクセスをさらにカスタマイズするには、「Organization にパッケージへのアクセス権限を設定する」を参照してください。

パッケージへの GitHub Codespaces アクセスの確保

既定では、 [アクセスの継承] オプションが選択された同じリポジトリ内で公開されたパッケージなど、詳細なアクセス許可をサポートするレジストリ内の特定のパッケージに codespace からシームレスにアクセスできます。 詳細なアクセス許可とシームレスな GitHub Codespaces のアクセスをサポートする GitHub Packages レジストリのリストについては、「GitHub Packagesの権限について」を参照してください。

あるいは、codespaceがパッケージに確実にアクセスできるようにするには、codespaceが起動されたリポジトリへのアクセスを許可しなければなりません。

指定するリポジトリは、パッケージのソースコードが保存されているリポジトリである必要はありません。 codespeceには、複数のリポジトリでパッケージへのアクセスを付与できます。

リポジトリ内でcodespaceと共有したいパッケージを選択したら、そのリポジトリへのアクセスを付与できます。

  1. 検索したら、管理するパッケージの名前をクリックします。

  2. パッケージのランディング ページの右側にある [ パッケージ設定] をクリックします。

    パッケージのランディング ページのスクリーンショット。 右下隅の [パッケージ設定] がオレンジ色の枠線で強調表示されています。

  3. [Codespaces アクセスの管理] で、 [リポジトリの追加] をクリックします。

    パッケージ設定ページの [Codespaces アクセスの管理] セクションのスクリーンショット。 [リポジトリの追加] ボタンがオレンジ色の枠線で強調表示されている。

  4. 追加したいリポジトリを検索してください。

  5. アクセスを許可したい追加のリポジトリについて、繰り返してください。

  6. リポジトリの codespace がイメージへのアクセスを必要としなくなった場合は、アクセスを削除できます。 をクリックします。

    パッケージ設定ページの [Codespaces アクセスの管理] セクションのスクリーンショット。 ごみ箱アイコンがオレンジ色の枠線で強調表示されている。

個人アカウントにパッケージの可視性を設定する

個人アカウントにスコープが指定されているパッケージを初めて公開する場合は、既定の可視性はプライベートであり、パッケージを表示できるのは自分だけです。 アクセス設定を変更すると、プライベートやパブリックのパッケージのアクセス権限を変更できます。

  1. 検索したら、管理するパッケージの名前をクリックします。

  2. パッケージのランディング ページの右側にある [ パッケージ設定] をクリックします。

    パッケージのランディング ページのスクリーンショット。 右下隅の [パッケージ設定] がオレンジ色の枠線で強調表示されています。

  3. ページ下部の [危険なゾーン] の下にある [可視性の変更] をクリックします。

  4. 可視性設定を選びます。

    • パッケージをすべてのユーザーに表示するには、 [パブリック] を選びます。

      Warning

      公開したパッケージを非公開に戻すことはできません。

    • カスタム選択したユーザーにパッケージを表示するには、 [プライベート] を選びます。

  5. 確認のため、パッケージ名を入力し、 [影響を理解したうえで、パッケージの可視性を変更します] をクリックします。

Organization メンバーのためのパッケージ作成の可視性

詳細なアクセス許可をサポートするレジストリの場合は、Organization のメンバーが既定で公開できるパッケージの可視性を選ぶことができます。 これらのレジストリの一覧については、「GitHub Packagesの権限について」を参照してください。

  1. GitHub の右上隅で、プロフィール写真を選択し、 あなたの組織をクリックします。
  2. 組織の隣の [設定] をクリックします。
  3. 左側の [パッケージ] をクリックします。
  4. [パッケージの作成] で、パブリック、プライベート、または内部のパッケージの作成を有効にするかどうかを選びます。
    • Organization のメンバーがパブリックパッケージを作成できるようにするには、 [パブリック] をクリックします。
    • Organization のメンバーが他の Organization のメンバーにのみ表示されるプライベート コンテナー イメージを作成できるようにするには、 [プライベート] をクリックします。 プライベート パッケージの可視性については、さらに細かくカスタマイズできます。
    • Organization のメンバーがすべての Organization のメンバーに表示される内部パッケージを作成できるようにするには、 [内部] をクリックします。 Enterprise にその Organization が所属している場合、パッケージは Enterprise のすべてのメンバーに見えるようになります。

Organization のパッケージの可視性を構成する

パッケージを最初に公開する際のデフォルトの可視性はプライベートで、パッケージを表示できるのは公開したユーザだけです。 アクセス設定を使用して、パッケージのさまざまなアクセスロールをユーザーや Team に与えることができます。 いったんパッケージをパブリックに設定すると、そのパッケージをプライベートに戻すことはできません。

  1. GitHubで、Organizationのメインページにアクセスしてください。

  2. 組織名の下にある [パッケージ] タブをクリックします。

    @octo-org のプロファイル ページのスクリーンショット。 [パッケージ] タブがオレンジ色の枠線で強調表示されています。

  3. 検索したら、管理するパッケージの名前をクリックします。

  4. パッケージのランディング ページの右側にある [ パッケージ設定] をクリックします。

    パッケージのランディング ページのスクリーンショット。 右下隅の [パッケージ設定] がオレンジ色の枠線で強調表示されています。

  5. ページ下部の [危険ゾーン] の下にある [可視性の変更] をクリックし、可視性設定を選びます。

    • パッケージをすべてのユーザーに表示するには、 [パブリック] をクリックします。

      Warning

      公開したパッケージを非公開に戻すことはできません。

    • Organization のカスタム選択したユーザーにパッケージを表示するには、 [プライベート] をクリックします。

    • パッケージを Organization のすべてのメンバーに表示するには、 [内部] をクリックします。 Organization が Enterprise に属している場合、パッケージは Enterprise のすべてのメンバーに表示されます。