Pour vos workflows GitHub Actions macOS Runner, choisissez un hôte permanent uniquement pour du code de confiance et des accès strictement limités ; pour du code externe ou des secrets de publication, préférez un environnement isolé et éphémère. Cette semaine, vérifiez les événements qui lancent vos tâches, les dépôts autorisés sur le Runner et les identifiants disponibles avant de modifier votre infrastructure.

Cet article s’adresse aux développeurs indépendants qui construisent des apps iOS et évaluent les coûts de maintenance d’un Runner réutilisable.
Il concerne aussi les petites équipes qui doivent séparer compilation courante et publication signée.
Les responsables d’automatisation y trouveront une méthode pour contrôler les accès et les traces laissées sur l’hôte.

01

La provenance du code détermine le cycle de vie du Runner

Un Runner permanent n’est pas automatiquement inadapté. Il convient lorsque les tâches proviennent d’un dépôt privé maîtrisé, que les personnes autorisées à modifier les workflows sont identifiées et que les droits du Runner sont limités à ce périmètre. Il est alors plus simple de conserver un environnement de compilation disponible et de maintenir les outils nécessaires au projet.

La limite apparaît quand le même hôte exécute du code dont vous ne contrôlez pas les changements. Un workflow peut lancer des scripts du dépôt, des outils de construction ou des actions tierces. Si une tâche hostile ou compromise atteint la machine, le risque ne se limite pas aux fichiers du répertoire de travail : les autres données accessibles au compte du Runner et l’état persistant de l’hôte doivent également être pris en compte. La documentation de sécurité GitHub Actions sur les Runner auto-hébergés avertit que ces machines peuvent être exposées au code exécuté par les workflows.

Il faut distinguer deux choses souvent confondues : le processus Runner qui reste en ligne et les données qu’une tâche laisse derrière elle. Le premier peut être réutilisé sans que l’arborescence du projet soit intacte ; inversement, nettoyer le répertoire courant ne signifie pas que le compte, le trousseau, les caches ou les processus lancés en arrière-plan ont été remis à un état sain.

Un Runner auto-hébergé peut-il exécuter plusieurs tâches successives ? Oui, un Runner permanent peut être réutilisé pour des tâches successives, sous réserve de son état et de la configuration du workflow. Cela ne constitue pas une garantie d’effacement entre les tâches. Si vous le réutilisez, traitez chaque exécution comme une possibilité de résidu : contrôlez les fichiers, les processus, les journaux locaux et les identifiants accessibles, au lieu de vous fier à la seule présence du Runner dans l’interface.

Pour décider si cette réutilisation est acceptable, examinez les conditions d’accès et les traces observables. La référence GitHub sur les Runner auto-hébergés décrit leur fonctionnement et les options de gestion ; les journaux du Runner et l’historique des tâches permettent ensuite de confronter cette configuration à ce qui s’est réellement exécuté.

02

Les Pull Requests n’ont pas toutes le même niveau de confiance

Une Pull Request issue d’une branche interne peut être soumise par une personne autorisée, mais l’origine interne ne suffit pas à prouver que son contenu est digne de confiance. Un script modifié dans la branche peut s’exécuter pendant la compilation. Examinez donc les droits du contributeur, les fichiers modifiés et la capacité du workflow à accéder à des ressources sensibles.

Les contributions provenant d’un dépôt externe demandent davantage de prudence. Par défaut, GitHub applique des restrictions particulières aux workflows déclenchés par des Pull Requests de forks, mais les paramètres du dépôt et l’événement choisi restent déterminants. Consultez la documentation des événements qui déclenchent les workflows avant de conclure qu’une tâche ne dispose ni de secrets ni de permissions d’écriture.

Une Pull Request externe peut-elle utiliser votre Mac auto-hébergé ? Techniquement, cela dépend de la configuration qui rend les Runner accessibles et du workflow déclencheur ; du point de vue opérationnel, ne l’autorisez pas sur un hôte qui contient des données ou des identifiants dont la Pull Request ne devrait pas pouvoir se rapprocher. Pour les contributions non fiables, privilégiez un environnement d’exécution isolé, ou n’exécutez pas le workflow sur votre Mac permanent.

Soyez particulièrement attentif à pull_request_target. Cet événement s’exécute dans le contexte du dépôt de base et peut disposer d’autorisations différentes de celles d’un workflow pull_request. Si vous y ajoutez du code ou des scripts provenant de la Pull Request, vous risquez de combiner une contribution non fiable avec un contexte privilégié. Les consignes de sécurisation de pull_request_target expliquent cette frontière. Ne changez pas d’événement simplement pour faire fonctionner un Runner : vérifiez d’abord quels contenus sont exécutés et quels droits leur sont accordés.

Les Runner groups apportent un contrôle utile, à condition de les configurer selon le principe du moindre accès. Un groupe peut limiter les dépôts autorisés à utiliser certains Runner ; vérifiez cette liste plutôt que de supposer que le nom du groupe suffit à isoler les tâches. La gestion de l’accès aux Runner auto-hébergés et la présentation des groupes de Runner détaillent les règles à contrôler.

03

Comparez les options selon le code et les droits disponibles

Le tableau sert à choisir un cycle de vie selon le scénario, pas à comparer la vitesse ou le coût des machines. Un Runner temporaire réduit la persistance entre les tâches, mais ne rend pas automatiquement sûr tout workflow qui lui est envoyé.

Scénario Option à privilégier Atout principal Limite à vérifier
Compilation d’un dépôt privé maîtrisé Runner permanent dédié au dépôt ou au groupe autorisé Environnement disponible et réutilisable État résiduel, accès du compte et scripts exécutés
Pull Request d’un contributeur externe Exécution hébergée ou environnement isolé et temporaire Réduit l’exposition d’un hôte persistant Secrets, permissions du jeton et données de diagnostic
Compilation courante sans signature Environnement séparé du processus de publication Limite l’accès aux clés de distribution Dépendances et fichiers temporaires restent à contrôler
Signature et envoi d’une version Tâche de publication protégée, sur un environnement réservé Accès aux identifiants réservé à la publication Un Runner dédié n’est pas isolé par sa seule étiquette
Aucune capacité à isoler du code non fiable Ne pas lancer ce code sur le Mac concerné Évite d’exposer cet hôte à la tâche Il faut choisir un autre mode d’exécution

Dans la configuration du workflow, attribuez explicitement les permissions dont la tâche a besoin. La syntaxe GitHub permet de définir les droits de GITHUB_TOKEN avec permissions, par exemple contents: read pour limiter l’accès aux contenus lorsque les autres droits ne sont pas requis. Consultez la référence de syntaxe des workflows et des permissions et vérifiez les paramètres effectifs du dépôt : une ligne de configuration ne remplace pas l’examen des permissions au niveau du dépôt ou de l’organisation.

Un répertoire de travail supprimé n’est pas une preuve d’isolation. Le trousseau macOS, les fichiers hors de ce répertoire, les processus persistants et les journaux locaux peuvent relever d’autres contrôles.

04

La signature doit rester hors du chemin de compilation ordinaire

Les certificats, clés privées, profils de provisionnement et identifiants d’App Store Connect n’ont pas à être accessibles à chaque compilation. Séparez la tâche qui compile et teste l’application de celle qui signe ou téléverse une version. Si une compilation de Pull Request n’a besoin que de produire des artefacts de test, ne lui donnez pas les secrets réservés à la publication.

Faut-il conserver les clés de signature iOS sur un Runner macOS permanent ? Évitez de les rendre accessibles à un Runner qui exécute aussi du code externe ou des tâches générales. Une machine réservée à la publication et accessible à un dépôt de confiance réduit le nombre de workflows concernés, mais ne constitue pas une garantie absolue : les personnes autorisées à modifier les fichiers de workflow et les commandes de publication restent importantes.

Sur macOS, vérifiez le trousseau utilisé par le compte d’exécution et la manière dont les secrets sont injectés, utilisés puis retirés. Ne laissez pas une tâche de compilation accéder à un trousseau déjà déverrouillé pour signer une autre version. Dans les journaux, masquez les valeurs sensibles et contrôlez que les commandes ne les impriment pas indirectement. Conservez une trace des autorisations accordées et des modifications apportées au workflow de publication ; ces éléments permettent de comprendre qui a pu lancer la tâche et dans quel contexte.

Pour une équipe, la séparation peut prendre la forme de Runner groups différents, de workflows distincts ou d’un environnement de publication soumis à une validation. Le choix dépend de vos paramètres GitHub et de votre modèle d’accès. Dans tous les cas, vérifiez que le Runner de compilation ne peut pas recevoir par erreur un travail de publication, et que celui de publication n’est pas sélectionné par un workflow largement accessible.

05

Vérifiez l’hôte, le nettoyage et les journaux après chaque changement

Une procédure de contrôle vaut mieux qu’une règle générale de nettoyage. Avant d’autoriser un workflow sur un Mac permanent, réalisez les vérifications suivantes et conservez les résultats utiles sans exposer de secrets.

  • Cartographiez les événements. Pour chaque workflow, relevez l’événement déclencheur, la branche ou le dépôt concerné et les règles d’approbation. Distinguez les changements soumis par une personne de confiance des contributions externes.
  • Contrôlez le routage. Vérifiez les étiquettes du Runner, les Runner groups et les dépôts qui peuvent les utiliser. Confirmez qu’un workflow non destiné à la publication ne peut pas être dirigé vers un hôte qui possède des identifiants de signature.
  • Réduisez les permissions. Examinez les droits du jeton, les secrets disponibles et les autorisations du compte macOS. Si une tâche n’a pas besoin d’écrire dans le dépôt ou d’accéder à une clé, retirez cet accès.
  • Définissez les résidus à traiter. Après une tâche réutilisant un hôte, contrôlez l’espace de travail, les fichiers temporaires, les processus encore actifs et les données de configuration susceptibles de contenir des informations. Le nettoyage est une mesure d’hygiène, pas un remplacement de l’isolation.
  • Choisissez une réponse aux erreurs. Si une tâche non fiable a été exécutée sur un hôte persistant, ne supposez pas que le nettoyage du répertoire suffit. Évaluez les accès possibles et, si l’intégrité de la machine est incertaine, réinitialisez ou remplacez l’environnement avant de lui confier des secrets.
  • Préservez les éléments de diagnostic. Le mode temporaire ne signifie pas que les journaux sont conservés automatiquement. La documentation GitHub recommande de transmettre les journaux des Runner éphémères vers un stockage externe avant la destruction de l’environnement. Consultez les indications de surveillance et dépannage des Runner et adaptez la conservation à vos besoins.
  • Validez le retrait. Après le remplacement ou la suppression d’un Runner, vérifiez aussi son enregistrement dans GitHub et les autorisations associées. La procédure officielle de suppression des Runner auto-hébergés distingue la désinscription de l’agent et les opérations réalisées sur la machine.

Que faut-il nettoyer après une tâche ? Au minimum, identifiez les fichiers de travail et temporaires, les processus qui peuvent survivre, les éléments du trousseau utilisés et les journaux pouvant contenir des données sensibles. La liste exacte dépend du projet et des actions exécutées. Notez ce qui est supprimé, ce qui est conservé pour diagnostiquer un échec et qui peut consulter ces traces. Les journaux expurgés, le résultat du travail et l’enregistrement du nettoyage apportent des preuves plus utiles qu’une affirmation générale selon laquelle « tout a été effacé ».

Pour un Runner éphémère, le principe est différent : l’agent est destiné à traiter une tâche puis à être retiré. La documentation GitHub précise que ce type de Runner n’accepte qu’une seule tâche, ce qui en fait une option adaptée à la réduction de la persistance ; elle recommande également d’externaliser les journaux afin qu’ils ne disparaissent pas avec la machine. Cela ne prouve pas que les secrets ont été correctement limités pendant la tâche, ni que l’infrastructure qui crée l’environnement est elle-même isolée. Vérifiez séparément les autorisations, le transfert des journaux et le retrait effectif.

06

Un Mac distant ne remplace pas l’isolation du Runner

Si votre organisation exécute seulement du code de dépôts privés maîtrisés et que les accès sont restreints, un Mac permanent dédié peut simplifier l’exploitation. En contrepartie, vous devez maintenir son état, surveiller les résidus et éviter de lui confier des tâches dont le niveau de confiance diffère. Si les workflows incluent des contributions externes ou des secrets de publication, une machine temporaire et isolée est plus cohérente avec ce risque, à condition que son cycle de vie et ses journaux soient réellement maîtrisés.

La location d’un Mac peut éviter l’achat d’une machine réservée à la compilation et vous donner accès à un environnement macOS distinct de votre poste de travail. Elle ne crée toutefois pas, à elle seule, un Runner éphémère, ne sépare pas les Pull Requests de la publication et ne protège pas une clé laissée accessible au compte d’exécution. Si vous envisagez cette voie, examinez les options de Mac distant proposées par VpsMesh et vérifiez comment elles s’accordent avec votre propre mode d’accès, votre configuration GitHub Actions et votre gestion des secrets. Vous pouvez aussi consulter les informations de location et les tarifs avant de décider si un hôte dédié répond à votre besoin ; pour du code externe ou des tâches privilégiées, concevez l’isolation séparément.