Informationen zu privaten Azure-Netzwerken für von GitHub gehostete Runner in Ihrem Unternehmen

Sie können eine private Netzwerkkonfiguration für Ihr Unternehmen erstellen, um GitHub-gehostete Runner in Ihrem virtuellen Azure-Netzwerk (VNET) zu verwenden.

Wer kann dieses Feature verwenden?

Enterprise owners can create private network configurations at the enterprise level to use GitHub-hosted runners with an Azure VNET.

In diesem Artikel

Informationen zu privaten Azure-Netzwerken für GitHubgehostete 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.

Die Verwendung von GitHubgehosteten Runnern innerhalb eines Azure-VNETs ermöglicht es Ihnen, die folgenden Aktionen durchzufü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.
  • Beschränken Sie bei voller Kontrolle über die Richtlinien für ausgehenden Netzwerkverkehr, auf was GitHub-gehostete Runner zugreifen oder womit sie sich verbinden können.
  • Überwachen Sie Netzwerklogs für von GitHub gehostete Runner, und zeigen Sie die gesamte Konnektivität zu und von einem Runner an.

Informationen zur Verwendung größerer Runner mit Azure VNET

2-64-vCPU-Ubuntu- und -Windows-Runner werden mit Azure VNET unterstützt. Weitere Informationen zu diesen Runner-Typen findest du unter Größere Läufer.

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 Läufer handelt. Weitere Informationen zum Netzwerk für größere Runner finden Sie unter Größere Läufer.

Über Netzwerkkommunikation

Um die Kommunikation zwischen den Netzwerken GitHub und Ihrem VNET zu erleichtern, wird die Netzwerkkarte (NIC) eines von GitHub gehosteten Runners in Ihrem Azure VNET bereitgestellt. Der Runner wird immer in derselben Azure-Region wie Ihr Subnetz bereitgestellt.

Da sich die NIC innerhalb Ihres VNETs 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 erfordert 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.

Hinweis

In Kürze werden NICs, die vom GitHub Actions-Dienst erstellt wurden, nicht mehr in deinen Azure-Abonnements angezeigt. Zukünftig werden Netzwerkkarten im Rahmen eines Service-Abonnements bereitgestellt und IP-Adressen aus deinem Subnetz zugewiesen.

Diagramm der Netzwerkkommunikation zwischen GitHub und deinen privaten Netzwerken. Jeder Schritt ist nummeriert und entspricht einem Schritt, der unter dem Diagramm aufgeführt ist.

  1. Ein GitHub Actions Workflow wird ausgelöst.
  2. Der GitHub Actions Dienst erstellt einen Runner.
  3. Der Runner-Dienst stellt die Netzwerkschnittstellenkarte (NIC) des auf GitHub gehosteten Runners in Ihrem Azure-VNET bereit.
  4. Der Runner-Agent nimmt den Workflowauftrag auf. Der GitHub Actions-Dienst stellt den Einzelvorgang in die Warteschlange ein.
  5. Der Läufer sendet Protokolle zurück an den GitHub Actions Dienst.
  6. Die NIC greift auf lokale Ressourcen zu.

Über unterstützte Regionen

GitHub stellt Ihre Runner in derselben Azure-Region wie das Subnetz bereit, mit dem Sie sie verbinden. Aus diesem Gründen muss sich Ihr Subnetz in einer der unterstützten Regionen befinden. Der GitHub Actions Dienst unterstützt eine Teilmenge aller Regionen, die Azure bereitstellt, wodurch die Kommunikation zwischen dem GitHub Actions Dienst und Ihrem Subnetz erleichtert wird.

Hinweis

Wenn Sie Datenresidenz auf GHE.com verwenden, sind die unterstützten Regionen unterschiedlich. Weitere Informationen findest du unter Netzwerkdetails für GHE.com.

Die folgenden Regionen werden auf GitHub.com unterstützt.

  • AustraliaEast
  • BrazilSouth
  • CanadaCentral
  • CanadaEast
  • CentralUs
  • EastAsia
  • EastUs
  • EastUs2
  • FranceCentral
  • GermanyWestCentral
  • JapanWest
  • KoreaCentral
  • NorthCentralUs
  • NorthEurope
  • NorwayEast
  • SouthCentralUs
  • SoutheastAsia
  • SouthIndia
  • SwedenCentral
  • SwitzerlandNorth
  • UkSouth
  • UkWest
  • WestUs
  • WestUs2
  • WestUs3

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

  • EastUs
  • NorthCentralUs
  • SouthCentralUs
  • WestUs

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

  • CentralUs
  • EastUs
  • EastUs2
  • NorthCentralUs
  • SouthCentralUs
  • WestUs
  • WestUs2
  • WestUs3

Wir werden in Kürze einen Prozess starten, um Unterstützung für neue Regionen anzufordern. 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 Sie die 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.

Informationen zum VNET-Failover

Hinweis

Das VNET-Failover befindet sich in Öffentliche Vorschau und unterliegt Änderungen.

Sie können ein Failovernetzwerk für Ihre Netzwerkkonfiguration konfigurieren. Ein Failovernetzwerk ist ein sekundäres Virtuelles Azure-Netzwerk-Subnetz, das sich in einer anderen Azure-Region als Ihrem primären Subnetz befinden kann. Wenn Ihr primäres Subnetz aufgrund eines regionalen Ausfalls oder einer anderen Unterbrechung nicht verfügbar ist, können Sie das Failovernetzwerk aktivieren, um den Läuferdatenverkehr über das sekundäre Subnetz weiterzuleiten und die Kontinuität für Ihre GitHub Actions Workflows aufrechtzuerhalten.

Wichtige Punkte zum VNET-Failover:

  • Das Failoversubnetz kann sich in einer anderen Azure-Region als dem primären Subnetz befinden.
  • Der Wechsel zwischen primären und Failoversubnetzen ist ein manueller Prozess. Sie aktivieren oder deaktivieren das Failovernetzwerk nach Eigenem Ermessen.
  • Sowohl die primären als auch die Failoversubnetze müssen mit den erforderlichen Azure-Ressourcen (VNET/Subnetz, Netzwerkeinstellungen usw.) konfiguriert werden, bevor Sie Failover verwenden können.
  • Das Failoversubnetz muss sich in einer unterstützten Region befinden.

Weitere Informationen zum Konfigurieren eines Failovernetzwerks finden Sie unter Konfigurieren eines privaten Netzwerks für GitHub-Runner in Ihrem Unternehmen.

Verwalten von Netzwerkkonfigurations-Richtlinien für Organisationen in deinem Unternehmen

Sie können Organisationsbesitzern in Ihrem Unternehmen die Möglichkeit geben, Netzwerkkonfigurationen auf Organisationsebene für GitHub-gehostete Runner einzurichten und zu verwalten.

Weitere Informationen finden Sie unter Konfigurieren eines privaten Netzwerks für GitHub-Runner in Ihrem Unternehmen.

Verwenden von GitHubgehosteten Runnern mit einem Azure-VNET

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

Standardmäßig können Organisationen in einem Unternehmen keine neuen Netzwerkkonfigurationen erstellen und nur Netzwerkkonfigurationen auf Unternehmensebene erben. Unternehmensbesitzer*innen können eine Richtlinie festlegen, mit der Organisationen im Unternehmen Netzwerkkonfigurationen erstellen können, die unabhängig vom Unternehmen sind. Weitere Informationen finden Sie unter Konfigurieren eines privaten Netzwerks für GitHub-Runner in Ihrem Unternehmen.

Verfahren zum Konfigurieren privater Azure-Netzwerke auf Unternehmensebene findest du unter Konfigurieren eines privaten Netzwerks für GitHub-Runner in Ihrem Unternehmen.

Vorgehensweise zum Konfigurieren privater Azure-Netzwerke auf Unternehmensebene findest du unter Konfiguration privater Netzwerke für GitHub-gehostete Runner in Ihrer Organisation.