Skip to main content

À propos du réseau privé Azure pour les exécuteurs hébergés par GitHub dans votre organisation

Vous pouvez créer une configuration réseau privé pour votre organisation afin d’utiliser des exécuteurs hébergés par GitHub dans votre (vos) réseau(x) virtuel(s) Azure (VNET).

Qui peut utiliser cette fonctionnalité ?

Les propriétaires d’organisation disposant du plan GitHub Team peuvent configurer la mise en réseau privée Azure pour les exécuteurs hébergés par GitHub au niveau de l’organisation.

À 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.com 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.

Diagramme de l’architecture de communication réseau entre les réseaux GitHub et vos réseaux privés. Le diagramme décrit chaque étape de la connexion des exécuteurs hébergés par GitHub à un VNet Azure. Chaque étape est numérotée et les nombres correspondent aux descriptions numérotées des étapes répertoriées sous le diagramme.

  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 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, votre sous-réseau doit se trouver dans l’une des régions prises en charge suivantes.

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

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

  • EastUs
  • WestUs
  • NorthCentralUs
  • SouthCentralUs

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

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.

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