より大きなランナーへのアクセスの制御

Organization または Enterprise に追加された より大きなランナー へのアクセスを、ポリシーを使って制限できます。

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

より大きなランナー は、GitHub Team または GitHub Enterprise Cloud プランを使っている組織とエンタープライズのみが使用できます。

この記事の内容

注: この記事の情報と手順は、Linux または Windows オペレーティング システムを搭載した より大きなランナー にのみ適用されます。

ランナー グループについて

Organization や Enterprise レベルのランナーへのアクセスを制御するために、Enterprise と Organization の所有者はランナー グループを使用できます。ランナー グループは、ランナーのセットを収集し、その周囲にセキュリティ境界を作成するために使用されます。

ランナー グループにアクセス権を付与すると、そのランナー グループが オーガニゼーションのランナー設定に表示されます。 必要に応じて、リポジトリとワークフローの詳細な追加アクセス ポリシーを、ランナー グループに割り当てることができます。

特に指定がなければ、新しいランナーが作成されると、自動的に既定のグループに割り当てられます。 ランナーは一度に1つのグループにのみ参加できます。 ランナーは、別のランナー グループに移動できます。 詳しくは、「ランナーをグループに移動する」をご覧ください。

特定のグループのランナーにジョブをルーティングする方法についての情報は、「ジョブのランナーを選択する」を参照してください。

ランナーへのアクセスの管理

注: ワークフローがより大きなランナーにジョブを送信できるようにするには、まずランナー グループのアクセス許可を構成する必要があります。 詳しくは、以下のセクションをご覧ください。

ランナー グループは、より大きなランナーでジョブを実行できるリポジトリを制御するために使用されます。 より大きなランナーを定義した場所に応じて、管理階層の各レベルからグループへのアクセス権を管理する必要があります。

  • エンタープライズ レベルのランナー: 既定では、Organization 内のリポジトリは Enterprise レベルのランナー グループにアクセスできません。 リポジトリに Enterprise ランナー グループへのアクセス権を付与するには、Organization の所有者が各 Enterprise ランナー グループを構成し、アクセスできるリポジトリを選ぶ必要があります。
  • 組織レベルのランナー: 既定では、Organization 内のすべてのリポジトリに、Organization レベルのランナー グループへのアクセス権が付与されます。 アクセスできるリポジトリを制限するには、Organization の所有者と "Organization ランナーとランナー グループの管理" アクセス許可を持つユーザーが Organization ランナー グループを構成し、アクセスできるリポジトリを選ぶ必要があります。

たとえば、次の図には、Enterprise レベルに grp-ubuntu-20.04-16core という名前のランナー グループがあります。 octo-repo という名前のリポジトリがグループ内のランナーを使用できるようにするには、まず、octo-org 組織へのアクセスを許可するようにエンタープライズ レベルでグループを構成する必要があります。 次に、octo-repo へのアクセスを許可するように組織レベルでグループを構成する必要があります。

Enterprise レベルで定義されたランナー グループと、2 つのリポジトリへのアクセスを許可する Organization 構成を示す図。

Organization のランナー グループを作成する

警告: 固定 IP 範囲を使っている場合、プライベート リポジトリには より大きなランナー のみを使うことをお勧めします。 ワークフロー内でコードを実行する pull request を作成することで、リポジトリのフォークによって、より大きなランナー 上で危険なコードが実行される可能性があります。

注: ランナー グループを作成するときは、ランナー グループにアクセスできるリポジトリとワークフローが定義されているポリシーを選ぶ必要があります。 ランナー グループにアクセスできるリポジトリとワークフローを変更するには、Organization の所有者と、"Organization ランナーとランナー グループの管理" アクセス許可を持つユーザーが Organization のポリシーを設定できます。 詳しくは、「エンタープライズで GitHub Actions のポリシーを適用する」を参照してください。

すべての Organization には、単一の既定のランナー グループがあります。 Organization の所有者と、"Organization ランナーとランナー グループの管理" アクセス許可を持つユーザーは、追加の Organization レベルのランナー グループを作成できます。 カスタム Organization の役割の詳細については、「カスタム組織の役割の情報」をご覧ください。

登録プロセスでグループを指定しなかった場合、ランナーは自動的に既定のグループに追加されます。 後で、ランナーを既定のグループからカスタム グループに移動することができます。 詳しくは、「ランナーをグループに移動する」をご覧ください。

REST API を使ってランナー グループを作成する方法について詳しくは、「GitHub Actions 用の REST API エンドポイント」をご覧ください。

  1. GitHub で、organization のメイン ページに移動します。

  2. 組織名の下で、 [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    組織のプロファイルのタブのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で囲まれています。

  3. 左サイドバーにある [アクション] をクリックし、 [ランナー グループ] をクリックします。

  4. "ランナー グループ" セクションで、 [新しいランナー グループ] をクリックします。

  5. ランナー グループの名前を入力します。

  6. リポジトリ アクセスのポリシーを割り当てます。

    ランナー グループは、特定のリストのリポジトリまたは組織のすべてのリポジトリにアクセスできるように構成できます。 既定では、ランナー グループのランナーにアクセスできるのはプライベート リポジトリのみですが、これはオーバーライドできます。 エンタープライズによって共有された組織のランナー グループを構成する場合、この設定をオーバーライドすることはできません。

  7. ワークフロー アクセス用のポリシーを割り当てます。

    特定のワークフローの一覧またはすべてのワークフローからアクセスできるようにランナー グループを構成できます。 エンタープライズによって共有された組織のランナー グループを構成している場合、この設定をオーバーライドできません。 ランナー グループにアクセスできるワークフローを指定する場合は、リポジトリ名と所有者を含むワークフローへの完全なパスを使用し、ワークフローをブランチ、タグ、または完全 SHA にピン留めする必要があります。 (例: octo-org/octo-repo/.github/workflows/build.yml@v2, octo-org/octo-repo/.github/workflows/deploy.yml@d6dc6c96df4f32fa27b039f2084f576ed2c5c2a5, monalisa/octo-test/.github/workflows/test.yml@main)。

    選択したワークフロー内で直接定義されたジョブのみがランナー グループにアクセスできます。 Organization が所有するランナー グループは、Enterprise 内の別の Organization からのワークフローにはアクセスできません。代わりに、Enterprise が所有するランナー グループを作成する必要があります。 1. [グループの作成] をクリックしてグループを作成し、ポリシーを適用します。

Enterprise のランナー グループを作成する

警告: 固定 IP 範囲を使っている場合、プライベート リポジトリには より大きなランナー のみを使うことをお勧めします。 ワークフロー内でコードを実行する pull request を作成することで、リポジトリのフォークによって、より大きなランナー 上で危険なコードが実行される可能性があります。

Enterprise を使うと、ランナーがグループに追加されて、アクセス管理を行うことができます。 Enterprise は、Enterprises アカウント内の特定の Organization 、または特定のワークフローにアクセス可能なランナーのグループを作成できます。 その後、Organization の所有者は、Enterprise ランナー グループに対し、追加の詳細なリポジトリまたはワークフロー アクセス ポリシーを割り当てることができます。 REST API を使ってランナー グループを作成する方法については、GitHub Actions REST API の Enterprise エンドポイントをご覧ください。

登録プロセスでグループを指定しなかった場合、ランナーは自動的に既定のグループに追加されます。 後で、ランナーを既定のグループからカスタム グループに移動することができます。 詳しくは、「ランナーをグループに移動する」をご覧ください。

グループを作成するときは、ランナーグループにアクセスできる Organization を定義するポリシーを選択する必要があります。

  1. GitHub の右上の自分のプロフィール写真をクリックし、[自分の Enterprise] をクリックします。

  2. Enterpriseのリストで、表示したいEnterpriseをクリックしてください。

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

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

  5. [ランナー グループ] タブをクリックします。

  6. [New runner group](新しいランナー グループ) をクリックします。

  7. [グループ名] に、ランナー グループの名前を入力します。1. Organization アクセスのポリシーを選ぶには、 [Organization のアクセス] ドロップダウン メニューを選び、[ポリシー] をクリックします。 組織の特定のリストまたはエンタープライズ内のすべての組織にアクセス可能なランナー グループを設定できます。

  8. ワークフロー アクセス用のポリシーを割り当てます。

    特定のワークフローの一覧またはすべてのワークフローからアクセスできるようにランナー グループを構成できます。 エンタープライズによって共有された組織のランナー グループを構成している場合、この設定をオーバーライドできません。 ランナー グループにアクセスできるワークフローを指定する場合は、リポジトリ名と所有者を含むワークフローへの完全なパスを使用し、ワークフローをブランチ、タグ、または完全 SHA にピン留めする必要があります。 (例: octo-org/octo-repo/.github/workflows/build.yml@v2, octo-org/octo-repo/.github/workflows/deploy.yml@d6dc6c96df4f32fa27b039f2084f576ed2c5c2a5, monalisa/octo-test/.github/workflows/test.yml@main)。

    選択したワークフロー内で直接定義されたジョブのみがランナー グループにアクセスできます。

  9. [グループの保存] をクリックしてグループを作成し、ポリシーを適用します。

ランナー グループに一意の名前を使用する

GitHub Actions では、ランナー グループ名が Organization レベルで一意である必要があります。 つまり、Organization は、Enterprise 内のランナー グループと同じ名前を持つものを作成できなくなります。 さらに、ユーザーには、Enterprise 内のグループと同じ名前を共有するすべてのランナー グループに、Organization グループの名前を変更することを提案する警告バナーが表示されます。

あいまいさを回避するために、Organization と Enterprise に重複するランナー グループがある場合、ワークフローは失敗します。 これに対処するには、Organization 内または Enterprise のいずれかのランナー グループの名前を変更するか、ワークフロー ファイルを更新してランナー グループ名にプレフィックスを追加します。

  • org/ または organization/
  • ent/ または enterprise/

例: プレフィックスを使用してランナー グループを区別する

たとえば、Organization 内に my-group という名前のランナー グループがあり、Enterprise 内に my-group という名前のランナー グループがある場合は、ワークフロー ファイルを更新して、org/my-group または ent/my-group を使用して 2 つを区別できます。

org/の使用

runs-on:
  group: org/my-group
  labels: [ self-hosted, label-1 ]

ent/の使用

runs-on:
  group: ent/my-group
  labels: [ self-hosted, label-1 ]

ランナー グループにアクセスできる組織を変更する

警告: 固定 IP 範囲を使っている場合、プライベート リポジトリには より大きなランナー のみを使うことをお勧めします。 ワークフロー内でコードを実行する pull request を作成することで、リポジトリのフォークによって、より大きなランナー 上で危険なコードが実行される可能性があります。

エンタープライズのランナー グループの場合、エンタープライズ内のどの組織がランナー グループにアクセスできるかを変更できます。

  1. GitHub の右上の自分のプロフィール写真をクリックし、[自分の Enterprise] をクリックします。

  2. Enterpriseのリストで、表示したいEnterpriseをクリックしてください。

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

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

  5. [ランナー グループ] タブをクリックします。

  6. [Organization アクセス] で、ドロップダウン メニューを使用して [選択した Organization ] をクリックします。

    1. ドロップダウン メニューの右側にある をクリックします。
    2. ポップアップで、チェックボックスを使って、このランナー グループを使用できる Organization を選択します。

  7. [グループの保存] をクリックします。

ランナー グループにアクセスできるリポジトリを変更する

警告: 固定 IP 範囲を使っている場合、プライベート リポジトリには より大きなランナー のみを使うことをお勧めします。 ワークフロー内でコードを実行する pull request を作成することで、リポジトリのフォークによって、より大きなランナー 上で危険なコードが実行される可能性があります。

組織のランナー グループの場合、組織内のどのリポジトリがランナー グループにアクセスできるかを変更できます。

  1. ランナー グループが配置されている組織のメイン ページに移動します。
  2. [設定] をクリックします。
  3. 左サイドバーにある [アクション] をクリックし、 [ランナー グループ] をクリックします。
  4. グループのリストで、構成するランナー グループをクリックします。
  5. 「リポジトリ アクセス」で、ドロップダウン メニューを使って [選択したリポジトリ] をクリックします。
    1. ドロップダウン メニューの右側にある をクリックします。
    2. ポップアップで、チェックボックスを使って、このランナー グループにアクセスできるリポジトリを選択します。
  6. [グループの保存] をクリックします。

ランナー グループにアクセスできるワークフローを変更する

警告: 固定 IP 範囲を使っている場合、プライベート リポジトリには より大きなランナー のみを使うことをお勧めします。 ワークフロー内でコードを実行する pull request を作成することで、リポジトリのフォークによって、より大きなランナー 上で危険なコードが実行される可能性があります。

選択したワークフローまたはすべてのワークフローを実行するようにランナー グループを構成できます。 たとえば、この設定を使って、ランナーに格納されているシークレットを保護したり、ランナー グループが特定の再利用可能なワークフローのみを実行するように制限してデプロイ ワークフローを標準化したりすることができます。 エンタープライズによって共有された組織のランナー グループを構成している場合、この設定をオーバーライドできません。

組織のランナー グループにアクセスできるワークフローを変更する

  1. ランナー グループが配置されている組織のメイン ページに移動します。

  2. [設定] をクリックします。

  3. 左サイドバーにある [アクション] をクリックし、 [ランナー グループ] をクリックします。

  4. グループのリストで、構成するランナー グループをクリックします。

  5. [ワークフロー アクセス] で、ドロップダウン メニューを選択し、 [選択したワークフロー] をクリックします。

  6. をクリックします。

  7. ランナー グループにアクセスできるワークフローのコンマ区切りの一覧を入力します。 リポジトリ名と所有者を含む完全なパスを使用します。 ワークフローをブランチ、タグ、または完全 SHA にピン留めします。 (例: octo-org/octo-repo/.github/workflows/build.yml@v2, octo-org/octo-repo/.github/workflows/deploy.yml@d6dc6c96df4f32fa27b039f2084f576ed2c5c2a5, monalisa/octo-test/.github/workflows/test.yml@main)。

    選択したワークフロー内で直接定義されたジョブのみがランナー グループにアクセスできます。

    組織所有のランナー グループは、エンタープライズ内の別の組織からワークフローにアクセスできません。代わりに、エンタープライズ所有のランナー グループを作成する必要があります。

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

エンタープライズのランナー グループにアクセスできるワークフローを変更する

  1. GitHub の右上の自分のプロフィール写真をクリックし、[自分の Enterprise] をクリックします。

  2. Enterpriseのリストで、表示したいEnterpriseをクリックしてください。

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

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

  5. [ランナー グループ] タブをクリックします。

  6. グループのリストで、構成するランナー グループをクリックします。

  7. [ワークフロー アクセス] で、ドロップダウン メニューを選択し、 [選択したワークフロー] をクリックします。

  8. をクリックします。

  9. ランナー グループにアクセスできるワークフローのコンマ区切りの一覧を入力します。 リポジトリ名と所有者を含む完全なパスを使用します。 ワークフローをブランチ、タグ、または完全 SHA にピン留めします。 (例: octo-org/octo-repo/.github/workflows/build.yml@v2, octo-org/octo-repo/.github/workflows/deploy.yml@d6dc6c96df4f32fa27b039f2084f576ed2c5c2a5, monalisa/octo-test/.github/workflows/test.yml@main)。

    選択したワークフロー内で直接定義されたジョブのみがランナー グループにアクセスできます。

    組織所有のランナー グループは、エンタープライズ内の別の組織からワークフローにアクセスできません。代わりに、エンタープライズ所有のランナー グループを作成する必要があります。

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

より大きなランナーのプライベート ネットワーク アクセスの構成

Azure VNET での GitHub ホストランナーを使用できます。 これにより、ランナーのネットワーク ポリシーを完全に制御しながら、CI/CD の GitHub マネージド インフラストラクチャを利用することができます。 Azure VNET の詳細については、Azure ドキュメントの「Azure Virtual Network とは」を参照してください。

enterprise または 組織を Azure VNET に接続するように構成している場合は、ランナー グループに仮想ネットワークへのアクセスを許可できます。 詳しくは、「GitHub ホスト ランナーを使用したプライベート ネットワークについて」を参照してください。

ランナー グループの名前を変更する

エンタープライズおよび組織レベルでランナー グループの名前を変更できます。

組織ランナー グループの名前を変更する

  1. ランナー グループが配置されている組織のメイン ページに移動します。
  2. [設定] をクリックします。
  3. 左サイドバーにある [アクション] をクリックし、 [ランナー グループ] をクリックします。
  4. グループのリストで、構成するランナー グループをクリックします。
  5. [グループ名] のテキスト フィールドに新しいランナー グループ名を入力します。
  6. [保存] をクリックします。

エンタープライズ ランナー グループの名前を変更する

  1. GitHub の右上の自分のプロフィール写真をクリックし、[自分の Enterprise] をクリックします。

  2. Enterpriseのリストで、表示したいEnterpriseをクリックしてください。

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

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

  5. [ランナー グループ] タブをクリックします。

  6. グループのリストで、構成するランナー グループをクリックします。

  7. [グループ名] のテキスト フィールドに新しいランナー グループ名を入力します。

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

ランナーをグループに移動する

登録プロセス中にランナー グループを指定しない場合、新しいランナーは、自動的に既定のグループに割り当てられ、その後別のグループへの移動が可能となります。

組織ランナーをグループに移動する

  1. GitHub で、organization のメイン ページに移動します。

  2. 組織名の下で、 [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    組織のプロファイルのタブのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で囲まれています。

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

  4. "ランナー" の一覧で、構成するランナーをクリックします。

  5. [ランナー グループ] ドロップダウンを選択します。

  6. "ランナーをグループに移動" で、ランナーの移動先グループを選択します。

エンタープライズ ランナーをグループに移動する

  1. GitHub の右上の自分のプロフィール写真をクリックし、[自分の Enterprise] をクリックします。

  2. Enterpriseのリストで、表示したいEnterpriseをクリックしてください。

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

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

  5. [Runners](ランナー) タブをクリックします。

  6. "ランナー" の一覧で、構成するランナーをクリックします。

  7. [ランナー グループ] ドロップダウンを選択します。

  8. "ランナーをグループに移動" で、ランナーの移動先グループを選択します。

ランナー グループを削除する

ランナー グループを削除するには、まず、グループからすべてのランナーを移動するか削除する必要があります。

組織からランナーを削除する

  1. ランナー グループが配置されている組織のメイン ページに移動します。
  2. [設定] をクリックします。
  3. 左サイドバーにある [アクション] をクリックし、 [ランナー グループ] をクリックします。
  4. グループの一覧で、削除するグループの右側にある をクリックします。
  5. グループを削除するには、 [グループの削除] をクリックします。
  6. 確認プロンプトを確認し、 [Remove this runner group](このランナー グループの削除) をクリックします。

エンタープライズからランナーを削除する

  1. GitHub の右上の自分のプロフィール写真をクリックし、[自分の Enterprise] をクリックします。

  2. Enterpriseのリストで、表示したいEnterpriseをクリックしてください。

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

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

  5. [ランナー グループ] タブをクリックします。

  6. グループの一覧で、削除するグループの右側にある をクリックします。

  7. グループを削除するには、 [グループの削除] をクリックします。

  8. 確認プロンプトを確認し、 [Remove this runner group](このランナー グループの削除) をクリックします。