Skip to main content
Nous publions des mises à jour fréquentes de notre documentation, et la traduction de cette page peut encore être en cours. Pour obtenir les informations les plus actuelles, consultez la documentation anglaise.

Cette version de GitHub Enterprise a été abandonnée le 2023-03-15. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

Connexion à un réseau privé

Vous pouvez connecter des exécuteurs hébergés par GitHub à des ressources sur un réseau privé, notamment des registres de packages, des gestionnaires de secrets et d’autres services locaux.

Remarque : Les exécuteurs hébergés sur GitHub ne sont pas pris en charge sur GitHub Enterprise Server. Vous pouvez voir plus d’informations sur le support futur planifié dans la GitHub public roadmap.

À propos de l’accès réseau des exécuteurs hébergés par GitHub

Par défaut, les exécuteurs hébergés par GitHub ont accès à l’Internet public. Toutefois, vous pouvez également souhaiter que ces exécuteurs accèdent aux ressources de votre réseau privé, par exemple un registre de packages, un gestionnaire de secrets ou d’autres services locaux.

Les exécuteurs hébergés par GitHub sont partagés entre tous les clients GitHub. Vous devez donc trouver un moyen de connecter votre réseau privé uniquement à vos exécuteurs pendant qu’ils exécutent vos workflows. Vous pouvez adopter différentes approches pour configurer cet accès, chacune ayant des avantages et des inconvénients distincts.

Utilisation de WireGuard pour créer un réseau de superposition

Si vous ne souhaitez pas gérer d’infrastructure distincte pour une passerelle API, vous pouvez créer un réseau de superposition entre votre exécuteur et un service de votre réseau privé, en exécutant WireGuard aux deux emplacements.

Cette approche présente divers inconvénients :

  • Pour atteindre l’instance de WireGuard s’exécutant sur votre service privé, vous avez besoin d’une adresse IP et d’un port bien connus que votre workflow peut référencer : il peut s’agir d’une adresse IP et d’un port publics, d’un mappage de port sur une passerelle réseau ou d’un service qui met à jour dynamiquement le DNS.
  • Dans la mesure où WireGuard ne prend pas en charge NAT-T (NAT Traversal) par défaut, vous devez identifier un moyen de fournir ce service.
  • Dans la mesure où cette connexion est de type un-à-un, si vous avez besoin de haute disponibilité ou d’un débit élevé, vous devez la superposer à WireGuard.
  • Vous devez générer et stocker de manière sécurisée les clés de l’exécuteur et de votre service privé. Dans la mesure où WireGuard utilise le protocole UDP, votre réseau doit prendre en charge le trafic UDP.

Il existe également certains avantages, car vous pouvez exécuter WireGuard sur un serveur existant pour ne pas avoir à gérer d’infrastructure distincte. De plus, il est bien pris en charge sur les exécuteurs hébergés par GitHub.

Exemple : Configuration de WireGuard

Cet exemple de workflow configure WireGuard pour la connexion à un service privé.

Pour cet exemple, l’instance de WireGuard s’exécutant sur le réseau privé présente la configuration suivante :

  • Adresse IP de réseau de superposition : 192.168.1.1
  • Adresse IP et port public : 1.2.3.4:56789
  • Clé publique : examplepubkey1234...

L’instance de WireGuard dans l’exécuteur GitHub Actions présente la configuration suivante :

  • Adresse IP de réseau de superposition : 192.168.1.2
  • La clé privée est stockée sous forme de secret GitHub Actions sous WIREGUARD_PRIVATE_KEY
name: WireGuard example

on:
  workflow_dispatch:

jobs:
  wireguard_example:
    runs-on: ubuntu-latest
    steps:
      - run: sudo apt install wireguard

      - run: echo "$" > privatekey

      - run: sudo ip link add dev wg0 type wireguard

      - run: sudo ip address add dev wg0 192.168.1.2 peer 192.168.1.1

      - run: sudo wg set wg0 listen-port 48123 private-key privatekey peer examplepubkey1234... allowed-ips 0.0.0.0/0 endpoint 1.2.3.4:56789

      - run: sudo ip link set up dev wg0

      - run: curl -vvv http://192.168.1.1

Pour plus d’informations, consultez Démarrage rapide de WireGuard ainsi que « Secrets chiffrés » afin de découvrir comment stocker les clés de manière sécurisée.

Utilisation de Tailscale pour créer un réseau de superposition

Tailscale est un produit commercial basé sur WireGuard. Cette option est très similaire à celle de WireGuard, à la différence près que Tailscale est une expérience produit plus complète et non un composant open source.

Ses inconvénients sont similaires à ceux de WireGuard : la connexion étant de type un-à-un, vous devrez peut-être effectuer du travail supplémentaire pour obtenir une haute disponibilité ou un débit élevé. Vous devez toujours générer et stocker les clés de manière sécurisée. Le protocole étant toujours UDP, votre réseau doit prendre en charge le trafic UDP.

Toutefois, il existe certains avantages par rapport à WireGuard : NAT-T (NAT Traversal) est intégré, vous n’avez donc pas besoin d’exposer un port au réseau Internet public. Il s’agit de loin de l’option la plus rapide pour être opérationnel, car Tailscale fournit un workflow GitHub Actions d’une seule étape pour se connecter au réseau de superposition.

Pour plus d’informations, consultez Tailscale GitHub Action ainsi que « Secrets chiffrés » afin de découvrir comment stocker les clés de manière sécurisée.