このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となります: 2024-08-29. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください。

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

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

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

Enterprise owners

この記事の内容

GitHub Actions のポリシーとは?

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

Enterprise ポリシーを適用しない場合、Organization のオーナーは、Organization の GitHub Actions を完全に制御できます。

ポリシーの適用

  1. GitHub Enterprise Server の右上で、ご自分のプロフィール フォトをクリックしてから、 [Enterprise 設定] をクリックします。

    GitHub Enterprise Server のプロファイル写真をクリックしたときに表示されるドロップダウン メニューのスクリーンショット。 [エンタープライズ設定] オプションが濃いオレンジ色の枠線で強調表示されています。

  2. ページの左側にある Enterprise アカウントのサイドバーで、 [ポリシー] をクリックします。

  3. 「 ポリシー」で、[アクション] をクリックします。

  4. 各ポリシーを構成したら、[保存] をクリックします。

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

ポリシー

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

  • すべての Organization に対して GitHub Actions を有効にする
  • 特定の Organization に対して GitHub Actions を有効にする
  • すべての Organization に対して GitHub Actions を無効にする

次のオプションを使用して、パブリック アクションの使用を制限することもできます。

  • すべてのアクションを許可する: 作成者や定義場所に関係なく、任意のアクションを使用できます。
  • Enterprise アクションを許可する: Enterprise 内のリポジトリで定義されているアクションのみを使用できます。
  • [Allow select actions](選択したアクションを許可する) : Enterprise 内のリポジトリで定義されているすべてのアクションに加えて、指定した条件に一致するすべてのアクションを使用できます。

[Allow select actions](選択したアクションを許可する)

このオプションを選択すると、Enterprise 内のアクションが許可されます。他のアクションの許可については次のオプションがあります。

  • GitHub によって作成されたアクションを許可する: actions Organization と github Organization にある GitHub によって作成されたすべてのアクションを許可します。

  • 検証済みの作成者によるマーケットプレース アクションを許可する: 検証済み作成者が作成し、 というラベルが付いたすべての GitHub Marketplace アクションを許可します。

    GitHub Connect が有効になっていて、GitHub Actions で構成されている場合にのみ使用できます。 「GitHub Connect を使用して GitHub.com アクションへの自動アクセスを可能にする」を参照してください。

  • 指定したアクションを許可する: 指定したアクションを許可します。 個々のアクションまたは Organization とリポジトリ全体を指定できます。

アクションを指定する場合は、次の構文を使用します。

  • アクションの特定のタグまたはコミット SHA へのアクセスを制限するには、ワークフローで使われているのと同じ構文を使って、アクションを選びます。
    • アクションの場合の構文は、OWNER/REPOSITORY@TAG-OR-SHA です。 たとえば、タグを選択するには actions/javascript-action@v1.0.1 を使用し、SHA を選択するには actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f を使用します。
  • パターンを指定するには、ワイルドカード文字 * を使用します。
    • space-org で始まる Organization のすべてのアクションを許可するには、space-org*/* を使用します。
    • octocat で始まるリポジトリのすべてのアクションを許可するには、*/octocat**@* を使用します。

ランナー

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

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

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

Note

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

成果物、ログ、キャッシュの設定

次のポリシーは、成果物、ログ、キャッシュのストレージを制御します。

成果物とログの保持

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

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

最大キャッシュ サイズ制限と既定のキャッシュ サイズ制限

既定:

  • GitHub Actions が お使いの GitHub Enterprise Server インスタンス 用の外部ストレージで使用するキャッシュ ストレージの合計は、リポジトリあたり最大 10 GB に制限されます。
  • リポジトリに設定できる最大許容サイズは 25 GB です。

この制限を超えると、GitHub は新しいキャッシュを保存しますが、合計サイズがリポジトリの制限を下回るまでキャッシュの削除を開始します。

各リポジトリの既定の合計キャッシュ サイズと、リポジトリで許可される最大の合計キャッシュ サイズの両方をカスタマイズできます。 たとえば、各リポジトリの既定の合計キャッシュ サイズを 5 GB にする一方で、管理者が個々のリポジトリの合計キャッシュ サイズを最大 15 GB に構成できるようにしたい場合があります。

組織所有者は、組織内の各リポジトリに適用される合計キャッシュ サイズをさらに小さく設定できます。 リポジトリへの管理者アクセス権を持つユーザーは、エンタープライズまたは組織のポリシー設定で許可された最大キャッシュ サイズまで、リポジトリの合計キャッシュ サイズを設定できます。

プライベート リポジトリ内の 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 を作成して承認できます。