エンタープライズで GitHub Actions のポリシーを適用する

Enterprise 内で GitHub Actions を使用する方法を管理するポリシーを適用できます。

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

Enterprise owners

この記事の内容

GitHub Actions のポリシーとは?

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

Enterprise ポリシーを適用しない場合、Organization のオーナーと "Organization のアクション ポリシーの管理" アクセス許可を持つユーザーは、Organization の GitHub Actions を完全に制御できます。

ポリシーの適用

  1. GitHub の右上隅にあるプロフィール写真をクリックします。
  2. ご自分の環境に応じて、[Your enterprise] または [Your enterprises] をクリックし、表示するエンタープライズをクリックします。
  3. ページの左側にある Enterprise アカウントのサイドバーで、 [ポリシー] をクリックします。
  4. 「 ポリシー」で、[アクション] をクリックします。
  5. 各ポリシーを構成したら、[保存] をクリックします。

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

ポリシー

[ポリシー] セクションでは、次のオプションを使用して、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 内のリポジトリで定義されているすべてのアクションまたは再利用可能なワークフローに加えて、指定した条件に一致するすべてのアクションまたは再利用可能なワークフローを使用できます。

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

このオプションを選択すると、Enterprise 内のアクションと再利用可能なワークフローが許可されます。他のアクションと再利用可能なワークフローの許可については次のオプションがあります。

  • GitHub によって作成されたアクションを許可する: actions Organization と github Organization にある 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**@* を使用します。

ランナー

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

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

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

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

Note

リポジトリ レベルのセルフホステッド ランナーが作成できなくなっている場合でも、ワークフローは Enterprise レベルまたは Organization レベルのセルフホステッド ランナーにアクセスできます。

成果物とログの保持

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

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

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

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

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

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

Warning

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

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

Note

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 はすべての範囲に対して読み取りアクセスと書き込みアクセスができます。
  • リポジトリの内容とパッケージの読み取りアクセス許可: 既定では、GITHUB_TOKEN には、contents と packages の範囲に対する読み取りアクセス権しかありません。 より制限の緩い設定は、個々の Organization またはリポジトリの既定値として選択できません。

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

[GitHub Actions で pull request の作成と承認を許可する] は既定では無効になっています。 この設定を有効にした場合、 GITHUB_TOKEN は pull request を作成して承認できます。