GitHub ホストランナーの Azure プライベート ネットワークについて
Azure VNET での GitHub ホストランナーを使用できます。 これにより、ランナーのネットワーク ポリシーを完全に制御しながら、CI/CD の GitHub マネージド インフラストラクチャを利用することができます。 Azure VNET の詳細については、Azure ドキュメントの「Azure Virtual Network とは」を参照してください。
複数の VNET サブネットを GitHub に接続し、ランナー グループを介してランナーのプライベート リソース アクセスを管理できます。 ランナー グループについて詳しくは、「より大きなランナーへのアクセスの制御」をご覧ください。
Azure VNet 内で GitHub でホストされているランナーを使用すると、次のアクションを実行できます。
- Azure VNET からアクセス可能なオンプレミス リソースなど、インターネット ポートを開かずにランナーを Azure VNET 内のリソースにプライベートに接続します。
- 送信ネットワーク ポリシーを完全に制御して、GitHub でホストされているランナーがアクセスまたは接続できる対象を制限します。
- GitHub でホストされているランナーのネットワーク ログを監視し、ランナーとの間のすべての接続を表示します。
Azure VNET での大規模ランナーの使用について
Azure VNET では、Ubuntu および Windows ランナーは 2 から 64 個の vCPU がサポートされています。 これらのランナーの種類の詳細については、「より大きなランナーの概要」を参照してください。
GitHub でホストされたランナーのプライベート ネットワークでは、larger runner の静的 IP アドレスはサポートされていません。 larger runner の既定の構成である動的 IP アドレスを使用する必要があります。 より大きなランナーのネットワークの詳細については、「より大きなランナーの概要」を参照してください。
ネットワーク通信について
GitHub ネットワークと VNET の間の通信を容易にするために、GitHub でホストされたランナーのネットワーク インターフェイス カード (NIC) が Azure VNET にデプロイされます。
NIC は VNET 内に存在するため、GitHub は受信接続をブロックできません。 既定では、Azure 仮想マシンは同じ VNET からの受信接続を受け入れます。 詳細については、Microsoft Learn の「AllowVNetInBound」を参照してください。 ランナーへのすべての受信接続を明示的にブロックすることをお勧めします。 GitHub では、これらのマシンへの受信接続は必要ありません。
NIC により、Azure 仮想マシン (VM) でインターネット、Azure、オンプレミスのリソースと通信できます。 このように、すべての通信はネットワーク境界内でプライベートに保たれ、VNet に適用されるネットワーク ポリシーもランナーに適用されます。 ネットワーク インターフェイスを管理する方法の詳細については、Microsoft Learn の「ネットワーク インターフェイス設定を変更する」を参照してください。
Note
GitHub Actions サービスは、ジョブの実行でリソースを過剰にプロビジョニングするので、サブスクリプション内の 1 つのジョブ内で複数の NIC が見られることがあります。 ランナーがアイドル状態になると、GitHub Actions サービスによってリソースのプロビジョニング解除が自動的に行われ、対応する NIC が削除されます。
- GitHub Actions ワークフローをトリガーします。
- GitHub Actions サービスはランナーを作成します。
- このランナー サービスにより、GitHubでホストされているランナーのネットワーク インターフェイス カード (NIC) が Azure VNet にデプロイされます。
- ランナー エージェントがワークフロー ジョブを取得します。 GitHub Actions サービスはジョブをキューします。
- ランナーは、ログを GitHub Actions サービスに送り返します。
- NIC はオンプレミスのリソースにアクセスします。
サポートされている地域について
GitHub Actions サービスは、Azure が提供するすべてのリージョンのサブセットをサポートします。 GitHub Actions サービスとサブネットの間の通信を容易にするには、サブネットがサポートされているリージョンのいずれかに存在している必要があります。
Note
GHE.com で データ所在地が を使う場合は、サポートされているリージョンが異なります。 「GHE.com のネットワークの詳細」を参照してください。
GitHub.com では、次のリージョンがサポートされています。
EastUsEastUs2WestUs2WestUs3CentralUsNorthCentralUsAustraliaEastJapanEastFranceCentralGermanyWestCentralNorthEuropeNorwayEastSwedenCentralSwitzerlandNorthUkSouthSoutheastAsiaKoreaCentral
Azure プライベート ネットワークは、次のリージョンの GPU ランナーをサポートしています。
EastUsWestUsNorthCentralUs
Azure プライベート ネットワークは、次のリージョンで arm64 ランナーをサポートしています。
EastUsEastUs2WestUs2WestUs3NorthCentralUs
希望するリージョンがサポート対象になっていない場合は、この GitHub フォームで新しいリージョンの可用性に関する要求を送信してください。 また、Azure リージョン間で仮想ネットワークを接続するのに、グローバル仮想ネットワーク ピアリングを使用します。 詳細情報については、Azure ドキュメントの「仮想ネットワーク ピアリング」を参照してください。
GitHub Actions サービスのアクセス許可について
NIC を正常にデプロイし、NIC をサブネットに参加させるために、GitHub Actions サービスは Azure サブスクリプションで次の Azure ロールベースのアクセス制御 (RBAC) アクセス許可を維持します。 Azure リソースのきめ細かなアクセス管理の詳細については、Azure ドキュメントの「Azure RBAC」を参照してください。
GitHub.Network/operations/readGitHub.Network/networkSettings/readGitHub.Network/networkSettings/writeGitHub.Network/networkSettings/deleteGitHub.Network/RegisteredSubscriptions/readMicrosoft.Network/locations/operations/readMicrosoft.Network/locations/operationResults/readMicrosoft.Network/locations/usages/readMicrosoft.Network/networkInterfaces/readMicrosoft.Network/networkInterfaces/writeMicrosoft.Network/networkInterfaces/deleteMicrosoft.Network/networkInterfaces/join/actionMicrosoft.Network/networkSecurityGroups/join/actionMicrosoft.Network/networkSecurityGroups/readMicrosoft.Network/publicIpAddresses/readMicrosoft.Network/publicIpAddresses/writeMicrosoft.Network/publicIPAddresses/join/actionMicrosoft.Network/routeTables/join/actionMicrosoft.Network/virtualNetworks/readMicrosoft.Network/virtualNetworks/subnets/join/actionMicrosoft.Network/virtualNetworks/subnets/readMicrosoft.Network/virtualNetworks/subnets/writeMicrosoft.Network/virtualNetworks/subnets/serviceAssociationLinks/deleteMicrosoft.Network/virtualNetworks/subnets/serviceAssociationLinks/readMicrosoft.Network/virtualNetworks/subnets/serviceAssociationLinks/writeMicrosoft.Network/virtualNetworks/subnets/serviceAssociationLinks/details/readMicrosoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/actionMicrosoft.Resources/subscriptions/resourceGroups/readMicrosoft.Resources/subscriptions/resourcegroups/deployments/readMicrosoft.Resources/subscriptions/resourcegroups/deployments/writeMicrosoft.Resources/subscriptions/resourcegroups/deployments/operations/readMicrosoft.Resources/deployments/readMicrosoft.Resources/deployments/writeMicrosoft.Resources/deployments/operationStatuses/read
次のアクセス許可は、Azure テナント内の 2 つのエンタープライズ アプリケーションに存在します。 Azure プライベート ネットワークを構成すると、Azure テナントのエンタープライズ アプリケーションが表示されます。
GitHub CPS Network Serviceid:85c49807-809d-4249-86e7-192762525474GitHub Actions APIid:4435c199-c3da-46b9-a61d-76de3f2c9f82
VNET のネットワーク ポリシーの使用
GitHub ホストランナーの NIC が Azure VNET にデプロイされるため、VNET に適用されるネットワーク ポリシーもランナーに適用されます。
たとえば、VNet がオンプレミスのリソース (例:Artifactory) へのアクセスを提供するように Azure ExpressRoute で構成されている場合、または他のクラウドベースのリソースへのアクセスを提供するために VPN トンネルに接続されている場合、これらのアクセス ポリシーはランナーにも適用されます。 さらに、VNET のネットワーク セキュリティ グループ (NSG) に適用される送信規則も適用され、ランナーの送信アクセスを制御できます。
VNET のネットワーク ログ監視を有効にしている場合は、ランナーのネットワーク トラフィックを監視することもできます。
GitHub ホストランナーは、ネットワークで使用されている送信制御を使用します。 ネットワークが Azure の既定の送信アクセスに依存している場合、IP は予測できず、GitHub IP 許可リストに追加できません。 安定した送信 IP の使用に関する推奨事項については、Azure ドキュメントの「既定の送信アクセス」を参照してください。
Enterprise 内の Organization のネットワーク構成ポリシーを管理する
Enterprise 内の Organization 所有者に、GitHub でホストされるランナーの Organization レベルのネットワーク構成を設定および維持する権限を付与できます。
詳しくは、「企業内の GitHub ホストランナーのプライベート ネットワークの構成」をご覧ください。
Azure VNET での GitHub ホストランナーの使用
Azure VNET で GitHub ホストランナーを使用するには、Azure リソースを構成してから、GitHub にネットワーク構成を作成する必要があります。
既定では、Enterprise 内の Organization は新しいネットワーク構成を作成できず、Enterprise レベルのネットワーク構成を継承するだけです。 Enterprise オーナーは、Enterprise 内の Organization が Enterprise から独立したネットワーク構成を作成できるようにするポリシーを設定できます。 詳しくは、「企業内の GitHub ホストランナーのプライベート ネットワークの構成」を参照してください。
エンタープライズ レベルで Azure プライベート ネットワークを構成する手順については、「企業内の GitHub ホストランナーのプライベート ネットワークの構成」を参照してください。
組織レベルで Azure プライベート ネットワークを構成する手順については、「組織内の GitHub ホスト ランナーのプライベート ネットワークの構成」を参照してください。