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

À 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 exécutants via des groupes d’exécuteurs. Pour plus d’informations sur les groupes d’exécuteurs, consultez Contrôle de l’accès aux exécuteurs plus grands.

L’utilisation d’exécuteurs hébergés par GitHub dans le réseau virtuel Azure vous permet d’effectuer les actions 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 l’accès et la connexion des exécuteurs hébergés par GitHub avec un contrôle total sur les stratégies réseau sortantes.
• Analyser les journaux réseau pour les exécuteurs hébergés par GitHub et afficher toute la connectivité vers et depuis un exécuteur.

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

Les exécuteurs Ubuntu et Windows avec UC 2-64 sont pris en charge par Azure VNET. Pour plus d’informations sur les types d’exécuteurs, 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, configuration par défaut des exécuteurs de plus grande taille. Pour plus d’informations sur la mise en réseau des exécuteurs de plus 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 GitHub hébergé se déploie dans votre VNET Azure.

Étant donné que le NIC se trouve dans votre VNET, GitHub ne peut 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 sur les exécuteurs. GitHub ne nécessitera jamais de connexions entrantes sur ces machines.

Une carte d'interface réseau (NIC) permet à un ordinateur virtuel Azure (VM) de communiquer avec des ressources Internet, Azure sur site. 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 workflow GitHub Actions est déclenché.
2. Le service GitHub Actions crée un exécuteur.
3. Le service de l’exécuteur déploie la carte d’interface réseau (NIC) de l’exécuteur hébergé par GitHub dans votre VNet Azure.
4. L’agent de l’exécuteur prélève la tâche de workflow. Le service GitHub Actions place la tâche en file d’attente.
5. L’exécuteur renvoie les journaux d’activité au service GitHub Actions.
6. La carte d’interface réseau accède aux ressources locales.

À propos des régions prises en charge

Le GitHub Actions service prend en charge un sous-ensemble de toutes les régions qu’Azure fournit. Pour faciliter la communication entre le GitHub Actions service et votre sous-réseau, votre sous-réseau doit se trouver dans l’une des régions prises en charge.

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 du service GitHub Actions

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 entreprise.

Gestion des stratégies de configuration réseau des organisations de votre entreprise

Vous pouvez donner aux propriétaires d’organisation de votre entreprise la possibilité de configurer et de maintenir les configurations réseau au niveau de l’organisation pour les GitHub-runners hébergés.

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 ».

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

Pour utiliser les exécuteurs hébergés par GitHub avec un réseau virtuel Azure, vous devez configurer vos ressources Azure, puis créer une configuration 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.