企業でGitHub Actionsのポリシーを適用する

GitHub Actionsのポリシーとは

エンタープライズ ポリシーは、エンタープライズ メンバーが GitHub Actionsを使用するときに使用できるオプションを制御します。

エンタープライズ ポリシーを適用しない場合は、組織の所有者 と「組織の Actions ポリシーの管理」権限 を持つユーザーが、それぞれの組織の GitHub Actions を完全に制御できます。

ポリシーの適用

1. 企業ページに移動してください。 たとえば、GitHub.com の [Enterprise] ページから。
2. ページの上部にある [ポリシーの] をクリックします。
3. [ Policies] で、[Actions] をクリックします。
4. 各ポリシーを構成したら、[保存] をクリックします。

[ポリシー] ページの各セクションの詳細については、引き続きお読みください。

ポリシー

[ポリシー] セクションでは、次のオプションを使用して、 GitHub Actionsを使用できる企業内の組織を制御できます。

• すべての組織の GitHub Actions を有効にする
• 特定の組織の GitHub Actions を有効にする
• すべての組織の GitHub Actions を無効にする

パブリック アクション および再利用可能なワークフローへのアクセスの制御

多くの場合、企業は、サプライ チェーン ガバナンスの一環として、十分にテストされたパブリック アクションのグループ 再利用可能なワークフロー のみにアクセスを制限したいと考えています。 GitHubで使用できるポリシーを使用すると、code scanningおよびGitHub Code Qualityで使用される動的ワークフローをブロックすることなく、アクセスを制御できます。

次のオプションを使用して、 code scanning と GitHub Code Qualityの例外や追加の構成を定義せずに、厳密な制御を適用できます。

• すべてのアクション および再利用可能なワークフローを許可する: アクション または再利用可能なワークフロー は、作成者や定義場所に関係なく使用できます。
• エンタープライズ アクション および再利用可能なワークフローを許可する: エンタープライズ内のリポジトリで定義されているアクション と再利用可能なワークフロー のみを使用できます。

GitHub アクションなど、actions/checkoutによって作成されたアクションへのすべてのアクセスをブロックします。

• [Allow enterprise, and select non-enterprise, actions and reusable workflows](エンタープライズを許可し、非エンタープライズ、アクション、再利用可能なワークフローを選択する) : エンタープライズ内のリポジトリで定義されているアクション または再利用可能なワークフロー 、指定した条件に一致するアクション または再利用可能なワークフロー を使用できます。
• アクションを完全な長さのコミット SHA に固定する必要がある: すべてのアクションは、完全な長さのコミット SHA に固定して使う必要があります。 これには、エンタープライズからのアクションと、 GitHubによって作成されたアクションが含まれます。 再利用可能なワークフローは、タグによって引き続き参照できます。 詳細については、「セキュリティで保護された使用に関するリファレンス」を参照してください。

[Allow enterprise, and select non-enterprise, actions and reusable workflows](エンタープライズを許可し、非エンタープライズ、アクション、再利用可能なワークフローを選択する)

このオプションを選択すると、企業内 アクションと再利用可能なワークフロー が許可され、他のアクション 再利用可能なワークフローを許可するための次のオプションがあります。

• **GitHubによって作成されたアクションを許可する:**GitHubおよびactions組織にある、によって作成されたすべてのアクションを許可します。
• **検証済みの作成者による Marketplace アクションを許可する:**GitHub Marketplaceでラベル付けされた、検証済みの作成者によって作成されたすべてのアクションを許可します。
• 指定したアクションおよび再利用可能なワークフローを許可またはブロック: 指定したアクションおよび再利用可能なワークフローを許可します。 個々のアクション 再利用可能なワークフロー 組織全体およびリポジトリを指定できます。

アクション 再利用可能なワークフローを指定する場合次の構文を使用します。

• 特定のタグへのアクセスを制限したり、アクション または再利用可能なワークフローの 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を許可するには、space-org*/*を使用します。
  • octocat で始まるリポジトリ内のすべてのアクション および再利用可能なワークフロー を許可するには、 */octocat**@*を使用します。
• 複数のパターンを指定するには、, を使ってパターンを区切ります。
  • および組織のすべてのアクションoctocat再利用可能なワークフローoctokitを許可するには、octocat/*, octokit/*を使用します。
• 特定のパターンを禁止するには、! プレフィックスを使います。
  • 組織のすべてのアクションと再利用可能なワークフローspace-orgを許可しつつ、space-org/action のような特定のアクションをブロックするには、space-org/*, !space-org/action@* を使用します。
  • 既定では、一覧で指定されたアクション および再利用可能なワークフロー のみが許可されます。 すべてのアクションと再利用可能なワークフローを許可しつつ、特定のアクションをブロックするには、*, !space-org/action@*を使用します。

ポリシーによって、ランナー ファイルシステム (uses: パスが ./で始まる場所) に対するローカル アクションへのアクセスが制限されることはありません。

ランナー

既定では、リポジトリの管理者アクセス権を持つすべてのユーザーが、リポジトリのセルフホステッド ランナーを追加できます。セルフホステッド ランナーには次のリスクがあります。

• セルフホステッド ランナーが一時的でクリーンな仮想マシンでホストされる保証はありません。 その結果、ワークフロー内の信頼できないコードによって侵害される可能性があります。
• リポジトリをフォークして pull request を開くことができるすべてのユーザーは、セルフホステッド ランナー環境を侵害し、シークレットと GITHUB_TOKEN へのアクセス権を取得する可能性があります。これは、リポジトリへの書き込みアクセス権を持つ可能性があります。

[ランナー] セクションでは、リポジトリ レベルのセルフホステッド ランナーの使用を無効にすることで、これらのリスクを解決できます。

• すべての Organization に対して無効にする: リポジトリ レベルでのランナーの作成を禁止します。
• **すべての Enterprise Managed User (EMU) リポジトリで無効にします。**マネージド ユーザー アカウントが所有するリポジトリのランナーの作成を禁止します。

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

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

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

1. 企業ページに移動してください。 たとえば、GitHub.com の [Enterprise] ページから。
2. ページの上部にある [ポリシーの] をクリックします。
3. [ Policies] で、[Actions] をクリックします。
4. 「Standard hosted runners」セクションまでスクロールし、すべての組織で無効にする をクリックします。
5. 保存 をクリックします。

カスタム イメージ

[カスタム イメージ] セクションでは、次のアクセス ポリシーを使用して、社内のどの組織でカスタム イメージの作成と管理を許可するかを制御できます。

• すべての組織に対して有効にする: 今後作成されるすべての組織を含め、すべての組織でカスタム イメージを使用または作成できます。
• 特定の組織に対して有効にする: カスタム イメージを使用または作成できるのは、選択した組織だけです。
• すべての組織に対して無効にする: カスタム イメージを使用または作成する組織はありません。

カスタム イメージの保持ポリシー

カスタム イメージ バージョンを保持する期間と非アクティブになるタイミングを定義できます。

• イメージあたりの最大バージョン数: 各イメージの保持バージョン数を制限します。 この制限を超えると、最も古い未使用のイメージ バージョンが自動的に削除されます。
  • 既定値: 20 バージョン
  • 構成可能な範囲: 1 ~ 100 バージョン
• 未使用のバージョンリテンション期間: 指定した日数だけ使用されていないイメージ バージョンを削除します。 ランナー プールに割り当てられているが、アクティブに使用されていないイメージ バージョンも未使用と見なされます。
  • デフォルト値: 30 日。
  • 構成可能な範囲: 1 ~ 90 日
• 最大バージョンの有効期間: 指定した日数より前に作成されたイメージ バージョンを無効にします。 ポリシーの制限が引き上げられるまで、ランナーは無効なイメージ バージョンを使用できません。
  • 既定値: 60 日
  • 構成可能な範囲: 7 ~ 90 日

Artifact とログの保持

既定では、ワークフローによって生成された成果物とログファイルは、90 日間保持されます。 保持期間は変更できます。

• パブリック リポジトリの場合、1 日から 90 日の期間に設定できます。
• プライベート リポジトリと内部リポジトリの場合、1 日から 400 日の期間に設定できます。

変更は、新しい成果物とログ ファイルにのみ適用されます。

キャッシュの設定

企業全体に適用される最大キャッシュリテンション期間とサイズ制限を構成できます。 プランに含まれる 10 GB を超えて "キャッシュ サイズの削除制限" を増やすと、キャッシュされたエントリの追加ストレージに対して課金されます。

既定では:

• キャッシュは、自動削除の前に 7 日間保持されます。
• キャッシュ ストレージの合計制限は、リポジトリあたり 10 GB です。

これらの設定をカスタマイズして、企業全体のキャッシュリテンション期間とキャッシュ ストレージ サイズの上限を設定できます。

• キャッシュリテンション期間: パブリック リポジトリの場合は最大 90 日間、プライベート リポジトリと内部リポジトリの場合は 365 日まで構成します。
• キャッシュ サイズの削除制限: リポジトリあたり最大 10,000 GB を構成します。

エンタープライズ レベルで構成する設定は、上限として機能します。 組織の所有者は、組織の制限を構成することを選択できますが、エンタープライズ レベルで設定されている制限を超えることはできません。 リポジトリ管理者は、リポジトリの制限を構成することを選択できますが、組織レベルで設定されている制限を超えることはできません。

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

リポジトリへの管理者アクセス権を持つユーザーは、エンタープライズのポリシー設定で許可された最大キャッシュ サイズまで、リポジトリの合計キャッシュ サイズを設定できます。

外部コラボレーターからの pull request ワークフローをフォークする

すべてのユーザーが、パブリック リポジトリをフォークしてから、そのリポジトリのワークフローへの変更を提案する pull request を送信できます。 不正使用を防ぐために、一部の共同作成者によって作成された pull request に対してはワークフローが自動的に実行されることはありません。

実行前に承認が必要な pull request を構成できます。

• GitHub に初めて参加するコントリビューターの承認を必須にする リポジトリにコミットしたことがなく、新しい GitHub アカウントを持つユーザーの承認が必要です。
• 初めての共同作成者の承認が必要です。 リポジトリにコミットしたことがないユーザーに対して承認が必要です。
• すべての外部コラボレーターの承認が必要です。 Organization のメンバーではないすべてのユーザーに対して承認が必要です。

プライベート リポジトリ内の 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 またはリポジトリの既定値として選択できません。

リポジトリへの書き込みアクセス権があるすべてのユーザーは、ワークフロー ファイルの GITHUB_TOKEN キーを編集して、特定のワークフローについて permissions に付与されたアクセス許可を変更できます。

GitHub Actions による pull request の作成と承認は、デフォルトでは無効になっています。 この設定を有効にした場合、 GITHUB_TOKEN は pull request を作成して承認できます。