Pour des tâches fiables et stables, évaluez un Runner Mac permanent uniquement si les permissions et le nettoyage sont maîtrisés ; pour du code non fiable ou fortement privilégié, privilégiez l’évaluation d’un runner éphémère associé à la réinitialisation du Mac. Cette semaine, consignez pour chaque classe de tâches qui peut fournir des secrets, qui nettoie l’hôte et quelle preuve confirme que le prochain travail démarre dans un environnement propre.
Cette analyse s’adresse aux responsables IT qui exploitent des Mac pour GitHub Actions et doivent choisir entre réutilisation et remplacement du runner.
Elle concerne aussi les équipes plateforme chargées des limites de confiance, des identifiants de signature et des journaux d’exécution.
Les directions techniques y trouveront les responsabilités d’exploitation à clarifier avant de déployer l’un ou l’autre modèle.
Le risque dépend du code exécuté, pas du nom du runner
Un runner associé à une organisation, à un dépôt privé ou à un groupe autorisé n’est pas automatiquement sûr pour chaque workflow qui lui est envoyé. La question déterminante est de savoir quel code s’exécute, avec quelles permissions et quels accès à l’hôte. GitHub avertit que des workflows non fiables peuvent compromettre l’environnement d’un runner auto-hébergé ; la documentation sur l’utilisation sécurisée de GitHub Actions doit donc être rapprochée des déclencheurs et des autorisations effectivement configurés dans le dépôt.
Séparez au minimum ces classes de travail :
- Code interne approuvé : branches protégées, modifications examinées et workflow dont les actions et dépendances sont contrôlées. Il peut être candidat à un runner permanent, sous réserve de limiter les permissions et les ressources accessibles.
- Contributions externes : propositions de modification dont le code peut être hostile, même si le dépôt qui les reçoit appartient à l’organisation. Ne leur donnez pas accès à un Mac contenant les identifiants de publication ou des ressources internes.
- Publication et signature : tâches qui utilisent des certificats, profils, clés ou autorisations de déploiement. Elles exigent une frontière distincte et des conditions d’approbation adaptées ; elles ne doivent pas être considérées comme sûres simplement parce qu’elles s’exécutent dans le même dépôt que les compilations ordinaires.
Examinez les événements déclencheurs et les règles de permissions dans les fichiers de workflow. En particulier, une configuration utilisant pull_request_target demande une attention spécifique : GitHub décrit les risques liés à ce déclencheur dans sa documentation dédiée à pull_request_target. Le critère d’admission devrait être explicite : une tâche qui peut modifier son propre code d’exécution ou accéder à un secret sensible ne rejoint pas le même pool qu’une compilation interne de confiance sans analyse préalable.
Le cycle de vie : comparaison des deux modes
La différence essentielle ne se résume pas à « rapide contre lent ». Un runner permanent reste enregistré et peut reprendre des tâches ; un runner éphémère est destiné à ne traiter qu’une tâche avant de se désinscrire. GitHub documente le paramètre --ephemeral et le fonctionnement des runners ponctuels dans sa référence des runners auto-hébergés. Aucun de ces mécanismes ne garantit, à lui seul, que le système macOS sous-jacent est remis à zéro.
| Dimension de décision | Runner permanent | Runner éphémère |
|---|---|---|
| Enregistrement | Reste disponible pour des exécutions ultérieures, selon sa configuration. | Se désinscrit après avoir accepté une tâche, selon le mécanisme documenté par GitHub. |
| Espace de travail et caches | Peuvent être conservés ou réutilisés ; leur nettoyage doit être organisé et contrôlé. | Le cycle d’enregistrement est court, mais fichiers et caches peuvent survivre sur le Mac. |
| Outils et état macOS | Permet de maintenir un environnement préparé, au prix d’un risque de dérive et de résidus. | Permet de viser une reconstruction propre si l’hôte est réinitialisé ou recréé entre les tâches. |
| Exploitation | L’équipe doit suivre l’état du nœud, ses mises à jour, ses journaux et ses procédures de remise en service. | L’équipe doit automatiser la création et la suppression du runner, mais également prouver le nettoyage de l’hôte. |
| Usage à examiner | Travaux internes stables, accès limités et nettoyage vérifiable. | Code non fiable, tâches privilégiées ou exigences fortes de séparation, si la remise à zéro est réelle. |
Une configuration éphémère peut être préparée avec le paramètre prévu par l’application du runner, par exemple :
./config.sh --url "$REPOSITORY_URL" --token "$RUNNER_TOKEN" --ephemeral
Les variables sont des valeurs à injecter au déploiement, pas des secrets à inscrire dans le dépôt. Ce paramètre demande un cycle de vie éphémère pour l’enregistrement du runner ; il ne commande pas nécessairement l’effacement complet du disque, la suppression des identités du Keychain ou la réinstallation de macOS.
Pour les environnements qui utilisent un runner JIT, vérifiez aussi la méthode de création, l’affectation et la suppression prévues par votre intégration. La configuration JIT et la fin d’une tâche ne sont pas des preuves de destruction physique ou logique de l’environnement. La documentation GitHub sur le retrait des runners distingue l’enregistrement du runner de la gestion de la machine : l’équipe reste responsable de ce qui demeure sur l’hôte.
L’isolation réelle après chaque tâche
L’isolation Mac CI doit être évaluée à partir de l’état résiduel, et non du seul statut affiché dans l’interface. Après un travail, vérifiez si l’environnement suivant peut retrouver le répertoire de travail, les caches de dépendances, les fichiers temporaires, les artefacts téléchargés ou les états de simulateur. Une tâche peut également modifier la configuration de l’utilisateur ou installer un outil persistant.
Établissez un protocole de validation avant d’autoriser un runner à passer d’une tâche à une autre :
- Exécutez une tâche témoin qui crée un fichier repérable dans le répertoire de travail et dans un emplacement temporaire.
- Lancez ensuite une tâche distincte et contrôlez si ces fichiers sont encore accessibles ; ne déduisez pas le nettoyage de la seule désinscription du runner.
- Vérifiez les répertoires de caches et les installations d’outils que vos workflows utilisent réellement, au lieu de supposer que tous les chemins sont remis à zéro par défaut.
- Examinez le Keychain, les profils de provisionnement et les identités de signature après la tâche, en tenant compte du compte macOS qui a exécuté le runner.
- Documentez le résultat attendu, le responsable de la remise en état et le traitement d’échec si la réinitialisation ne peut pas être confirmée.
Un runner qui n’apparaît plus comme disponible n’est pas nécessairement un Mac propre. Si la preuve de réinitialisation manque, ne réaffectez pas cet hôte à une tâche d’un niveau de confiance supérieur.
Pour les tâches où le risque justifie une séparation stricte, la reconstruction de l’environnement à partir d’une base maîtrisée est plus probante qu’un simple nettoyage ciblé, à condition que la procédure elle-même soit testée. Si l’organisation ne peut pas démontrer ce qui est supprimé, elle ne peut pas présenter la désinscription comme une isolation achevée.
Secrets, jetons et accès au réseau
Le risque ne se limite pas aux certificats iOS. Un workflow peut recevoir un jeton avec des permissions, des Secrets de dépôt ou d’environnement, des identifiants de service, ou un accès réseau vers des ressources internes. La documentation des permissions de GITHUB_TOKEN décrit la gestion des autorisations du jeton ; appliquez le principe du moindre privilège aux permissions réellement nécessaires plutôt que de laisser une configuration large servir à tous les workflows.
Inventoriez les éléments qu’une tâche peut lire ou modifier : Secrets injectés, profils de signature, clés présentes dans le Keychain, fichiers de configuration, caches d’authentification et services accessibles depuis le réseau. La documentation sur les Secrets GitHub Actions explique leur mise à disposition dans les workflows, mais ne remplace pas l’examen de ce qui a été copié ou utilisé sur le Mac pendant l’exécution.
Pour les opérations de publication, utilisez les environnements et leurs protections lorsque cela correspond à votre modèle d’autorisation. GitHub documente les règles de protection des environnements et des déploiements. Une approbation peut contrôler le moment où un travail démarre ou reçoit certains secrets ; elle ne transforme pas le système hôte en machine isolée. De même, les groupes de runners servent à organiser l’accès et le routage, mais ne constituent pas une frontière de sécurité entre les tâches déjà exécutées sur le même Mac.
Le choix des permissions doit donc tenir compte de la destination suivante du nœud. Si une tâche externe peut atteindre le réseau interne, lire une identité de signature ou modifier un outil partagé, un nettoyage partiel peut ne pas suffire. Distinguez les pools par niveau de confiance, réduisez leurs accès réseau et réservez les identifiants de signature à un chemin de publication contrôlé. Les règles qui protègent un dépôt n’effacent pas les effets d’un workflow qui a déjà eu accès à son hôte.
Outils, caches et cohérence des constructions
Un runner permanent simplifie le maintien d’une chaîne Xcode connue et peut conserver des dépendances utiles aux workflows. En contrepartie, l’état observé aujourd’hui n’est pas nécessairement celui du prochain cycle : une tâche peut mettre à jour un outil, modifier une préférence ou laisser un cache incohérent. La stabilité apparente ne remplace donc pas un inventaire et une procédure de retour à une base vérifiée.
Un runner éphémère peut faciliter la répétition d’une configuration maîtrisée si le Mac est reconstruit ou réinitialisé à partir d’une base contrôlée. Il demande toutefois de traiter explicitement l’installation de Xcode, des dépendances, des certificats et des outils propres à l’équipe. Sans mesure dans votre environnement, ne présumez ni d’un gain de temps ni d’une pénalité de construction : le résultat dépend des logiciels, des caches autorisés et de la méthode de préparation.
| Point de contrôle | Question à vérifier | Preuve exploitable |
|---|---|---|
| Xcode et outils | La version attendue et les composants requis sont-ils présents avant la tâche ? | Inventaire de l’environnement et contrôle exécuté par le workflow. |
| Dépendances | Les versions sont-elles verrouillées et les caches isolés selon la confiance ? | Fichiers de verrouillage, configuration du cache et test de réutilisation. |
| Workspace | Le travail précédent laisse-t-il des fichiers ou modifications pertinents ? | Résultat d’un test de résidu et journal de nettoyage. |
| Simulateurs | Les appareils et états utilisés par la tâche sont-ils réinitialisés ou reconstruits ? | Vérification réalisée après exécution sur le Mac concerné. |
| Signature | Les certificats et profils sont-ils accessibles seulement au workflow autorisé ? | Permissions, contrôle du Keychain et preuve de retrait ou de rotation. |
Ce contrôle est particulièrement utile lorsqu’un même Mac sert à des projets iOS, macOS, audio ou vidéo : les outils, fichiers de projet et licences peuvent différer, et une configuration partagée ne doit pas être prise pour une base commune fiable. Consignez les écarts observés avant de décider si la réutilisation des caches est acceptable.
Pour examiner les modalités de mise à disposition d’un Mac distant avant de définir votre architecture, consultez la présentation des solutions Mac de NodeMini et vérifiez séparément les conditions d’accès, de nettoyage et de responsabilité qui s’appliquent à votre cas.
Journaux, diagnostic et responsabilité opérationnelle
Un runner éphémère peut disparaître rapidement de l’infrastructure, mais une enquête ne doit pas disparaître avec lui. GitHub fournit des informations de surveillance et de dépannage des runners, notamment des journaux utiles au diagnostic ; consultez sa documentation de surveillance et de dépannage pour macOS. Déterminez quels journaux sont conservés par la plateforme et lesquels doivent être transférés vers un stockage contrôlé avant de supprimer l’environnement.
Reliez chaque exécution à des preuves distinctes : identité et version du runner, identifiant de tâche, workflow déclenché, permissions accordées, événements de nettoyage et résultat de la remise en état. La preuve que le runner a été retiré n’atteste pas le nettoyage du système ; la preuve qu’un nettoyage a été lancé n’atteste pas qu’il a réussi. Si la machine est supprimée avant l’export des journaux locaux, définissez une collecte externe préalable et testez qu’elle permet encore d’examiner une tâche en échec.
Les rôles doivent être nommés avant le déploiement : qui maintient la base macOS et Xcode, qui renouvelle les identifiants de signature, qui examine l’échec d’un nettoyage, qui décide de l’isolement du nœud et qui autorise sa remise en service. Sans responsable clairement désigné, l’automatisation peut signaler une tâche terminée sans apporter de réponse vérifiable sur l’état du Mac.
Matrice de décision et vérification de déploiement
Appliquez la décision à la classe de travail et à son environnement, pas à l’organisation entière. Un même parc peut combiner des runners permanents pour des constructions internes récurrentes et des runners éphémères pour des contributions ou opérations plus sensibles, si les chemins d’exécution et les ressources accessibles sont effectivement séparés.
| Conditions constatées | Option à évaluer | Condition préalable |
|---|---|---|
| Code interne stable, permissions réduites, outils maîtrisés | Runner permanent | Nettoyage contrôlé, revue périodique de l’état et responsable de remise en service. |
| Code externe ou tâche à privilèges élevés | Runner éphémère | Destruction, réinitialisation ou reconstruction automatique de l’environnement après la tâche. |
| Secrets de signature nécessaires à une publication | Runner réservé à la publication, avec cycle adapté au risque | Accès limité, Keychain contrôlé, permissions minimales et journaux conservés hors de l’hôte. |
| Nettoyage impossible à démontrer | Ne pas réutiliser le Mac pour un niveau de confiance supérieur | Suspendre la réaffectation jusqu’à ce qu’une remise en état vérifiable soit disponible. |
Pour déployer sans confondre les étapes, procédez ainsi :
- Classez chaque workflow selon l’origine du code, les permissions et les secrets qu’il peut recevoir.
- Associez chaque classe à un groupe et à un hôte dont les accès réseau et les ressources sont documentés.
- Testez le cycle éphémère ou permanent avec un fichier témoin, des caches et les éléments pertinents du Keychain.
- Automatisez la collecte des journaux et des résultats de nettoyage avant de supprimer ou reconstruire l’environnement.
- Simulez un échec de remise en état, puis vérifiez que le Mac est mis à l’écart plutôt que réaffecté silencieusement.
- Autorisez la production seulement après revue conjointe des permissions, des résultats de nettoyage et de la capacité de diagnostic.
La règle de décision reste conditionnelle : si le travail est fiable et stable, que les droits sont étroits et que la remise en état du Mac est contrôlable, le mode permanent peut être évalué. Si le code est non fiable ou fortement privilégié, évaluez d’abord le mode éphémère avec destruction ou reconstruction automatisée. Si la propreté du système ne peut pas être prouvée, l’étiquette « éphémère » ne suffit pas.
Questions fréquentes
Quelle différence entre un runner Mac éphémère et permanent ?
Le mode éphémère concerne le cycle d’enregistrement du runner : après une tâche, il se désinscrit au lieu de rester disponible pour les suivantes. Le mode permanent permet une réutilisation, mais celle-ci peut conserver des fichiers, des caches ou des réglages. Il faut distinguer le runner enregistré, la fin du travail et l’état de macOS ; ces événements ne garantissent pas tous la même chose.
Le Mac doit-il être nettoyé après une tâche éphémère ?
Oui, si une autre tâche, surtout d’un niveau de confiance différent, doit utiliser ce Mac. La désinscription n’établit pas que les fichiers de travail, les caches, le Keychain et les états de simulateur ont été supprimés. Vérifiez une procédure de nettoyage, de réinitialisation ou de reconstruction, ainsi que son résultat. En l’absence de preuve, maintenez le nœud hors service pour les tâches sensibles.
Comment réduire le risque lié aux identifiants sur un Mac CI partagé ?
Limitez les permissions de GITHUB_TOKEN et la portée des Secrets, séparez les workflows externes des tâches de publication et contrôlez les identités de signature dans le Keychain. Ajoutez une vérification des accès réseau et du contenu résiduel après chaque tâche. Les groupes de runners et les approbations peuvent organiser l’accès, mais ne remplacent pas l’isolation ou la remise à zéro du Mac.
Quels travaux iOS justifient un runner éphémère ?
Évaluez ce modèle pour le code externe, les tâches à privilèges élevés et les opérations qui manipulent des identifiants sensibles, à condition que l’hôte soit lui aussi nettoyé ou reconstruit. Des compilations internes répétitives peuvent convenir à un runner permanent lorsque les permissions sont limitées, que l’environnement est surveillé et que les résidus sont contrôlés. Mesurez les contraintes de votre chaîne avant de trancher.
Pour des équipes qui maintiennent elles-mêmes leurs Mac, la solution actuelle implique généralement du matériel à acheter et renouveler, des mises à jour à coordonner et une responsabilité directe sur le nettoyage comme sur les journaux ; elle peut néanmoins rester préférable lorsqu’un accès physique, un contrôle local particulier ou une charge durable l’exige. Une location de Mac n’est pas, à elle seule, une garantie d’isolation : avant d’évaluer les Mac disponibles auprès de NodeMini, vérifiez les modalités réelles de livraison, d’accès, de remise à zéro et de conservation des preuves. Tant que ces responsabilités ne sont pas documentées pour le besoin concerné, gardez votre architecture actuelle sous contrôle plutôt que de traiter le changement d’hébergement comme une mesure de sécurité.