組織のGitHub Actionsの無効化または制限

組織の GitHub Actions アクセス許可について

既定では、GitHub Actions の後の GitHub Actions ですべてのリポジトリと組織で有効になります。 GitHub Actions を無効にするか、または Enterprise のアクションと再生可能なワークフローに制限することができます。 GitHub Actionsの詳細については、「ワークフローの書き込み」を参照してください。

組織内のすべてのリポジトリに対して GitHub Actions を有効にすることができます。 GitHub Actions を有効にすると、ワークフローはリポジトリ内および他のパブリックまたは内部のリポジトリに配置されているアクションと再利用可能なワークフローを実行できます。 組織内のすべてのリポジトリの GitHub Actions を無効にすることができます。 GitHub Actionsを無効化すると、リポジトリでワークフローが実行されなくなります。

または、組織内のすべてのリポジトリで GitHub Actions を有効にすることもできますが、ワークフローが実行できるアクション および再利用可能なワークフロー は制限できます。

組織の GitHub Actions アクセス許可の管理

組織内のすべてのリポジトリに対して GitHub Actions を無効にすることも、特定のリポジトリのみを許可することもできます。 パブリック アクション再利用可能なワークフローの使用を制限して、ユーザーがローカル アクションと再利用可能なワークフローのみを使用できるようにenterpriseに存在するようにすることもできます。

1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

2. 組織をクリックして選択します。

3. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

   

4. 左側のサイドバーで、 [Actions] をクリックしてから [General] をクリックします。

5. [Policies] で、オプションを選択します。

   **[Allow enterprise, and select non-enterprise, actions and reusable workflows]\(エンタープライズを許可し、非エンタープライズ、アクション、再利用可能なワークフローを選択する\)**  を選択した場合、エンタープライズ内のアクションおよび再利用可能なワークフローが許可され、追加のオプションで、その他の特定のアクションや再利用可能なワークフローも許可されます。 詳細については、「[選択したアクションと再利用可能なワークフローの実行の許可](#allowing-select-actions-and-reusable-workflows-to-run)」を参照してください。
   

   エンタープライズからのみ再利用可能なワークフローとアクションを許可する場合、ポリシーにより GitHub で作成したアクションへのすべてのアクセスがブロックされます。 たとえば、actions/checkout アクションにはアクセスできません。

   [Require actions to be pinned to a full-length commit SHA] を有効にすると、すべてのアクションは、使用するには完全な長さのコミット SHA に固定する必要があります。 これには、Enterprise からのアクションと、GitHub によって作成されたアクションが含まれます。 再利用可能なワークフローは、引き続きタグで参照できます。詳細については、「セキュリティで保護された使用に関するリファレンス」を参照してください。

6. [保存] をクリックします。

選択したアクションと再利用可能なワークフローの実行の許可

[ [Allow enterprise, and select non-enterprise, actions and reusable workflows](エンタープライズを許可し、非エンタープライズ、アクション、再利用可能なワークフローを選択する) ] を選ぶと、ローカル アクションと再利用可能なワークフローが許可され、他の特定のアクションや再利用可能なワークフローを許可するための追加のオプションがあります。

•           **[GitHub によって作成されたアクションを許可する]:** GitHub によって作成されたすべてのアクションを、ワークフローで使用できるようにします。 GitHub によって作成されたアクションは、`actions` および `github` 組織にあります。 詳細については、「[`actions`](https://github.com/actions) および [`github`](https://github.com/github) 組織」を参照してください。
  

•           **[検証済みの作成者による Marketplace アクションを許可する]:**  検証済みの作成者が作成したすべての GitHub Marketplace アクションをワークフローで使用できるようにできます。 GitHubがアクションの作者をパートナーOrganizationとして検証すると、GitHub Marketplaceでアクションの隣に<svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-verified" aria-label="The verified badge" role="img"><path d="m9.585.52.929.68c.153.112.331.186.518.215l1.138.175a2.678 2.678 0 0 1 2.24 2.24l.174 1.139c.029.187.103.365.215.518l.68.928a2.677 2.677 0 0 1 0 3.17l-.68.928a1.174 1.174 0 0 0-.215.518l-.175 1.138a2.678 2.678 0 0 1-2.241 2.241l-1.138.175a1.17 1.17 0 0 0-.518.215l-.928.68a2.677 2.677 0 0 1-3.17 0l-.928-.68a1.174 1.174 0 0 0-.518-.215L3.83 14.41a2.678 2.678 0 0 1-2.24-2.24l-.175-1.138a1.17 1.17 0 0 0-.215-.518l-.68-.928a2.677 2.677 0 0 1 0-3.17l.68-.928c.112-.153.186-.331.215-.518l.175-1.14a2.678 2.678 0 0 1 2.24-2.24l1.139-.175c.187-.029.365-.103.518-.215l.928-.68a2.677 2.677 0 0 1 3.17 0ZM7.303 1.728l-.927.68a2.67 2.67 0 0 1-1.18.489l-1.137.174a1.179 1.179 0 0 0-.987.987l-.174 1.136a2.677 2.677 0 0 1-.489 1.18l-.68.928a1.18 1.18 0 0 0 0 1.394l.68.927c.256.348.424.753.489 1.18l.174 1.137c.078.509.478.909.987.987l1.136.174a2.67 2.67 0 0 1 1.18.489l.928.68c.414.305.979.305 1.394 0l.927-.68a2.67 2.67 0 0 1 1.18-.489l1.137-.174a1.18 1.18 0 0 0 .987-.987l.174-1.136a2.67 2.67 0 0 1 .489-1.18l.68-.928a1.176 1.176 0 0 0 0-1.394l-.68-.927a2.686 2.686 0 0 1-.489-1.18l-.174-1.137a1.179 1.179 0 0 0-.987-.987l-1.136-.174a2.677 2.677 0 0 1-1.18-.489l-.928-.68a1.176 1.176 0 0 0-1.394 0ZM11.28 6.78l-3.75 3.75a.75.75 0 0 1-1.06 0L4.72 8.78a.751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018L7 8.94l3.22-3.22a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042Z"></path></svg>バッジが表示されるようになります。
  

•           ** を許可するか  指定したアクション  および再利用可能なワークフローを拒否する:** 特定の組織やリポジトリでアクション  および再利用可能な  を使用すると、ワークフローを制限できます。 指定したアクションは、1000 を超えるアクションに設定できません。
  

  アクションまたは再利用可能なワークフローの特定のタグまたはコミット SHA へのアクセスを制限するには、ワークフローで使われているのと同じ構文を使って、アクションまたは再利用可能なワークフローを選びます。

  • アクションの場合の構文は、OWNER/REPOSITORY@TAG-OR-SHA です。 たとえば、タグを選択するには actions/javascript-action@v1.0.1 を使用し、SHA を選択するには actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f を使用します。 詳しくは、「ワークフローで事前に作成されたビルディング ブロックを使用する」をご覧ください。 (この行はGitHub Actionsのフロージャンプのバージョン管理で使用される特定のテンプレート構文を含みます。詳細な説明は技術ドキュメントを参照してください)
  • 再利用可能なワークフローの場合の構文は、OWNER/REPOSITORY/PATH/FILENAME@TAG-OR-SHA です。 たとえば、「 octo-org/another-repo/.github/workflows/workflow.yml@v1 」のように入力します。 詳しくは、「ワークフローを再利用する」をご覧ください。

  パターンのマッチには、ワイルドカード文字 * を使用できます。 たとえば、space-org で始まる Organization のすべてのアクションと再利用可能なワークフローを許可するには、space-org*/* と指定できます。 octocat で始まるリポジトリのすべてのアクションと再利用可能なワークフローを許可するには、*/octocat**@* を使用できます。 * ワイルドカードの使用の詳細については、「GitHub Actions　のワークフロー構文」を参照してください。

  , を使用して、パターンを区切ります。 たとえば、octocat と octokit 組織からすべてのアクション と 再利用可能なワークフロー を許可するには、octocat/*, octokit/* を指定します。

  ! プレフィックスを使用してパターンをブロックします。 たとえば、space-org 組織からのすべてのアクション と再利用可能なワークフロー を許可し、space-org/action などの具体的なアクションをブロックするには、space-org/*, !space-org/action@* を指定できます。 既定では、一覧で指定したアクションと再利用可能なワークフローのみが許可されます。 すべてのアクション と再利用可能なワークフロー を許可する一方で、特定のアクションを禁止するには、*, !space-org/action@* を指定できます。

この手順では、特定のアクション と再利用可能なワークフロー をリストに追加する方法を示します。

1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

2. 組織をクリックして選択します。

3. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

   

4. 左側のサイドバーで、 [Actions] をクリックしてから [General] をクリックします。

5. [ポリシー] で [Allow enterprise, and select non-enterprise, actions and reusable workflows](エンタープライズを許可し、非エンタープライズ、アクション、再利用可能なワークフローを選択する) を選択し、必要なアクション 再利用可能なワークフロー を一覧に追加します。

6. [保存] をクリックします。

セルフホステッド ランナーの使用を制限する

GitHub のセルフホステッド ランナーがエフェメラルでクリーンな仮想マシン上でホストされる保証はありません。 その結果、ワークフロー内の信頼できないコードによって侵害される可能性があります。

同様に、リポジトリをフォークしてプル リクエストを開くことができるユーザー (通常は、リポジトリへの読み取りアクセス権を持つユーザー) は、セルフホステッド ランナー環境を侵害する可能性があります。それには、シークレットへのアクセスや、リポジトリへの書き込みアクセス権を設定に応じて付与できる GITHUB_TOKEN の取得が含まれます。 ワークフローは、環境と必要なレビューを使用して環境シークレットへのアクセスを制御できますが、これらのワークフローは分離された環境では実行されず、セルフホストランナーで実行した場合でも同じリスクの影響を受けやすくなります。

このような理由やその他の理由から、ユーザーがリポジトリ レベルでセルフホステッド ランナーを作成できないようにすることができます。

リポジトリの使用を無効にしたとき、既にセルフホステッド ランナーがあった場合、これらは "無効" の状態で一覧表示され、新しいワークフロー ジョブを割り当てることができません。

1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

2. 組織をクリックして選択します。

3. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

   

4. 左側のサイドバーで、 [Actions] をクリックしてから [General] をクリックします。

5. "ランナー" で、ドロップダウン メニューを使って好みの設定を選びます。

   • すべてのリポジトリ - セルフホステッド ランナーは、Organization 内の任意のリポジトリで使えます。
   • 選択したリポジトリ - セルフホステッド ランナーは、選んだリポジトリでのみ使えます。
   • 無効 - セルフホステッド ランナーはリポジトリ レベルで作ることはできません。

6. 選択したリポジトリ を選択した場合は、次のようにします。

   1. をクリックします。
   2. セルフホステッド ランナーを許可するリポジトリのチェック ボックスをオンにします。
   3. リポジトリの選択 をクリックします。

標準のホストランナーの無効化

標準 GitHub ホステッド ランナーは、組織レベルで無効化できます。 この設定では、ランナー グループを介してランナーをターゲットにするワークフローが必要であり、一貫したアクセス制御とガバナンスを適用するのに役立ちます。

GitHub でホストされるランナーのジョブの同時実行制限については、アクションの制限 を参照してください。

1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

2. 組織をクリックして選択します。

3. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

   

4. 左側のサイドバーで、 [Actions] をクリックしてから [General] をクリックします。

5. [Standard hosted runners](標準のホストランナー) セクションまでスクロールし、[ Disable for all repositories](すべてのリポジトリに対して無効にする) をクリックします。

6. [保存] をクリックします。

パブリックフォークからのワークフローに対する必須の承認の設定

パブリックリポジトリをフォークし、リポジトリのGitHub Actionsワークフローへの変更を提案するPull Requestをサブミットすることは誰でもできます。 フォークからのワークフローはシークレットなどの機密データにアクセスできませんが、悪用目的で変更された場合、メンテナが迷惑を被る可能性があります。

これを防ぐために、外部コラボレータのパブリックリポジトリへのPull Requestではワークフローは自動的には動作せず、まず承認が必要になることがあります。 [Approval for running fork pull request workflows from contributors] 設定によっては、パブリック リポジトリへの pull request のワークフローは自動的に実行されず、次の場合に承認が必要になる可能性があります。

• pull request は、選択したポリシーに基づいて承認を必要とするユーザーによって作成される。
• pull request イベントは、選択したポリシーに基づいて承認を必要とするユーザーによってトリガーされる。

デフォルトでは、すべての初めてのコントリビューターは、ワークフローを実行するのに承認を必要とします。

pull_request_target イベントによってトリガーされるワークフローは、ベース ブランチのコンテキストで実行されます。 ベース ブランチは信頼済みと見なされるため、承認設定に関係なく、これらのイベントによってトリガーされるワークフローは常に実行されます。 pull_request_target イベントの詳細については、「ワークフローをトリガーするイベント」を参照してください。

Organizationのこの動作は、以下の手順で設定できます。 この設定を変更すると、Enterpriseレベルでの設定が上書きされます。

1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

2. 組織をクリックして選択します。

3. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

   

4. 左側のサイドバーで、 [Actions] をクリックしてから [General] をクリックします。

5. [Approval for running fork pull request workflows from contributors] で、pull request に対してワークフローを実行する前に承認を必要とするユーザーのサブセットを選びます。 pull request の作成者と、ワークフローをトリガーする pull request イベントのアクターの両方がチェックされて、承認が必要かどうかを判断されます。 承認が必要な場合、リポジトリへの書き込みアクセス権限を持つユーザーが、実行される pull request ワークフローを承認する必要があります。 「フォークからのワークフロー実行の承認」を参照してください。

   警告

   初めてのコントリビューターに対してのみ承認を要求する場合 (最初の 2 つの設定)、リポジトリにコミットまたは pull request をマージしたことのあるユーザーは承認を必要としません。 悪意のあるユーザーは、作成した pull request の一部として、または別のユーザーの pull request の一部として、単純な入力ミスや他の無害な変更をメンテナに受け入れさせることで、この要件を満たす可能性があります。

   • GitHub を初めて使用する共同作成者の承認が必要です。 GitHub の新規ユーザーと、このリポジトリにコミットまたは pull request をマージしたことがないユーザーについてのみ、ワークフローを実行するための承認が必要です。
   • 初めての共同作成者の承認が必要です。 このリポジトリにコミットまたは pull request をマージしたことがないユーザーについてのみ、ワークフローを実行するための承認が必要です。
   • [Require approval for all external contributors] このリポジトリのメンバーまたは所有者ではないすべてのユーザー、および organization のメンバーではないすべてのユーザーは、ワークフローを実行するために承認が必要です。

6. [保存] をクリックして設定を適用します。

このポリシーが適用されるワークフロー実行の承認の詳細については、「フォークからのワークフロー実行の承認」を参照してください。

プライベートリポジトリのフォークのワークフローを有効にする

プライベート リポジトリのフォークの利用に依存している場合、pull_request イベントの際にユーザーがどのようにワークフローを実行できるかを制御するポリシーを構成できます。 プライベート リポジトリと内部リポジトリでのみ使用でき、Enterprise、Organization、またはリポジトリに対してこれらのポリシー設定を構成できます。

企業に対してポリシーが無効になっている場合は、組織に対して有効にすることはできません。 組織でポリシーが無効になっている場合、リポジトリに対してポリシーを有効にすることはできません。 Organizationがポリシーを有効化していると、そのポリシーを個々のリポジトリで無効化することはできません。

• フォーク pull request からワークフローを実行する - 読み取り専用権限を持ち、シークレットへのアクセス権を持たない GITHUB_TOKEN を使用して、フォーク pull request からワークフローを実行できます。
• pull request からワークフローに書き込みトークンを送信する - フォークからの pull request で書き込み権限を持つ GITHUB_TOKEN を使用できます。
• pull request からワークフローにシークレットを送信する - すべてのシークレットを pull request で利用できるようにします。
• フォークの pull request ワークフローに対して承認を要求する - 書き込みアクセス許可のないコラボレーターからの pull request に対するワークフロー実行には、実行する前に書き込みアクセス許可を持つ誰かからの承認が必要になります。

Organization のプライベートフォークポリシーを設定する

1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

2. 組織をクリックして選択します。

3. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

   

4. 左側のサイドバーで、 [Actions] をクリックしてから [General] をクリックします。

5. [Fork pull request workflows](pull request ワークフローのフォーク) で、オプションを選択します。

6. [保存] をクリックして設定を適用します。

組織の GITHUB_TOKEN のアクセス許可の設定

GITHUB_TOKEN に付与される既定のアクセス許可を設定できます。 GITHUB_TOKEN の詳細については、「ワークフローでの認証に GITHUB_TOKEN を使用する」を参照してください。 デフォルトとして制限付きアクセス許可セットを選択するか、より幅広く許可をする設定を適用できます。

組織またはリポジトリの設定で、GITHUB_TOKEN の既定のアクセス許可を設定できます。 Organization の設定でデフォルトとして制限付きのオプションを選択した場合、そのオプションは Organization 内のリポジトリの設定でも選択され、制限の緩いオプションは無効化されます。 組織が GitHub Enterprise アカウントに属していて、エンタープライズ設定でより制限の厳しい既定値が選択されている場合、組織の設定で制限の厳しい既定値を選択することはできません。

リポジトリへの書き込みアクセス権を持っている人は誰でも、ワークフロー ファイルの permissions キーを編集して、GITHUB_TOKEN に付与されたアクセス許可を変更でき、必要に応じて追加または削除できます。 詳細については、permissions をご覧ください。

既定の GITHUB_TOKEN のアクセス許可の構成

既定では、新しい組織を作成すると、 設定はエンタープライズ設定で構成されているものから継承されます。

1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[Your profile] をクリックします。

   

2. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

3. 組織をクリックして選択します。

4. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

   

5. 左側のサイドバーで、 [Actions] をクリックしてから [General] をクリックします。

6. [Workflow permissions] で、GITHUB_TOKEN に対してすべてのアクセス許可での読み取りと書き込みのアクセスを許可するか (制限の緩い設定)、contents と packages アクセス許可での読み取りアクセスのみを許可するか (制限の厳しい設定) を選びます。

7. [保存] をクリックして設定を適用します。

GitHub Actionsがプル要求を作成または承認できないようにする

GitHub Actions ワークフローでの pull request の作成または承認を許可するか禁止するかを選択できます。

既定では、新しい organization を作成した場合、ワークフローでの pull request の作成または承認は許可されません。

1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[Your profile] をクリックします。

   

2. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

3. 組織をクリックして選択します。

4. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

   

5. 左側のサイドバーで、 [Actions] をクリックしてから [General] をクリックします。

6. ワークフローのアクセス許可で、"Allow GitHub Actions to create and approve pull requests" の設定を使用して、GITHUB_TOKEN がプルリクエストを作成および承認できるかどうかを設定します。

7. [保存] をクリックして設定を適用します。

組織 GitHub Actions キャッシュ ストレージの管理

組織の管理者は、 GitHub Actions キャッシュ ストレージを管理できます。

リポジトリ別 GitHub Actions キャッシュ ストレージの表示

Organization 内の各リポジトリについて、リポジトリが使用しているキャッシュ ストレージの量、アクティブなキャッシュの数、リポジトリがキャッシュ サイズの合計の上限に近いかどうかを確認できます。 キャッシュの使用と削除のプロセスについて詳しくは、「依存関係キャッシュのリファレンス」を参照してください。

1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[Your profile] をクリックします。

   

2. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

3. 組織をクリックして選択します。

4. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

   

5. 左側のサイドバーで、「 アクション」 をクリックし、「 キャッシュ」をクリックします。

6. GitHub Actions キャッシュに関する情報については、リポジトリの一覧を確認してください。 リポジトリ名をクリックすると、リポジトリのキャッシュの詳しい情報を表示できます。

組織の GitHub Actions キャッシュ設定を構成する

組織内のすべてのリポジトリに適用されるキャッシュリテンション期間とサイズの設定を構成できます。 この機能は選択式で、登録済みの支払い方法を持つユーザーが利用可能です。

組織がキャッシュ設定を構成した企業が所有している場合は、企業によって設定された最大値までの制限のみを構成できます。 組織が企業によって所有されていない (または企業がキャッシュ設定を構成していない) 場合は、グローバル最大値まで構成できます。

リポジトリ管理者は、リポジトリの制限を構成することを選択できますが、組織レベルで設定されている制限を超えることはできません。

1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[Your profile] をクリックします。

   

2. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

3. 組織をクリックして選択します。

4. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

   

5. 左側のサイドバーで、 [Actions] をクリックしてから [General] をクリックします。

6. [キャッシュ] セクションで、次の設定に対する変更を構成して保存します。

   • キャッシュリテンション期間: キャッシュを保持してから自動削除するまでの最大日数。 既定値は 7 日です。 最大 365 日 (または企業が設定した上限まで) を構成できます。 [ 保存] をクリックして、行った変更を適用します。
   • キャッシュ サイズの削除制限: リポジトリ内のすべてのキャッシュの最大合計サイズ。 既定値は 10 GB です。 リポジトリあたり最大 10,000 GB を構成できます (または、企業によって設定された上限まで)。 この制限を超えると、古いキャッシュが削除され、新しいキャッシュ用のスペースが作成されます。 [ 保存] をクリックして、行った変更を適用します。

キャッシュの削除の詳細については、「 依存関係キャッシュのリファレンス」を参照してください。