À propos du réseau privé Azure pour les exécuteurs hébergés par GitHub
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 des exécuteurs de plus grande taille avec un VNet Azure
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 « À propos des exécuteurs de plus grande taille ».
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 « À propos des exécuteurs de plus grande taille ».
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.
Note
Plusieurs NIC peuvent apparaître pour un seul travail dans votre abonnement, car le service GitHub Actions surprovisionne les ressources pour exécuter des travaux. Une fois qu’un exécuteur est inactif, le service GitHub Actions déprovisionne automatiquement la ressource et supprime la NIC correspondante.
- Un workflow GitHub Actions est déclenché.
- Le service GitHub Actions crée un exécuteur.
- 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.
- 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.
- L’exécuteur renvoie les journaux d’activité au service GitHub Actions.
- La carte d’interface réseau accède aux ressources locales.
À propos des régions prises en charge
Le service GitHub Actions prend en charge un sous-ensemble de toutes les régions qu’Azure fournit. Pour faciliter la communication entre le service GitHub Actions et votre sous-réseau, celui-ci doit se trouver dans l'une des régions prises en charge.
Note
Si vous utilisez différente sur GHE.com, les régions prises en charge sont différentes. Consultez « Détails du réseau pour GHE.com ».
Les régions suivantes sont prises en charge par GitHub.com.
EastUs
EastUs2
WestUs2
WestUs3
CentralUs
NorthCentralUs
AustraliaEast
JapanEast
FranceCentral
GermanyWestCentral
NorthEurope
NorwayEast
SwedenCentral
SwitzerlandNorth
UkSouth
SoutheastAsia
KoreaCentral
La mise en réseau privée Azure prend en charge les exécuteurs GPU dans les régions suivantes.
EastUs
WestUs
NorthCentralUs
La mise en réseau privée Azure prend en charge les exécuteurs arm64 dans les régions suivantes.
EastUs
EastUs2
WestUs2
WestUs3
NorthCentralUs
Si votre région souhaitée n’est pas prise en charge, envoyez une demande de nouvelle disponibilité de région dans ce formulaire GitHub. Vous pouvez également utiliser l’appairage de réseaux virtuels mondiaux pour connecter des réseaux virtuels entre les différentes régions Azure. Pour plus d’informations, consultez le document Peering de réseau virtuel dans la documentation Azure.
À propos des autorisations de service de 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.
Utilisation des exécuteurs hébergés par 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 d’un réseau privé pour les exécuteurs hébergé sur GitHub dans votre entreprise ».
Pour connaître les procédures de configuration du réseau privé Azure au niveau de l’enterprise , voir "Configuration d’un réseau privé pour les exécuteurs hébergé sur GitHub dans votre entreprise".
Pour connaître les procédures de configuration du réseau privé Azure au niveau de l'organisation, voir "Configuration d'un réseau privé pour les exécuteurs hébergés sur GitHub dans votre organisation".