À propos de la mise en réseau privée Azure pour les agents hébergés par GitHub dans votre organisation

À propos du réseau privé Azure pour les runners GitHub-hébergés par

Vous pouvez utiliser des exécuteurs hébergés par GitHub dans un VNet Azure. Cela vous permet d’utiliser une infrastructure managée par GitHub pour CI/CD tout en vous fournissant un contrôle total sur les stratégies de mise en réseau de vos exécuteurs. Pour plus d'informations sur Azure VNET, consultez la section Qu'est-ce que le réseau virtuel Azure ? dans la documentation Azure.

Vous pouvez connecter plusieurs sous-réseaux VNET à GitHub et gérer l’accès aux ressources privées pour vos runners via des groupes de runners. Pour plus d’informations sur les groupes d’exécuteurs, consultez Contrôle de l’accès aux exécuteurs plus grands.

L’utilisation de GitHubexécuteurs hébergés dans un réseau virtuel Azure vous permet d’effectuer les opérations suivantes.

• Connectez un exécuteur en privé à des ressources à l’intérieur d’un VNet Azure sans ouvrir de ports Internet, y compris les ressources locales accessibles à partir du VNet Azure.
• Limitez les ressources auxquelles les exécuteurs hébergés par GitHub peuvent accéder ou se connecter, avec un contrôle total sur les stratégies réseau sortantes.
• Surveillez les journaux réseau des GitHubexécuteurs hébergés et affichez toutes les connexions vers et depuis un exécuteur.

À propos de l’utilisation d’exécuteurs de plus grandes capacités avec Azure VNET

Les runners Ubuntu et Windows de 2 à 64 vCPU sont pris en charge avec Azure VNET. Pour plus d’informations sur ces types de runners, consultez Exécuteurs plus grands.

Le réseau privé des GitHub hébergés par les exécuteurs ne prend pas en charge les adresses IP statiques des exécuteurs de plus grandes tailles. Vous devez utiliser des adresses IP dynamiques, ce qui est la configuration par défaut pour les runners de grande taille. Pour plus d’informations sur le réseau des runners de grande taille, consultez Exécuteurs plus grands.

Informations sur la communication réseau

Pour faciliter la communication entre les réseaux GitHub et votre VNET, la carte d’interface réseau (NIC) d’un exécuteur hébergé GitHub est déployée sur votre VNET Azure. Le runner est toujours déployé dans la même région Azure que votre sous-réseau.

Étant donné que la carte réseau réside dans votre réseau virtuel, GitHub ne peut pas bloquer les connexions entrantes. Par défaut, les machines virtuelles Azure acceptent les connexions entrantes provenant du même VNET. Pour plus d’informations, consultez AllowVNetInBound sur Microsoft Learn. Il est recommandé de bloquer explicitement toutes les connexions entrantes à destination des runners. GitHub ne nécessite jamais de connexions entrantes à ces ordinateurs.

Une carte d’interface réseau (NIC) permet à une machine virtuelle Azure (VM) de communiquer avec Internet, Azure et les ressources locales. Toutes les communications restent ainsi privées à l’intérieur des limites du réseau et les stratégies de mise en réseau appliquées au VNet s’appliquent également à l’exécuteur. Pour plus d’informations sur la gestion d'une interface réseau, consultez Modifier les paramètres de l'interface réseau sur Microsoft Learn.

1. Un GitHub Actions flux de travail est déclenché.
2. Le service GitHub Actions crée un exécuteur.
3. Le service exécuteur déploie la carte réseau (NIC) du runner hébergé sur GitHub dans votre VNET Azure.
4. L’agent exécuteur prend en charge la tâche du workflow. Le service GitHub Actions met la tâche en file d’attente.
5. L'exécuteur renvoie les journaux au service GitHub Actions.
6. La carte d’interface réseau accède aux ressources locales.

À propos des régions prises en charge

GitHub déploie vos runners dans la même région Azure que le sous-réseau auquel vous les connectez. En raison de cela, votre sous-réseau doit se trouver dans l’une des régions prises en charge. Le GitHub Actions service prend en charge un sous-ensemble de toutes les régions qui Azure fournit, ce qui facilite la communication entre le GitHub Actions service et votre sous-réseau.

Les régions suivantes sont prises en charge sur GitHub.com.

• 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

La mise en réseau privée Azure prend en charge les exécuteurs GPU dans les régions suivantes.

• EastUs
• NorthCentralUs
• SouthCentralUs
• WestUs

La mise en réseau privée Azure prend en charge les exécuteurs arm64 dans les régions suivantes.

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

Nous lancerons bientôt un processus de demande de support pour de nouvelles régions. Vous pouvez également utiliser le peering global de réseau virtuel pour connecter des réseaux virtuels à travers les régions Azure. Pour plus d’informations, consultez Peering de réseau virtuel dans la documentation Azure.

À propos des autorisations de GitHub Actions service

Afin de déployer correctement une carte réseau (NIC) et joindre une NIC à un sous-réseau, le service GitHub Actions gère les autorisations de contrôle d’accès en fonction du rôle (RBAC) suivantes dans votre abonnement Azure. Pour plus d’informations sur la gestion des accès affinée des ressources Azure, consultez Azure RBAC dans la documentation Azure.

• 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

Les autorisations suivantes sont présentes sur deux applications d’entreprise dans votre client Azure. Vous verrez les applications d’entreprise de votre client Azure s’affichent après avoir configuré la mise en réseau privée Azure.

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

Utilisation des stratégies réseau de votre VNet

Étant donné que la carte d’interface réseau de l’exécuteur hébergé par GitHub est déployée dans votre VNet Azure, les stratégies de mise en réseau appliquées au VNet s’appliquent également à l’exécuteur.

Par exemple, si votre VNet est configuré avec Azure ExpressRoute pour fournir l’accès aux ressources locales (par exemple, Artifactory) ou connecté à un tunnel VPN pour fournir l’accès à d’autres ressources cloud, ces stratégies d’accès s’appliquent également à vos exécuteurs. En outre, toutes les règles de trafic sortant appliquées au groupe de sécurité réseau (NSG) de votre VNet s’appliquent également, ce qui vous permet de contrôler l’accès sortant pour vos exécuteurs.

Si vous avez activé la supervision des journaux réseau pour votre VNet, vous pouvez également surveiller le trafic réseau pour vos exécuteurs.

Les exécuteurs hébergés par GitHub utilisent le contrôle de sortie utilisé par votre réseau. Si votre réseau repose sur l’accès de sortie par défaut d’Azure, les IP ne sont pas prévisibles et ne peuvent pas être ajoutées à la liste adresses IP autorisées GitHub. Pour obtenir des recommandations sur l’utilisation d’une adresse IP de sortie stable, consultez Accès de sortie par défaut dans la documentation Azure.

À propos du basculement VNET

Vous pouvez configurer un réseau de basculement pour votre configuration réseau. Un réseau de basculement est un sous-réseau de réseau virtuel Azure secondaire, qui peut se trouver dans une région Azure différente de votre sous-réseau principal. Si votre sous-réseau principal devient indisponible en raison d’une panne régionale ou d’une autre interruption, vous pouvez activer le réseau de basculement pour router le trafic de l’exécuteur via le sous-réseau secondaire, en conservant la continuité de vos GitHub Actions flux de travail.

Points clés concernant le basculement du VNET :

• Le sous-réseau de basculement peut résider dans une région Azure différente de celle du sous-réseau principal.
• Le basculement entre les sous-réseaux principaux et de secours est un processus manuel. Vous activez ou désactivez le réseau de basculement à votre discrétion.
• Les sous-réseaux principaux et de basculement doivent être configurés avec les ressources Azure requises (réseau virtuel/sous-réseau, paramètres réseau, etc.) avant de pouvoir utiliser le basculement.
• Le sous-réseau de basculement doit se trouver dans une région prise en charge.

Pour plus d’informations sur la configuration d’un réseau de basculement, consultez Configuration de la mise en réseau privée pour les exécuteurs hébergés par GitHub dans votre organisation.

Utilisation des runners hébergés GitHub avec un VNET Azure

Pour utiliser les runners hébergés par GitHub avec un réseau virtuel (VNET) Azure, vous devez configurer vos ressources Azure, puis créer une configuration de mise en réseau dans GitHub.

Par défaut, les organisations d’une entreprise ne peuvent pas créer de nouvelles configurations réseau et héritent uniquement des configurations réseau au niveau de l’entreprise. Les propriétaires d’entreprise peuvent définir une stratégie qui permet aux organisations de l’entreprise de créer des configurations réseau indépendantes de l’entreprise. Pour plus d’informations, consultez « Configuration de la mise en réseau privée pour les exécuteurs hébergés par GitHub dans votre entreprise ».

Pour connaître les procédures de configuration du réseau privé Azure au niveau de l’enterprise ,  consultez Configuration de la mise en réseau privée pour les exécuteurs hébergés par GitHub dans votre entreprise.

Pour connaître les procédures de configuration du réseau privé Azure au niveau de l’organisation, consultez Configuration de la mise en réseau privée pour les exécuteurs hébergés par GitHub dans votre organisation.