Symptôme — Un build doit joindre un registre privé ou respecter une liste blanche d’adresses IP.

Réponse rapide — GitHub précise que les macOS larger runners ne fournissent pas d’adresse IP statique ni Azure private networking. Si votre tâche exige un accès direct au réseau interne ou une IP fixe, ne les choisissez pas par défaut : vérifiez d’abord les capacités documentées, puis testez une passerelle autorisée ou évaluez un Mac autogéré placé sur le chemin réseau requis【limites réseau des runners hébergés】.

Cet article s’adresse à vous si :
- vous définissez les règles réseau pour un dépôt privé, un registre de paquets ou un service interne ;
- vous répartissez les tâches d’une chaîne CI iOS/macOS entre runners hébergés et Mac autogérés ;
- vous devez arbitrer entre contrôle réseau, responsabilité d’exploitation et risque lié aux secrets.

Scénario : le build ne dépend que de ressources accessibles publiquement

Un runner hébergé peut être un candidat lorsque le code source, les dépendances et les services utilisés par le build sont joignables depuis son environnement. « Public » doit toutefois décrire le chemin d’accès, pas seulement la visibilité du dépôt : un dépôt privé peut être autorisé par un jeton, tandis qu’un registre ou une API publique peut encore exiger une authentification.

Commencez par relever les dépendances réellement appelées par le workflow : dépôt, sous-modules, registre de paquets, téléchargement d’outils, service de test et destination des artefacts. Pour chaque ressource, consignez le nom d’hôte, le mécanisme d’authentification et l’étape qui la contacte. Les journaux du workflow et la liste des dépendances constituent une meilleure preuve qu’une supposition fondée sur le fait que le projet « fonctionne sur un poste de développeur ».

Si le build ne requiert ni route privée ni source IP stable, un runner hébergé mérite d’être évalué. Cela ne signifie pas qu’il convient à toutes les tâches d’entreprise : les contrôles d’accès, le périmètre des secrets et les autorisations de publication restent à valider dans la configuration du dépôt et de l’organisation. La documentation décrit les possibilités de gestion des larger runners et de contrôle de leur accès【gestion des larger runners】【contrôle d’accès et configuration réseau】.

Besoin du build Première option à évaluer Preuve attendue avant adoption
Dépendances accessibles depuis le runner avec authentification adaptée macOS larger runner hébergé Workflow réussi et journaux d’accès aux ressources
Route privée directe nécessaire Mac autogéré disposant réellement de cette route Tests de résolution, de connexion et d’authentification depuis le runner
Source IP fixe exigée par le pare-feu Mac autogéré ou autre chemin validé par l’équipe réseau Adresse observée côté service et règle de filtrage vérifiée
Quelques appels internes seulement Intermédiaire approuvé, si le service le permet Test de bout en bout, contrôle d’identité et traces d’audit

Les macOS larger runners peuvent-ils accéder à un registre privé de paquets ? Ils peuvent accéder à une ressource seulement si le chemin réseau et l’authentification nécessaires sont effectivement disponibles pour ce runner. Ne déduisez pas l’accès à un réseau d’entreprise du fait qu’un jeton autorise le téléchargement d’un paquet. Vérifiez le nom d’hôte, le mode d’authentification, les règles d’accès et le résultat d’un workflow exécuté dans le contexte réel.

Scénario : le build doit joindre un dépôt ou un service privé

Distinguez d’abord les dépendances « privées parce qu’elles nécessitent une identité » de celles « privées parce qu’elles ne sont joignables que depuis un réseau donné ». Un jeton peut authentifier une requête vers un service accessible, mais il ne crée pas une route vers un hôte interne. À l’inverse, une route réseau ne donne pas le droit de lire le dépôt ou le registre.

Dessinez le trajet de chaque requête avant de modifier le workflow. Indiquez le point de départ, la destination, le sens de la connexion, l’identité présentée et l’endroit où la règle d’accès est appliquée. Faites cet exercice pour les registres privés, les dépôts de sous-modules, les serveurs d’artefacts, les services de secrets et les API internes. Un build peut réussir la compilation puis échouer au moment de télécharger un outil ou de publier une archive ; l’étape concernée est une donnée d’architecture, pas un simple détail de diagnostic.

Pour les larger runners macOS, confrontez chaque besoin aux capacités explicitement documentées pour ce type de runner. Les mécanismes décrits pour une autre famille de runners hébergés ne sont pas automatiquement disponibles sur macOS. La documentation de contrôle des larger runners aide à vérifier les réglages applicables, mais l’acceptation doit venir d’un essai sur le runner ciblé【options de contrôle des larger runners】.

Question à trancher Indice à recueillir Décision si la preuve manque
Le service est-il publiquement joignable ou seulement depuis le réseau de l’entreprise ? Chemin réseau attendu et journaux du service Traiter l’accès comme non établi
L’accès est-il accordé par identité, par adresse source ou par les deux ? Configuration d’authentification et règle du pare-feu Ne pas confondre jeton valide et connectivité
Le workflow peut-il obtenir le secret sans l’exposer aux tâches non fiables ? Portée du secret, événements déclencheurs et journaux Isoler la tâche ou revoir le déclenchement
Le service enregistre-t-il une preuve exploitable de l’accès ? Journaux d’accès rapprochés de l’exécution CI Reporter la mise en production jusqu’à l’observabilité

Cette séparation évite une erreur fréquente de conception : tester une URL depuis un poste connecté au réseau, puis supposer que le runner disposera de la même route. L’environnement, l’identité et l’origine réseau doivent correspondre au contexte de production du workflow.

Scénario : le pare-feu exige une adresse IP source stable

GitHub Actions macOS larger runners prennent-ils en charge une liste blanche IP statique ? La documentation GitHub indique que les macOS larger runners ne fournissent pas d’adresses IP statiques. Elle indique également qu’Azure private networking n’est pas disponible pour ces runners【référence des capacités réseau des runners hébergés】. Si le service interne n’accepte que des sources fixes, considérez cette exigence comme un blocage tant qu’une solution propre à votre runner n’a pas été démontrée.

Avant de changer de plateforme, demandez à l’équipe réseau ce que la règle protège exactement. Une liste blanche peut viser une adresse source, mais la politique peut aussi dépendre d’une identité, d’un certificat, d’un relais ou d’une combinaison de contrôles. L’étiquette « IP autorisée » ne suffit pas à décrire le besoin. Faites confirmer par le propriétaire du service quelle adresse il observe, à quel point du trajet la règle s’applique et si une autre méthode d’authentification est acceptable.

N’étendez pas à macOS les capacités documentées pour des runners Linux ou Windows. La documentation de l’accès réseau des larger runners doit être lue dans son périmètre, avec la plateforme et le type de runner concernés【configuration réseau et accès aux larger runners】. Si l’IP fixe est impérative, évaluez un Mac autogéré situé sur un réseau dont l’adresse et les règles sont administrées par votre entreprise, ou une voie d’accès alternative approuvée et testée.

L’option autogérée a des avantages et des coûts opérationnels. Vous pouvez aligner le chemin réseau sur les règles internes, mais vous prenez aussi en charge la maintenance de l’hôte, les mises à jour, la surveillance, les identifiants et la reprise après incident. Une machine accessible depuis le réseau interne n’est pas automatiquement isolée des tâches qui s’exécutent dessus.

Scénario : l’accès privé peut passer par un intermédiaire contrôlé

Une passerelle, une authentification fondée sur l’identité du workflow ou une solution de réseau superposé peut convenir à certains services ; aucun de ces termes ne prouve à lui seul que le runner visé pourra joindre votre réseau. Décidez service par service. Vérifiez la destination permise, les identifiants transmis, le chemin de sortie, les journaux disponibles et le comportement en cas d’échec.

GitHub documente une approche OIDC pour authentifier des appels vers une passerelle API. Cette piste ne donne pas automatiquement une route réseau vers chaque service interne : elle suppose que la passerelle soit joignable et qu’elle puisse joindre la destination selon vos règles【authentification OIDC d’une passerelle API】. Validez notamment la portée du jeton, les audiences acceptées, les autorisations de la passerelle et les traces conservées. Ne placez pas un secret durable dans un workflow comme substitut à une stratégie d’identité.

GitHub publie également des indications relatives à WireGuard et aux réseaux superposés pour des runners hébergés. Vous devez vérifier le champ d’application exact de ces indications avant de les appliquer à un runner macOS larger : si la documentation ne confirme pas leur compatibilité avec votre cible, traitez-la comme une hypothèse à tester, pas comme une fonctionnalité acquise【connexion à un réseau privé avec WireGuard】.

Azure private networking doit faire l’objet de la même prudence. La documentation GitHub en décrit le périmètre pour les runners hébergés ; ne transposez pas cette capacité aux macOS larger runners lorsque la documentation indique qu’elle n’y est pas disponible【périmètre d’Azure private networking】. Dans votre dossier d’architecture, distinguez donc une solution documentée pour le type de runner choisi, une solution dont la compatibilité reste à valider et une solution écartée.

Scénario : le Mac autogéré doit porter le chemin réseau

Un runner Mac autogéré peut être placé dans un environnement disposant de l’accès voulu, mais son enregistrement dans GitHub ne lui confère pas automatiquement des droits sur le réseau interne. Le résultat dépend de son emplacement, des routes configurées, du filtrage, de la résolution DNS et de l’identité utilisée par le service. Vous devez tester ces éléments depuis l’hôte et depuis le workflow concerné.

La documentation des runners autogérés décrit les exigences de communication entre le runner et GitHub【communications réseau des runners autogérés】. Cela ne remplace pas la validation de vos flux internes. Préparez un workflow d’essai qui vérifie les hôtes requis, les connexions attendues et l’authentification, sans afficher de secrets ni envoyer de données sensibles dans les journaux.

Faut-il choisir un Mac autogéré lorsque la CI iOS doit joindre le réseau interne de l’entreprise ? Choisissez cette piste si la route interne ou l’adresse source fixe est une contrainte confirmée et si votre équipe peut assumer l’exploitation de l’hôte. Sinon, comparez une passerelle validée ou le découpage du workflow. Dans tous les cas, l’accès réseau ne constitue pas une isolation de sécurité : les déclencheurs acceptés, les droits du dépôt et la confiance accordée aux contributions doivent être examinés séparément.

Sur un Mac autogéré, prévoyez des responsabilités explicites pour les comptes locaux, les mises à jour, le stockage temporaire, l’effacement des espaces de travail, les certificats et les identifiants de signature. Les workflows qui exécutent du code non fiable demandent une attention particulière : si une tâche peut lire les secrets ou atteindre des services internes, sa permission d’exécution doit être limitée en conséquence. Une connexion distante à l’hôte ne garantit pas davantage que deux exécutions soient isolées.

Scénario : une chaîne mixte peut séparer compilation et accès interne

Si seules certaines étapes ont besoin du réseau privé, vous pouvez envisager de séparer les tâches. Par exemple, un travail de compilation et de tests utilisant des ressources accessibles peut être évalué sur un runner hébergé, tandis qu’une étape nécessitant un service interne est affectée à un environnement autorisé. Cette séparation n’est utile que si les résultats transmis entre tâches sont maîtrisés.

Définissez à l’avance les artefacts transférés, leur intégrité, l’identité qui autorise leur publication et l’endroit où s’effectue la signature. Un paquet produit par une tâche ne devient pas fiable parce qu’il est transmis à une autre. Validez le chemin réel, de l’exécution initiale à l’archive signée, et assurez-vous que les droits de publication ne sont pas accordés aux étapes qui n’en ont pas besoin.

Une passerelle ou un réseau superposé peut-il remplacer l’accès direct ? Cela dépend du service, du chemin et des règles de sécurité. Testez un workflow réel et vérifiez séparément la résolution du nom, la connexion à la destination, l’identité acceptée et l’enregistrement de l’accès. Si un de ces contrôles n’est pas démontré, inscrivez le point comme non validé ; ne fondez pas votre décision sur une simple possibilité décrite pour une autre catégorie de runner.

Utilisez cette checklist avant de figer l’architecture :

  • [ ] Inventoriez les dépôts, registres, API, services de secrets et destinations d’artefacts appelés par chaque tâche.
  • [ ] Classez chaque ressource selon son besoin de route privée, d’identité, d’adresse source autorisée ou de combinaison de contrôles.
  • [ ] Vérifiez dans la documentation la capacité réseau correspondant exactement au type de runner macOS retenu.
  • [ ] Exécutez un workflow d’essai qui reproduit les accès nécessaires, sans exposer de secrets dans les journaux.
  • [ ] Comparez les résultats du workflow aux journaux du pare-feu, de la passerelle ou du service cible.
  • [ ] Vérifiez les artefacts transmis entre tâches, les droits de signature et les autorisations de publication.
  • [ ] Attribuez un responsable aux mises à jour, à la surveillance, aux identifiants et à la reprise de chaque hôte autogéré.
  • [ ] Consignez les contraintes non satisfaites et reportez le choix de production tant qu’elles restent bloquantes.

Votre décision finale doit nommer les tâches exécutées sur chaque type de runner, les flux réseau autorisés, les identités utilisées, les preuves d’acceptation et les éléments encore à tester. Cette fiche évite de confondre accès réseau, autorisation applicative et isolation de l’hôte.

Si votre solution actuelle repose sur des macOS larger runners alors que le pare-feu exige une IP stable, elle ne répond pas à cette contrainte documentée ; si elle dépend d’un accès privé non testé, elle laisse aussi un risque de panne et de diagnostic tardif. Un Mac autogéré peut répondre au besoin de chemin réseau, mais vous devrez en administrer l’accès et la sécurité. Pour un essai temporaire ou un environnement de validation, vous pouvez examiner les Mac mini distants proposés par MACCOME et vérifier l’adéquation réseau avant de l’intégrer à la CI. Consultez également la présentation française de MACCOME pour comparer les options disponibles, sans considérer une route privée ou une IP fixe comme acquise tant qu’elle n’a pas été confirmée pour votre cas.