Informationen zu Azure Privatnetzwerken für von GitHub gehostete Läufer in Ihrer Organisation

Sie können eine private Netzwerkkonfiguration für Ihre Organisation erstellen, um in GitHub gehostete Runner in Ihrem/Ihren Azure Privatnetzwerk(en) (VNET) zu verwenden.

Wer kann dieses Feature verwenden?

Organisationsbesitzer*innen mit dem GitHub Team-Plan können private Azure-Netzwerke für GitHub-gehostete Runner auf Organisationsebene konfigurieren.

In diesem Artikel

Informationen über Azure Privatnetzwerke für GitHub-gehostete Runner

Sie können GitHub-gehosteten Runnern in einem Azure-VNET verwenden. Dies ermöglicht es Ihnen, die Vorteile der von GitHub verwalteten Infrastruktur für Ihren CI/CD-Prozess nutzen und gleichzeitig vollständige Kontrolle über die Netzwerkrichtlinien Ihrer Runner zu haben. Weitere Informationen zu Azure-VNET findest du in der Azure-Dokumentation unter Was ist Azure Virtual Network?.

Sie können mehrere VNET-Subnetze mit GitHub verbinden und den privaten Ressourcenzugriff für Ihre Runner über Runner-Gruppen verwalten. Weitere Informationen zu Runnergruppen findest du unter Steuern des Zugriffs auf größere Runner.

Mithilfe von in GitHub gehosteten Runnern in einem Azure-VNET können sie die folgenden Aktionen ausführen.

  • Verbinden Sie einen Runner privat mit Ressourcen in einem Azure VNET, ohne Internetports zu öffnen – das umfasst auch lokale Ressourcen, auf die über das Azure VNET zugegriffen werden kann.
  • Schränken Sie ein, worauf von GitHub gehostete Runner zugreifen oder womit sie eine Verbindung herstellen dürfen. Dazu haben Sie vollständige Kontrolle über ausgehende Netzwerkrichtlinien.
  • Überwache Netzwerkprotokolle für auf von GitHub gehostete Runner, und zeige die gesamte Konnektivität mit und von einem Runner an.

Informationen zur Verwendung größerer Runner mit Azure VNET

Nur 2-64 vCPU Ubuntu und Windows-Runner werden mit Azure VNET unterstützt. Weitere Informationen zu diesen Runner-Typen finden Sie unter „Informationen zu großen Runnern“.

Private Netzwerke für GitHub-gehosteten Runnern unterstützen keine statischen IP-Adressen für größere Runner. Sie müssen dynamische IP-Adressen verwenden, bei denen es sich um die Standardkonfiguration für größere Runner handelt. Weitere Informationen zu Netztechnologien für größeren Runner finden Sie unter „Informationen zu großen Runnern“.

Über Netzwerkkommunikation

Um die Kommunikation zwischen GitHub-Netzwerken und Ihrem VNET zu erleichtern, Ihrem Azure VNET die Netzwerkschnittstellenkarte (Network Interface Car, NIC) eines GitHub-gehosteten Runners bereitgestellt.

Da sich die NIC in Ihrem VNET befindet, kann GitHub eingehende Verbindungen nicht blockieren. Standardmäßig akzeptieren virtuelle Azure-Computer eingehende Verbindungen vom gleichen VNET. Weitere Informationen finden Sie unter AllowVNetInBound auf Microsoft Learn. Es wird empfohlen, alle eingehenden Verbindungen mit den Runners explizit zu blockieren. GitHub erfordern niemals eingehende Verbindungen zu diesen Computern.

Eine NIC ermöglicht einem virtuellen Azure-Computer (VM) die Kommunikation mit dem Internet, Azure und lokalen Ressourcen. Dadurch ist die gesamte Kommunikation innerhalb der Netzwerkgrenzen privat, und Netzwerkrichtlinien, die auf das VNET angewendet werden, gelten auch für den Runner. Weitere Informationen zum Verwalten einer Netzwerkschnittstelle finden Sie unter Ändern der Netzwerkschnittstelleneinstellungen auf Microsoft Learn.

Note

Für einen einzelnen Auftrag in Ihrem Abonnement können mehrere NICs angezeigt werden, da der Dienst GitHub Actions zu viele Ressourcen für die Ausführung von Aufträgen bereitstellt. Sobald ein Runner im Leerlauf ist, hebt der Dienst GitHub Actions automatisch die Bereitstellung der Ressource auf und entfernt die entsprechende NIC.

Diagramm der Netzwerkkommunikationsarchitektur zwischen GitHub-Netzwerken und Ihren privaten Netzwerken. Das Diagramm beschreibt jeden Schritt beim Verbinden von GitHub-gehosteten Runnern mit einem Azure-VNET. Jeder Schritt ist nummeriert, und die Zahlen entsprechen den nummerierten Beschreibungen des Schritts unterhalb des Diagramms.

  1. GitHub Actions-Workflows werden ausgelöst.
  2. Der GitHub Actions-Dienst erstellt einen Runner.
  3. Mit dem Runner-Dienst wird die Netzwerkschnittstellenkarte (NIC) des GitHub-gehosteten Runners in Ihrem Azure-VNET bereitgestellt.
  4. Der Runner-Agent nimmt den Workflowauftrag auf. Der GitHub Actions-Dienst reiht den Job in die Warteschlange ein.
  5. Der Runner sendet Protokolle zurück an den GitHub Actions-Dienst.
  6. Die NIC greift auf lokale Ressourcen zu.

Unterstützten Regionen

Der Dienst GitHub Actions unterstützt eine Teilmenge aller Regionen, die Azure bereitstellt. Um die Kommunikation zwischen dem Dienst GitHub Actions und Ihrem Subnetz zu erleichtern, muss Ihr Subnetz in einer der folgenden unterstützten Regionen liegen.

  • EastUs
  • EastUs2
  • WestUs2
  • WestUs3
  • CentralUs
  • NorthCentralUs
  • AustraliaEast
  • JapanEast
  • FranceCentral
  • GermanyWestCentral
  • NorthEurope
  • NorwayEast
  • SwedenCentral
  • SwitzerlandNorth
  • UkSouth
  • SoutheastAsia
  • KoreaCentral

Private Azure-Netzwerke unterstützen GPU-Runner in den folgenden Regionen.

  • EastUs
  • WestUs
  • NorthCentralUs

Private Azure-Netzwerke unterstützen arm64-Runner in den folgenden Regionen.

  • EastUs
  • EastUs2
  • WestUs2
  • WestUs3
  • NorthCentralUs

Wenn Ihre gewünschte Region nicht unterstützt wird, senden Sie bitte eine Anforderung an die Verfügbarkeit neuer Regionen in diesem GitHub-Formular. Sie können auch globales Peering virtueller Netzwerke verwenden, um virtuelle Netzwerke über Azure-Regionen hinweg zu verbinden. Weitere Informationen finden Sie unter Peering virtueller Netzwerke in der Azure-Dokumentation.

Informationen zu den GitHub Actions-Dienstberechtigungen

Um eine NIC erfolgreich bereitzustellen und eine NIC mit einem Subnetz zu verbinden, muss der Dienst GitHub Actions die folgenden Berechtigungen zur rollenbasierten Zugriffssteuerung (RBAC) in Ihrem Azure-Abonnement beibehalten. Weitere Informationen zur fein abgestuften Zugriffsverwaltung von Azure-Ressourcen finden Sie unter Azure RBAC in der Azure-Dokumentation.

  • GitHub.Network/operations/read
  • GitHub.Network/networkSettings/read
  • GitHub.Network/networkSettings/write
  • GitHub.Network/networkSettings/delete
  • GitHub.Network/RegisteredSubscriptions/read
  • Microsoft.Network/locations/operations/read
  • Microsoft.Network/locations/operationResults/read
  • Microsoft.Network/locations/usages/read
  • Microsoft.Network/networkInterfaces/read
  • Microsoft.Network/networkInterfaces/write
  • Microsoft.Network/networkInterfaces/delete
  • Microsoft.Network/networkInterfaces/join/action
  • Microsoft.Network/networkSecurityGroups/join/action
  • Microsoft.Network/networkSecurityGroups/read
  • Microsoft.Network/publicIpAddresses/read
  • Microsoft.Network/publicIpAddresses/write
  • Microsoft.Network/publicIPAddresses/join/action
  • Microsoft.Network/routeTables/join/action
  • Microsoft.Network/virtualNetworks/read
  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read
  • Microsoft.Network/virtualNetworks/subnets/write
  • Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/delete
  • Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/read
  • Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/write
  • Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/details/read
  • Microsoft.Network/virtualNetworks/subnets/serviceAssociationLinks/validate/action
  • Microsoft.Resources/subscriptions/resourceGroups/read
  • Microsoft.Resources/subscriptions/resourcegroups/deployments/read
  • Microsoft.Resources/subscriptions/resourcegroups/deployments/write
  • Microsoft.Resources/subscriptions/resourcegroups/deployments/operations/read
  • Microsoft.Resources/deployments/read
  • Microsoft.Resources/deployments/write
  • Microsoft.Resources/deployments/operationStatuses/read

Die folgenden Berechtigungen sind in zwei Unternehmensanwendungen in Ihrem Azure-Mandanten vorhanden. Sie sehen die Unternehmensanwendungen Ihres Azure-Mandanten nach der Konfiguration des privaten Azure-Netzwerks.

  • GitHub CPS Network Service ID: 85c49807-809d-4249-86e7-192762525474
  • GitHub Actions API ID: 4435c199-c3da-46b9-a61d-76de3f2c9f82

Verwenden der Netzwerkrichtlinien Ihres VNET

Da die GitHub-gehostete NIC des Runners in Ihrem Azure VNET bereitgestellt wird, gelten Netzwerkrichtlinien, die auf das VNET angewendet werden, auch für den Runner.

Wenn Ihr VNET beispielsweise mit einer Azure ExpressRoute konfiguriert ist, um Zugriff auf lokale Ressourcen zu ermöglichen (z. B. artefaktbasiert), oder wenn das VNET mit einem VPN-Tunnel verbunden ist, um Zugriff auf andere cloudbasierte Ressourcen zu ermöglichen, gelten diese Zugriffsrichtlinien auch für Ihre Runner. Darüber hinaus gelten alle ausgehenden Regeln, die auf die Netzwerksicherheitsgruppe (NSG) Ihres VNET angewendet werden, sodass Sie den ausgehenden Zugriff für Ihre Runner steuern können.

Wenn Sie die Überwachung von Netzwerkprotokollen für Ihr VNET aktiviert haben, können Sie auch Netzwerkdatenverkehr für Ihre Runner überwachen.

GitHub-gehostete Läufer verwenden die in Ihrem Netzwerk verwendete Ausgangskontrolle. Wenn Ihr Netzwerk den standardmäßigen ausgehenden Zugriff von Azure verwendet, sind die IP-Adressen nicht vorhersehbar und können nicht der Liste der GitHub-IP-Zulassungsliste hinzugefügt werden. Empfehlungen zur Verwendung einer stabilen ausgehenden IP finden Sie in der Azure-Dokumentation unter Standardmäßiger ausgehender Zugriff.

Verwenden von GitHub-gehosteten Runnern mit einem Azure-VNET

Um GitHub-gehostete Runner mit einem Azure VNET zu verwenden, müssen Sie Ihre Azure-Ressourcen konfigurieren und dann eine Netzwerkkonfiguration in GitHub erstellen.

Vorgehensweise zum Konfigurieren privater Azure-Netzwerke auf Unternehmensebene finden Sie unter „AUTOTITEL“.