Comment isoler les PR externes sur un runner Mac de GitHub Actions en 2026 ?

Les PR externes ne devraient pas s’exécuter sur un Mac auto-hébergé qui conserve des secrets ou des états persistants. Cet article aide les mainteneurs, responsables sécurité et équipes plateforme à contrôler l’origine du code, les permissions, les identifiants et le nettoyage, puis à choisir une solution de repli si un contrôle échoue.

Une PR externe démarre sur un Mac qui conserve peut-être des fichiers, des processus ou des identifiants d’une exécution précédente.

Décision rapide — adapté si le code non fiable est dirigé vers un environnement isolé, sans secrets de publication, et si le nettoyage du Mac est vérifié en pratique. Inadapté si la PR peut atteindre un runner auto-hébergé durable qui conserve des clés, des données ou des processus persistants.

Cet audit s’adresse aux mainteneurs de projets ouverts qui doivent décider où exécuter les contributions externes. Il concerne aussi les responsables sécurité iOS qui séparent les tests de la signature et de la publication. Les équipes plateforme y trouveront des contrôles pour les groupes de runners, le nettoyage et la reprise des nœuds.

Les risques liés à l’origine du workflow

Une PR n’est pas seulement une différence de code à compiler. Lorsqu’un workflow se déclenche, GitHub Actions exécute une définition de workflow et les étapes qui lui sont associées. Si l’exécution arrive jusqu’à un runner auto-hébergé, le code lancé sur le Mac peut interagir avec les ressources accessibles au processus. L’examen de sécurité commence donc par la provenance du workflow, pas par le nom de l’étiquette du runner.

Il faut distinguer les situations que les équipes regroupent parfois sous le terme « PR » :

• Une branche de confiance déclenche un workflow contrôlé par le dépôt.
• Une PR interne vient d’un contributeur qui dispose déjà d’un niveau de confiance dans l’organisation.
• Une contribution externe peut inclure des changements de code et, selon la configuration, des changements de workflow proposés par une personne qui ne contrôle pas le dépôt.
• Un événement qui exécute un workflow avec des permissions privilégiées exige un examen particulier, notamment si ce workflow récupère ensuite le code de la PR et le lance.

La documentation de GitHub avertit que des workflows non fiables peuvent compromettre des runners auto-hébergés. Ces machines ne fournissent pas automatiquement la même séparation qu’un environnement isolé et éphémère. Le risque augmente lorsque le même Mac sert à plusieurs dépôts ou conserve son état entre les tâches. Nous considérons donc le droit d’exécuter une PR comme une décision d’accès au nœud, et non comme une simple préférence de compilation. Les recommandations officielles sur la sécurité des runners fournissent le cadre à appliquer.

Les événements doivent eux aussi être examinés séparément. Les restrictions associées aux PR provenant de forks, les événements déclarés dans le workflow et les changements de configuration influent sur ce qui est exécuté et sur les permissions disponibles. Consultez la documentation des événements qui déclenchent les workflows pour vérifier quel événement correspond au comportement réel du dépôt. Ne concluez pas qu’une PR est sans risque simplement parce qu’elle vient d’un fork : son code reste non fiable s’il est exécuté sur une machine persistante.

Les accès aux groupes et aux dépôts

Un contrôle fréquent, mais insuffisant, consiste à vérifier que le workflow indique la bonne étiquette de runner. Une étiquette aide GitHub Actions à sélectionner un runner correspondant à une demande. Elle ne constitue pas, à elle seule, une règle d’autorisation. Si un dépôt non prévu peut accéder au groupe qui contient le Mac, une étiquette spécifique ne l’empêche pas de demander ce runner.

Pour évaluer la configuration, partez de la portée réelle des accès :

• Identifiez le niveau auquel le runner est enregistré et le groupe auquel il appartient.
• Examinez les dépôts autorisés par la politique du groupe. Retirez ceux qui n’ont pas de raison opérationnelle d’y envoyer des tâches.
• Vérifiez les workflows qui peuvent demander ce groupe et les changements de configuration susceptibles d’élargir son utilisation.
• Contrôlez les règles après chaque modification des dépôts autorisés, des groupes ou des étiquettes.

Les règles de gestion des accès aux runners auto-hébergés décrivent comment limiter les dépôts qui peuvent utiliser un groupe. Confrontez votre configuration à la documentation sur les accès aux runners et à l’explication des groupes de runners.

Notre critère est concret. L’accès est refusé si un dépôt non approuvé peut envoyer une tâche vers le groupe, ou si personne ne peut justifier la présence d’un dépôt autorisé. Il est à revoir si l’accès paraît restreint, mais que l’équipe ne peut pas retrouver la politique appliquée. Il est acceptable pour poursuivre l’audit lorsque les dépôts autorisés sont identifiés, leur besoin est documenté et la sélection du runner ne repose pas sur les étiquettes seules.

Cette vérification relève de la sécurité d’un runner auto-hébergé GitHub Actions. Elle ne remplace cependant pas l’examen du workflow : un accès au dépôt correctement limité ne protège pas un Mac déjà exposé par une exécution précédente.

Les identifiants et les tâches de publication

Un runner n’est pas sûr simplement parce que les secrets ne sont pas visibles dans la sortie de compilation. Un processus peut accéder aux éléments que son contexte d’exécution lui rend disponibles. Il faut donc inventorier les secrets explicitement transmis au workflow, mais aussi ce qui reste présent sur le Mac : fichiers de configuration, trousseaux, variables d’environnement, outils de signature configurés et identifiants accessibles au compte utilisé par le service du runner.

La règle d’architecture à privilégier est de séparer les finalités :

• Les tests de PR compilent et valident le code sans clé de signature ni identifiant de publication.
• Les tâches de signature et de publication utilisent un workflow réservé à des événements et à des personnes de confiance.
• Le Mac destiné aux tests ne conserve pas les secrets de publication après une tâche.
• Si une contrainte impose un hôte partagé, les tâches non fiables ne doivent pas pouvoir être planifiées sur le runner qui détient les identifiants sensibles.

Les protections applicables dépendent du déclencheur, du contexte et de la configuration du dépôt. La documentation de GitHub sur l’utilisation des secrets dans les workflows décrit les conditions dans lesquelles ils sont disponibles et la façon de les référencer. Vérifiez ce que le workflow peut réellement utiliser, plutôt que de déduire l’absence d’accès du fait qu’aucune valeur n’apparaît dans les journaux.

Portez une attention particulière à pull_request_target. Cet événement peut exécuter un workflow dans un contexte privilégié par rapport à une PR classique. Le danger apparaît notamment lorsqu’un workflow de confiance récupère ensuite le code de la PR et l’exécute avec ces permissions. Suivez l’avertissement officiel sur l’utilisation sécurisée de pull_request_target et ne lancez pas de code non fiable dans un contexte qui peut atteindre des secrets.

Le contrôle des permissions doit inclure le jeton fourni au workflow, les secrets explicitement référencés et les identifiants préexistants sur le nœud. Les recommandations de sécurité des workflows expliquent aussi les précautions à prendre pour éviter qu’un workflow ou une dépendance transforme un accès légitime en voie d’exfiltration. L’absence d’une clé dans les journaux ne prouve donc pas qu’un processus exécuté sur le Mac ne pouvait pas y accéder.

Le nettoyage et l’état persistant du Mac

Même si une tâche ne reçoit pas de clé, elle peut modifier les fichiers qu’un job ultérieur retrouvera. La suppression de l’espace de travail ne garantit pas à elle seule l’effacement des caches, des fichiers temporaires, des données de compilation, des services en arrière-plan ou des processus lancés en dehors de la durée prévue du job. Sur un Mac réutilisé, la frontière importante est l’état qui reste après la fin de l’exécution.

Vérifiez les éléments suivants pour la configuration réelle :

• Les répertoires de travail sont supprimés ou recréés depuis un état maîtrisé.
• Les caches utilisés par les tests sont séparés des données sensibles et ne peuvent pas être modifiés puis réutilisés sans contrôle.
• Les fichiers temporaires, profils de signature et journaux contenant des informations confidentielles sont traités selon une règle définie.
• Les processus et services démarrés pendant la tâche s’arrêtent effectivement, y compris lorsqu’un job échoue ou est annulé.
• Le compte système qui exécute le runner ne peut pas lire des données sans rapport avec la CI.

Les scripts exécutés avant et après une tâche peuvent participer au nettoyage, mais leur présence dans la configuration ne prouve pas qu’ils fonctionnent dans toutes les conditions d’échec. La documentation GitHub sur les scripts de pré-exécution et de post-exécution précise leur intégration au runner. Complétez cette lecture par une validation sur le Mac : une commande de suppression déclarée dans le dépôt ne démontre pas que les processus, les caches et les permissions ont retrouvé l’état attendu.

Pour tester sans exposer de secret, lancez une tâche non sensible conçue pour laisser des traces contrôlées : un fichier temporaire dans le répertoire de travail, un processus de test identifiable et une donnée de cache sans valeur. Après l’exécution, vérifiez sur le nœud que ces éléments ont disparu et que le runner peut reprendre une tâche saine. Réalisez aussi l’essai après un échec ou une annulation si ces chemins font partie de votre usage. Consignez le résultat, le compte utilisé et les contrôles effectués. Un examen du YAML seul n’est pas un test de nettoyage.

Point de vigilance. Si l’état du Mac après une exécution non fiable ne peut pas être confirmé, ne lui confiez pas immédiatement une tâche de publication. Retirez-le du routage, restaurez-le selon votre procédure de confiance, puis faites valider sa remise en service.

Outil de décision pour le routage des PR

Cochez chaque condition en vous fondant sur la configuration et sur un test réel. Un contrôle réussi ne compense pas l’échec d’un autre. Dès qu’une condition de blocage est présente, la tâche non fiable ne doit pas être envoyée sur le Mac concerné.

• [ ] Origine identifiée : le workflow et le code exécuté proviennent d’une source dont le niveau de confiance est documenté. Si la provenance est externe ou incertaine, choisissez un environnement destiné aux contributions non fiables.
• [ ] Accès limité : seuls les dépôts qui ont un besoin validé peuvent utiliser le groupe du runner. Si un dépôt non approuvé peut le demander, bloquez le routage et corrigez la politique d’accès.
• [ ] Étiquettes traitées comme du routage : aucune équipe ne considère l’étiquette du runner comme une mesure d’autorisation. Si l’accès dépend seulement d’une étiquette, le contrôle échoue.
• [ ] Secrets séparés : les tâches de test ne peuvent pas atteindre les clés de signature, les identifiants de publication ou les données équivalentes. Si une clé est accessible depuis le contexte de la PR, séparez les tâches avant de réactiver le runner.
• [ ] État du nœud vérifié : un essai non sensible confirme la suppression des fichiers, caches et processus prévus. Si le résultat est incertain ou si un processus persiste, retirez le nœud du service et restaurez-le.
• [ ] Reprise attribuée : les personnes chargées de bloquer le routage et d’autoriser la remise en service sont identifiées. Sans responsable ni procédure de restauration, ne considérez pas le contrôle comme terminé.

Décision : si toutes les conditions sont remplies, le routage peut être envisagé dans le périmètre isolé destiné aux PR. Si l’accès est trop large, si un secret est atteignable ou si le nettoyage échoue, dirigez les contributions non fiables vers un environnement distinct et limitez le runner auto-hébergé aux workflows de confiance jusqu’à correction et nouvelle vérification.

Reprise et audit continu

La reprise ne consiste pas à relancer simplement le workflow. Lorsque l’accès était trop large, que des identifiants étaient disponibles ou que le nettoyage n’a pas été démontré, empêchez d’abord de nouvelles tâches d’atteindre le Mac concerné. Examinez les workflows et les journaux utiles sans y inscrire de secrets, retirez les identifiants qui ont pu être exposés selon la procédure interne, puis restaurez le nœud depuis un état de confiance.

Ne réutilisez pas le runner tant que les contrôles ayant échoué n’ont pas été corrigés et vérifiés à nouveau. Si l’incident peut concerner plusieurs workflows, examinez les dépôts qui utilisent le même groupe, pas uniquement la PR à l’origine du signalement. Consignez la cause, les actions de restauration, le résultat des vérifications et la personne qui a autorisé la remise en service.

L’audit doit garder une trace de la décision, pas seulement du résultat. Notez quels dépôts peuvent utiliser le groupe, quels types de contributions sont acceptés sur le Mac, quels secrets sont réservés à la publication, comment le nettoyage est testé et qui est responsable de cette revue. Cette trace aide à repérer une dérive lorsqu’un workflow change ou qu’un nouveau dépôt rejoint le périmètre.

Une réussite ponctuelle indique que le scénario testé s’est terminé comme prévu ; elle ne garantit pas la sécurité continue du runner. La configuration peut évoluer, une nouvelle étape peut demander des permissions supplémentaires et une tâche peut échouer par un chemin non couvert par l’essai. Répétez l’examen après une modification des accès, du workflow ou de la procédure de nettoyage. Cette liste est un cadre opérationnel : elle ne certifie pas une architecture et ne prouve pas, à elle seule, la conformité à une norme ou à une réglementation.

FAQ sur les PR et les runners Mac

Exécution des PR externes

Une PR externe peut techniquement être dirigée vers un runner auto-hébergé si le workflow et les règles d’accès l’autorisent. Ce routage ne constitue pas une preuve de sécurité. Pour une contribution non fiable, utilisez un environnement isolé, sans secrets sensibles et sans état résiduel réutilisable ; sinon, refusez son routage vers le Mac partagé.

Restriction des dépôts autorisés

La restriction s’effectue dans la politique d’accès du groupe de runners : seuls les dépôts ayant un besoin justifié doivent être autorisés. Les étiquettes aident à sélectionner un runner compatible, mais ne filtrent pas à elles seules les dépôts. Vérifiez aussi les workflows qui demandent le groupe et les changements susceptibles d’élargir les accès.

Protection des clés de signature

Les tests de PR et la publication doivent relever de workflows séparés. N’exposez pas les clés de signature à une tâche qui exécute du code non fiable. Contrôlez les références aux secrets dans le workflow, mais également les trousseaux, les fichiers et les variables accessibles au compte du runner. Un secret absent des journaux peut rester accessible sur le Mac.

Vérification après une tâche

Après une exécution non fiable, vérifiez le répertoire de travail, les caches, les fichiers temporaires, les processus persistants et les éléments accessibles au compte du runner. Confirmez le résultat par un test non sensible sur le nœud, pas seulement par la lecture du YAML. En cas de doute ou d’échec du nettoyage, retirez le runner du routage et restaurez son état avant toute nouvelle tâche de confiance.

Choisir un environnement adapté au besoin

Un Mac auto-hébergé durable peut convenir à des compilations régulières, mais il faut gérer l’état persistant, les mises à jour, le nettoyage et la séparation des clés. Un environnement local évite parfois une partie de la gestion distante, mais mobilise une machine et ne sépare pas automatiquement les tâches non fiables des données présentes. Dans les deux cas, une machine qui conserve des secrets ou des fichiers entre les exécutions n’est pas un bac à sable par défaut.

Si les contributions externes n’ont pas besoin de signer ou de publier une application, réserver un environnement distinct à leur validation est souvent plus simple que de durcir un runner de publication partagé. Si un Mac distant n’est nécessaire que pour une période de validation ou un chantier CI, examinez les options de location de Mac proposées par ZekVPS, puis vérifiez les modalités d’accès, de nettoyage et de remise en état avant d’y exécuter du code non fiable. Les équipes qui comparent une implantation précise peuvent également consulter la page de location de Mac au Japon.

La location ne garantit pas à elle seule l’isolation. Elle peut toutefois éviter de mobiliser durablement une machine locale pour un besoin ponctuel, à condition de confirmer les limites réelles de l’environnement choisi. Pour une charge stable et sensible, ou lorsqu’un accès physique particulier est nécessaire, conserver et administrer un Mac dédié peut être plus adapté. Dans tous les cas, commencez par vérifier les accès du runner actuel et la politique applicable aux PR externes ; ne déplacez une tâche qu’après avoir établi que le nouvel environnement répond effectivement à vos exigences de séparation.