GitHub Actions のポリシーとは?
Enterprise ポリシーは、Enterprise メンバーが GitHub Actions を使用するときに使用できるオプションを制御します。
Enterprise ポリシーを適用しない場合、Organization のオーナーと "Organization のアクション ポリシーの管理" アクセス許可を持つユーザーは、Organization の GitHub Actions を完全に制御できます。
ポリシーの適用
- GitHub の右上隅にあるプロフィール画像をクリックします。
- ご自分の環境に応じて、[Your enterprise] または [Your enterprises] をクリックし、表示するエンタープライズをクリックします。
- ページの上部にある [ Policies] をクリックします。
- [ Policies] で、[Actions] をクリックします。
- 各ポリシーを構成したら、[保存] をクリックします。
[ポリシー] ページの各セクションの詳細については、引き続きお読みください。
ポリシー
[ポリシー] セクションでは、次のオプションを使用して、GitHub Actions を使用できる Enterprise 内の Organization を制御できます。
- すべての Organization に対して GitHub Actions を有効にする
- 特定の Organization に対して GitHub Actions を有効にする
- すべての Organization に対して GitHub Actions を無効にする
次のオプションを使用して、パブリック アクションと再利用可能なワークフローの使用を制限することもできます。
- すべてのアクションと再利用可能なワークフローを許可する: 作成者や定義場所に関係なく、任意のアクションまたは再利用可能なワークフローを使用できます。
- Enterprise アクションと再利用可能なワークフローを許可する: Enterprise 内のリポジトリで定義されているアクションと再利用可能なワークフローのみを使用できます。 actions/checkoutアクションなど、GitHub によって作成されたアクションへのすべてのアクセスをブロックします。
- [Allow enterprise, and select non-enterprise, actions and reusable workflows](エンタープライズを許可し、非エンタープライズ、アクション、再利用可能なワークフローを選択する) : Enterprise 内のリポジトリで定義されているすべてのアクションまたは再利用可能なワークフローに加えて、指定した条件に一致するすべてのアクションまたは再利用可能なワークフローを使用できます。
- アクションを完全な長さのコミット SHA に固定する必要がある: すべてのアクションは、完全な長さのコミット SHA に固定して使う必要があります。 これには、Enterprise からのアクションと GitHub によって作成されたアクションが含まれます。 再利用可能なワークフローは、引き続きタグで参照できます。詳細については、「セキュリティで保護された使用に関するリファレンス」を参照してください。
[Allow enterprise, and select non-enterprise, actions and reusable workflows](エンタープライズを許可し、非エンタープライズ、アクション、再利用可能なワークフローを選択する)
このオプションを選択すると、Enterprise 内のアクションと再利用可能なワークフローが許可されます。他のアクションと再利用可能なワークフローの許可については次のオプションがあります。
- GitHub によって作成されたアクションを許可する: actionsOrganization とgithubOrganization にある GitHub によって作成されたすべてのアクションを許可します。
- 検証済みの作成者によるマーケットプレース アクションを許可する: 検証済み作成者が作成し、 というラベルが付いたすべての GitHub Marketplace アクションを許可します。
- 指定したアクションと再利用可能なワークフローを許可または禁止する: 指定したアクションと再利用可能なワークフローを許可します。 個々のアクションと再利用可能なワークフローまたは Organization とリポジトリ全体を指定できます。
アクションと再利用可能なワークフローを指定する場合は、次の構文を使用します。
- アクションまたは再利用可能なワークフローの特定のタグまたはコミット SHA へのアクセスを制限するには、ワークフローで使われているのと同じ構文を使って、アクションまたは再利用可能なワークフローを選びます。
- アクションの場合の構文は、OWNER/REPOSITORY@TAG-OR-SHAです。 たとえば、タグを選択するにはactions/javascript-action@v1.0.1を使用し、SHA を選択するにはactions/javascript-action@a824008085750b8e136effc585c3cd6082bd575fを使用します。
- 再利用可能なワークフローの場合の構文は、OWNER/REPOSITORY/PATH/FILENAME@TAG-OR-SHAです。 たとえば、octo-org/another-repo/.github/workflows/workflow.yml@v1のようにします。
 
- アクションの場合の構文は、
- パターンを指定するには、ワイルドカード文字 *を使用します。- space-orgで始まる Organization のすべてのアクションと再利用可能なワークフローを許可するには、- space-org*/*を使用します。
- octocat で始まるリポジトリのすべてのアクションと再利用可能なワークフローを許可するには、*/octocat**@*を使用します。
 
- 複数のパターンを指定するには、,を使ってパターンを区切ります。- octocatおよび- octokitorganization からのすべてのアクションと再利用可能なワークフローを許可するには、- octocat/*, octokit/*を使います。
 
- 特定のパターンを禁止するには、!プレフィックスを使います。- space-orgorganization からのすべてのアクション と再利用可能なワークフローを許可し、- space-org/actionなどの特定のアクションを禁止するには、- space-org/*, !space-org/action@*を使います。
- 既定では、一覧で指定したアクションと再利用可能なワークフローのみが許可されます。 すべてのアクションと再利用可能なワークフローを許可し、さらに特定のアクションを禁止するには、*, !space-org/action@*を使います。
 
ポリシーによって、ランナー ファイルシステム (uses: パスが ./で始まる場所) に対するローカル アクションへのアクセスが制限されることはありません。
ランナー
既定では、リポジトリの管理者アクセス権を持つすべてのユーザーが、リポジトリのセルフホステッド ランナーを追加できます。セルフホステッド ランナーには次のリスクがあります。
- セルフホステッド ランナーが一時的でクリーンな仮想マシンでホストされる保証はありません。 その結果、ワークフロー内の信頼できないコードによって侵害される可能性があります。
- リポジトリをフォークして pull request を開くことができるすべてのユーザーは、セルフホステッド ランナー環境を侵害し、シークレットと GITHUB_TOKENへのアクセス権を取得する可能性があります。これは、リポジトリへの書き込みアクセス権を持つ可能性があります。
[ランナー] セクションでは、リポジトリ レベルのセルフホステッド ランナーの使用を無効にすることで、これらのリスクを解決できます。
- すべての Organization に対して無効にする: リポジトリ レベルでのランナーの作成を禁止します。
- すべての Enterprise マネージド ユーザー (EMU) リポジトリで無効にする: マネージド ユーザー アカウント が所有するリポジトリのランナーの作成を禁止します。
メモ
リポジトリ レベルのセルフホステッド ランナーが作成できなくなっている場合でも、ワークフローは Enterprise レベルまたは Organization レベルのセルフホステッド ランナーにアクセスできます。
成果物とログの保持
既定では、ワークフローによって生成された成果物とログファイルは、90 日間保持されます。 保持期間は変更できます。
- パブリック リポジトリの場合、1 日から 90 日の期間に設定できます。
- プライベート リポジトリと内部リポジトリの場合、1 日から 400 日の期間に設定できます。
変更は、新しい成果物とログ ファイルにのみ適用されます。
外部コラボレーターからの pull request ワークフローをフォークする
すべてのユーザーが、パブリック リポジトリをフォークしてから、そのリポジトリのワークフローへの変更を提案する pull request を送信できます。 不正使用を防ぐために、一部の共同作成者によって作成された pull request に対してはワークフローが自動的に実行されることはありません。
実行前に承認が必要な pull request を構成できます。
警告
初めてのコントリビューターに対してのみ承認を要求する場合 (最初の 2 つの設定)、リポジトリにコミットまたは pull request をマージしたことのあるユーザーは承認を必要としません。 悪意のあるユーザーは、作成した pull request の一部として、または別のユーザーの pull request の一部として、単純な入力ミスや他の無害な変更をメンテナに受け入れさせることで、この要件を満たす可能性があります。
- GitHub を初めて使用する共同作成者の承認が必要です。 リポジトリにコミットしたことがなく、新しい GitHub アカウントを持つユーザーに対して承認が必要です。
- 初めての共同作成者の承認が必要です。 リポジトリにコミットしたことがないユーザーに対して承認が必要です。
- すべての外部コラボレーターの承認が必要です。 Organization のメンバーではないすべてのユーザーに対して承認が必要です。
メモ
 pull_request_target イベントによってトリガーされたベース ブランチのワークフローは、承認設定に関係なく、常に実行されます。
プライベート リポジトリ内の pull request ワークフローをフォークする
ユーザーがプライベート リポジトリと内部リポジトリの pull_request イベントに対してワークフローを実行する方法を制御できます。
- フォーク pull request からワークフローを実行します。 ユーザーはフォーク pull request からワークフローを実行できます。 既定では、ワークフローでは、シークレットへのアクセス権がない読み取り専用アクセス許可を持つ GITHUB_TOKENが使用されます。
- pull request からワークフローに書き込みトークンを送信します。 ワークフローでは、書き込みアクセス許可を持つ GITHUB_TOKENが使用されます。
- pull request からワークフローにシークレットを送信します。 pull request では、すべてのシークレットを使用できます。
- フォーク pull request ワークフローの承認が必要です。 書き込みアクセス許可のないコラボレーターからの pull request によるワークフローには、実行する前に書き込みアクセス許可を持つユーザーからの承認が必要になります。
エンタープライズでポリシーが有効になっている場合は、個々の組織またはリポジトリでポリシーを選択的に無効にすることができます。 エンタープライズでポリシーが無効になっている場合は、個々の組織またはリポジトリでそれを有効にすることはできません。
ワークフローのアクセス許可
[ワークフローのアクセス許可] セクションでは、GITHUB_TOKEN に付与する既定のアクセス許可を設定できます。
- 
読み取りと書き込みのアクセス許可: GITHUB_TOKENの既定のアクセス許可は、Enterprise または organization がいつ作成されたかによって異なります。- 2023 年 2 月 2 日以降に作成 – 既定値はすべてのスコープの読み取り専用アクセス権限です。
- 2023 年 2 月 2 日より前に作成 – 既定値はすべてのスコープの読み取りおよび書き込みアクセス権限です。
 
- 
リポジトリの内容とパッケージの読み取りアクセス許可: 既定では、 GITHUB_TOKENには、contentsとpackagesの範囲に対する読み取りアクセス権しかありません。 より制限の緩い設定は、個々の Organization またはリポジトリの既定値として選択できません。
リポジトリへの書き込みアクセス権があるすべてのユーザーは、ワークフロー ファイルの permissions キーを編集して、特定のワークフローについて GITHUB_TOKEN に付与されたアクセス許可を変更できます。
[GitHub Actions で pull request の作成と承認を許可する] は既定では無効になっています。 この設定を有効にした場合、 GITHUB_TOKEN は pull request を作成して承認できます。