Organization について GitHub Actions を無効化または制限する

Organization の GitHub Actions を有効化、無効化、制限することができます。

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

Organization owners and users with the "Manage organization Actions policies" and "Manage runners and runner groups" fine-grained permissions can enable, disable, and limit GitHub Actions for an organization.

For more information, see カスタム組織の役割の情報.

この記事の内容

Organization の GitHub Actions 権限について

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

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

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

Organization の GitHub Actions 権限の管理

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

Note

Organization が、優先ポリシーのある Enterprise によって管理されている場合、これらの設定を管理できない場合があります。 詳しくは、「エンタープライズで GitHub Actions のポリシーを適用する」をご覧ください。

  1. GitHub の右上隅で、プロフィール写真を選択し、 あなたの組織をクリックします。

  2. 組織の隣の [設定] をクリックします。

  3. 左のサイドバーで [アクション] をクリックして、 [全般] をクリックします。

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

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

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

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

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

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

Note

Organization に優先ポリシーがある場合、または優先ポリシーのある Enterprise によって管理されている場合は、これらの設定を管理できない場合があります。 詳しくは、「Organization について GitHub Actions を無効化または制限する」または「エンタープライズで GitHub Actions のポリシーを適用する」をご覧ください。

  • [GitHub によって作成されたアクションを許可する]: GitHub によって作成されたすべてのアクションを、ワークフローで使用できるようにします。 GitHub によって作成されたアクションは、actions および github 組織にあります。 詳しくは、actions および github の Organization をご覧ください。

  • [検証済みの作成者による Marketplace アクションを許可する]: 検証済みの作成者が作成したすべての GitHub Marketplace アクションをワークフローで使用できるようにできます。 GitHubがアクションの作者をパートナーOrganizationとして検証すると、GitHub Marketplaceでアクションの隣にバッジが表示されるようになります。

  • [指定したアクションと再利用可能なワークフローを許可する]: ワークフローで使用できるアクションと再利用可能なワークフローを、特定の組織とリポジトリのものに制限します。 指定されたアクションを 1000 を超えるアクションに設定することはできません。

    アクションまたは再利用可能なワークフローの特定のタグまたはコミット 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**@* を使用できます。 * ワイルドカードの使用の詳細については、「GitHub Actions　のワークフロー構文」を参照してください。

    パターンを区切るには , を使います。 たとえば、octocat と octokit を許可するには、octocat/*, octokit/* を指定します。

    Note

    GitHub Free、GitHub Pro、organization の GitHub Free、または GitHub Team プランでは、[Allow specified actions and reusable workflows] オプションはパブリック リポジトリでのみ使用できます。

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

  1. GitHub の右上隅で、プロフィール写真を選択し、 あなたの組織をクリックします。
  2. 組織の隣の [設定] をクリックします。
  3. 左のサイドバーで [アクション] をクリックして、 [全般] をクリックします。
  4. [ポリシー] で [ [Allow enterprise, and select non-enterprise, actions and reusable workflows](エンタープライズを許可し、非エンタープライズ、アクション、再利用可能なワークフローを選択する) ] を選び、必要なアクションと再利用可能なワークフローを一覧に追加します。
  5. [保存] をクリックします。

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

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

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

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

Note

Organization が Enterprise に属している場合、リポジトリ レベルでのセルフホステッド ランナーの作成は、Enterprise 全体の設定として無効になっている可能性があります。 これが行われている場合、Organization 設定でリポジトリ レベルのセルフホステッド ランナーを有効にすることはできません。 詳しくは、「エンタープライズで GitHub Actions のポリシーを適用する」をご覧ください。

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

"ランナー"の一覧の状態が "無効" のセルフホステッド ランナーを示すスクリーンショット。

Note

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

  1. GitHub の右上隅で、プロフィール写真を選択し、 あなたの組織をクリックします。
  2. 組織の隣の [設定] をクリックします。
  3. 左のサイドバーで [アクション] をクリックして、 [全般] をクリックします。
  4. [ランナー] で、ドロップダウン メニューを使って好みの設定を選びます。
    • すべてのリポジトリ - セルフホステッド ランナーは、Organization 内の任意のリポジトリで使えます。
    • 選択したリポジトリ - セルフホステッド ランナーは、選んだリポジトリでのみ使えます。
    • 無効 - セルフホステッド ランナーはリポジトリ レベルで作ることはできません。
  5. [選択したリポジトリ] を選んだ場合は、次のようにします。
    1. をクリックします。
    2. セルフホステッド ランナーを許可するリポジトリのチェック ボックスをオンにします。
    3. [リポジトリの選択] をクリックします。

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

パブリックリポジトリをフォークし、リポジトリの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 イベントについて詳しくは、「ワークフローをトリガーするイベント」をご覧ください。

Warning

これらのワークフロー承認ポリシーは、GitHub Actions ランナーでワークフローを実行できるユーザーのセットを制限することを目的としています。これにより、GitHub ホステッド ランナーを使用すると、予期しないリソースとコンピューティングの消費につながる可能性があります。 自己ホストランナーを使用している場合、設定された承認ポリシーでの承認をユーザーがバイパスすることが許可されているか、pull request が承認されていると、悪意のある可能性のあるユーザーが制御するワークフロー コードが自動的に実行されます。 インフラストラクチャでこのコードを実行するリスクを考慮する必要があり、使用されている承認設定に関係なく、自己ホストランナーのセキュリティに関する推奨事項を確認して従う必要があります。 「GitHub Actions のセキュリティ強化」をご覧ください。

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

  1. GitHub の右上隅で、プロフィール写真を選択し、 あなたの組織をクリックします。

  2. 組織の隣の [設定] をクリックします。

  3. 左のサイドバーで [アクション] をクリックして、 [全般] をクリックします。

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

    Warning

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

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

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

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

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

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

Enterpriseでポリシーが無効化されていると、それをOrganizationで有効化することはできません。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 の右上隅で、プロフィール写真を選択し、 あなたの組織をクリックします。
  2. 組織の隣の [設定] をクリックします。
  3. 左のサイドバーで [アクション] をクリックして、 [全般] をクリックします。
  4. [Fork pull request workflows](pull request ワークフローのフォーク) で、オプションを選択します。
  5. [保存] をクリックして設定を適用します。

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

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

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

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

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

既定では、新しい Organization を作成すると、 設定は Enterprise 設定で構成されているものから継承されます。

  1. GitHub の右上隅で、プロフィール写真をクリックし、[あなたのプロフィール] をクリックします。

    @octocat のプロファイル写真の下にあるドロップダウン メニューのスクリーンショット。 [自分のプロファイル] が濃いオレンジ色の枠線で囲まれています。

  2. GitHub の右上隅で、プロフィール写真を選択し、 あなたの組織をクリックします。

  3. 組織の隣の [設定] をクリックします。

  4. 左のサイドバーで [アクション] をクリックして、 [全般] をクリックします。

  5. [ワークフローのアクセス許可] で、GITHUB_TOKEN に対してすべてのアクセス許可での読み取りと書き込みのアクセスを許可するか (制限の緩い設定)、contents アクセス許可と packages アクセス許可での読み取りアクセスのみを許可するか (制限された設定) を選びます。

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

GitHub Actions による pull request の作成または承認を禁止する

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

既定では、新しい Organization を作成するとき、ワークフローで pull request を作成または承認することは許可されていません。

  1. GitHub の右上隅で、プロフィール写真をクリックし、[あなたのプロフィール] をクリックします。

    @octocat のプロファイル写真の下にあるドロップダウン メニューのスクリーンショット。 [自分のプロファイル] が濃いオレンジ色の枠線で囲まれています。

  2. GitHub の右上隅で、プロフィール写真を選択し、 あなたの組織をクリックします。

  3. 組織の隣の [設定] をクリックします。

  4. 左のサイドバーで [アクション] をクリックして、 [全般] をクリックします。

  5. [ワークフローのアクセス許可] で、 [GitHub Actions が pull request を作成または承認するのを許可する] 設定を使って、GITHUB_TOKEN が pull request を作成または承認できるかどうかを構成します。

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

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

Organization の管理者は GitHub Actions Organization 内のすべてのリポジトリのキャッシュ ストレージを管理できます。

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

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

  1. GitHub の右上隅で、プロフィール写真をクリックし、[あなたのプロフィール] をクリックします。

    @octocat のプロファイル写真の下にあるドロップダウン メニューのスクリーンショット。 [自分のプロファイル] が濃いオレンジ色の枠線で囲まれています。

  2. GitHub の右上隅で、プロフィール写真を選択し、 あなたの組織をクリックします。

  3. 組織の隣の [設定] をクリックします。

  4. 左のサイドバーで [アクション] をクリックし、 [キャッシュ] をクリックします。

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