GitLab Runner macOS : la connexion automatique est-elle sûre ? Liste de contrôle 2026

La connexion automatique peut résoudre un problème de session au démarrage ; elle ne prouve ni que le service GitLab Runner fonctionne, ni qu’un travail de construction aboutit, ni que l’hôte est suffisamment isolé. Pour prendre une décision exploitable, gardez ces états séparés dans les journaux et dans le procès-verbal de validation.

La documentation GitLab indique que le Runner macOS fonctionne comme un agent de lancement associé à un utilisateur et décrit la connexion automatique comme un moyen de maintenir le Runner disponible après un redémarrage. Cela correspond à une dépendance de fonctionnement à la session, pas à une garantie générale de reprise de tous les composants. Consultez les instructions GitLab pour installer le Runner sous macOS et relevez la méthode effectivement utilisée sur le nœud.

La connexion automatique est-elle nécessaire sur macOS ?

Elle peut être utilisée pour restaurer la session utilisateur dont dépend le Runner dans cette configuration. Elle n’est pas une exigence de sécurité universelle, et son activation n’est pas une preuve qu’un Runner donné sera opérationnel après chaque redémarrage. Il faut déterminer si le nœud repose bien sur un LaunchAgent, quel compte le charge et à quel moment il est censé démarrer.

Sur le Mac concerné, consignez les éléments suivants avant toute modification :

• [ ] Le Runner est associé au compte utilisateur prévu, et non à un compte personnel dont le départ ou la désactivation interromprait le service.
• [ ] La configuration vérifiée correspond à un LaunchAgent et non à une supposition fondée sur le seul nom du processus.
• [ ] Le démarrage attendu, la fermeture de session et la fermeture du processus sont distingués dans la procédure d’exploitation.
• [ ] La personne chargée d’intervenir est identifiée si le compte ne peut pas ouvrir de session automatiquement.
• [ ] L’équipe sait quelle preuve elle attend à chaque état : session ouverte, Runner enregistré et actif, puis tâche représentative terminée.

La configuration ne doit donc pas être acceptée sur la base d’un indicateur « en ligne » uniquement. Une session ouverte ne démontre pas que le service a chargé la bonne configuration ; un Runner actif ne démontre pas qu’il possède les dépendances ou les autorisations nécessaires à un véritable build.

Le compte employé par GitLab Runner définit une grande partie de la portée concrète d’une tâche. Avant de décider si la connexion automatique est acceptable, établissez ce que ce compte peut lire, modifier, lancer et contacter. Cette cartographie doit décrire l’environnement réellement observé, pas seulement les droits prévus dans une demande de changement.

Droits, fichiers et réseau

Examinez les répertoires de travail, les espaces temporaires, les fichiers de configuration, les journaux, les outils de développement et les secrets auxquels le compte peut accéder. Vérifiez également les accès réseau disponibles depuis le Mac : dépôt de code, services internes, destinations de publication et éventuels systèmes de déploiement. Un travail peut hériter de ces accès par l’identité d’exécution, même si le script de CI ne les mentionne pas explicitement.

• [ ] Le compte du Runner est identifié dans la configuration et confirmé pendant une tâche réelle.
• [ ] Les droits d’administration sont justifiés par une tâche documentée ; sinon, leur retrait est évalué avant la mise en production.
• [ ] Les répertoires partagés avec d’autres utilisateurs ou tâches sont répertoriés et leurs permissions contrôlées.
• [ ] Les accès réseau sont comparés aux destinations dont les tâches ont effectivement besoin.
• [ ] Les outils installés et leurs fichiers de configuration ne permettent pas d’obtenir des secrets sans rapport avec la tâche.
• [ ] Les preuves conservées comprennent la configuration pertinente, l’identité constatée pendant l’exécution et le résultat de l’examen des accès.

Il ne suffit pas de constater que l’utilisateur n’est pas administrateur. Des fichiers de signature lisibles, des jetons conservés dans l’environnement ou un accès trop large au réseau peuvent donner à un compte non administrateur une portée importante. À l’inverse, la présence d’un outil de développement ne signifie pas, à elle seule, que le compte peut accéder à toutes les données du Mac : l’accès doit être vérifié par chemin, permission et identité.

La documentation GitLab sur la configuration d’un environnement macOS aide à situer le fonctionnement du Runner. Elle ne remplace pas l’inventaire local des permissions et des dépendances, qui varie selon les comptes, les réglages de sécurité et les scripts utilisés par l’entreprise.

Le risque du Shell executor tient notamment au fait que les scripts de travail s’exécutent sur l’hôte avec l’identité et les capacités disponibles pour le Runner. GitLab souligne que cet exécuteur offre une isolation limitée. Cette réserve concerne le mode d’exécution Shell ; elle ne doit pas être étendue sans examen à tous les exécuteurs ni interprétée comme une preuve que chaque tâche compromet l’hôte.

La documentation de sécurité de l’exécuteur Shell de GitLab doit être lue avec la politique d’affectation des tâches de l’organisation. Une même machine ne présente pas le même risque selon que ses travaux proviennent exclusivement de branches protégées, de projets contrôlés ou de contributions externes capables de modifier les scripts exécutés.

Le Shell executor isole-t-il les projets ?

Ne le traitez pas comme une frontière d’isolation suffisante entre des projets dont les contributeurs ou les niveaux de confiance diffèrent. Les scripts s’exécutent sur la machine, et les tâches peuvent potentiellement exploiter les accès accordés au compte du Runner. La séparation doit donc reposer sur une politique explicite d’affectation et, lorsque le niveau de confiance l’exige, sur des hôtes ou des files de travail distincts.

Pour chaque groupe de tâches, documentez :

• [ ] L’origine du code autorisé : dépôt interne contrôlé, branche protégée ou contribution provenant d’une source moins fiable.
• [ ] Les règles qui déterminent le Runner auquel une tâche peut être confiée, ainsi que les personnes habilitées à modifier ces règles.
• [ ] Les projets qui partagent le même compte et la même machine, avec la raison de ce partage.
• [ ] Les secrets accessibles à une tâche de test ordinaire, puis ceux réservés aux tâches de publication et de signature.
• [ ] La procédure d’arrêt ou de mise en quarantaine si une tâche suspecte a accédé à l’hôte.

Recommandez une séparation des nœuds ou des comptes lorsque des tâches de confiance différente partagent des secrets, des répertoires ou des accès réseau qui ne peuvent pas être limités proprement. Cette mesure constitue une recommandation d’architecture, à adapter à la politique interne et au modèle de menace ; ce n’est pas une affirmation selon laquelle tous les projets doivent nécessairement disposer d’un Mac séparé.

Apple indique que le réglage de connexion automatique peut être indisponible lorsque FileVault est activé. Vérifiez cette contrainte dans les instructions Apple sur la connexion automatique et dans la documentation Apple sur la gestion de FileVault. La conséquence dépend de la configuration effective du Mac ; elle ne permet pas de conclure que tout nœud macOS protégé par FileVault est incapable de reprendre son activité.

Dans l’analyse d’architecture, ne confondez pas le déverrouillage du disque, l’ouverture de la session utilisateur et la disponibilité du Runner. Un disque protégé peut requérir une étape de déverrouillage ; une session peut ensuite être ouverte sans que la configuration du Runner soit correcte ; enfin, un Runner actif peut échouer à exécuter un build faute de dépendances ou d’accès adaptés. Il s’agit d’états distincts à tester séparément.

• [ ] La règle de chiffrement de l’entreprise est confirmée pour le nœud et le compte utilisés.
• [ ] Aucun réglage automatique n’a été obtenu en désactivant une protection exigée par la politique interne.
• [ ] La procédure décrit comment le disque est déverrouillé après redémarrage lorsque cette étape est requise.
• [ ] Le comportement réel de la session et du Runner est testé avec la politique FileVault appliquée.
• [ ] Une procédure manuelle de reprise est prévue si la connexion automatique n’est pas disponible ou autorisée.

Si la règle de sécurité exige FileVault et que le scénario de connexion automatique ne peut pas respecter cette règle, la décision n’est pas de supprimer le chiffrement pour garder le Runner en ligne. Il faut revoir le mécanisme de reprise, l’intervention humaine attendue ou l’organisation des tâches. La responsabilité de l’intervention doit être assignée à une équipe ou à un rôle opérationnel, sans supposer qu’un nœud distant sera toujours accessible au moment nécessaire.

Un Runner qui exécute des tâches de publication peut détenir ou pouvoir lire des certificats, des profils et des éléments du trousseau. Cette capacité fait de la portée du compte d’exécution un critère de mise en production à part entière. La connexion automatique ne crée pas à elle seule un accès au trousseau, mais elle peut rétablir une session dans laquelle des outils et des secrets sont accessibles selon les permissions configurées.

Établissez l’inventaire des éléments de signature utilisables depuis le compte concerné : trousseau accessible, certificats, profils de provisionnement, identifiants de publication et emplacement des secrets auxiliaires. Vérifiez ensuite quels types de tâches peuvent les lire ou les employer. Une tâche de test sans besoin de signature ne devrait pas recevoir les mêmes capacités qu’une tâche de publication simplement parce qu’elles partagent un Runner.

• [ ] Les tâches de test et les tâches de signature sont séparées dans les règles d’affectation et les autorisations effectives.
• [ ] Les secrets ne sont pas exposés dans les journaux de travail ni copiés dans des répertoires accessibles à des tâches non concernées.
• [ ] L’accès au trousseau est testé sous l’identité réelle du Runner, et non sous un compte administrateur de maintenance.
• [ ] Les événements d’usage des identifiants sont conservés selon la politique de journalisation de l’organisation.
• [ ] Le renouvellement ou la révocation des secrets fait partie de la réponse prévue en cas de tâche non fiable.

Pour choisir un environnement adapté aux tâches de signature, raisonnez à partir de la frontière de confiance et de l’identité qui consomme les secrets. Un nœud dédié aux publications peut convenir si ses tâches sont contrôlées, que son accès aux clés est restreint et que ses opérations sont traçables. Si des contributions externes peuvent atteindre la même machine ou la même session, cette organisation doit être révisée avant d’y déposer des clés utilisables.

La mise en service doit s’appuyer sur un essai en environnement isolé, avec la politique de sécurité réellement prévue. Un test limité à la disponibilité du processus ne suffit pas : le dossier doit démontrer que la session, le Runner et une tâche représentative se rétablissent de la manière attendue, et indiquer les actions manuelles requises lorsque ce n’est pas le cas.

• [ ] Relever l’état initial : compte de service, type de lancement, politique FileVault, accès réseau et secrets présents.
• [ ] Redémarrer le nœud selon une procédure approuvée, sans neutraliser une protection imposée.
• [ ] Vérifier séparément l’état du disque et de la session utilisateur, puis relever si le LaunchAgent est chargé.
• [ ] Confirmer l’enregistrement et la disponibilité du Runner dans l’environnement CI.
• [ ] Exécuter un build représentatif sans secret, puis un test de signature contrôlé si ce scénario fait partie du périmètre.
• [ ] Consigner les journaux utiles, les éventuelles étapes manuelles, le responsable de reprise et la décision de mise en production.

Une tâche représentative doit exercer les dépendances réellement utilisées : outils de développement, accès aux fichiers requis, téléchargement éventuel des composants nécessaires et sortie de build vérifiable. Pour un scénario de signature, utilisez une tâche autorisée dans un environnement maîtrisé ; l’objectif est de vérifier les droits et les traces, pas de déposer des identifiants de publication dans un test accessible à des contributions non fiables.

Le dossier d’acceptation doit permettre à un autre membre de l’équipe de comprendre ce qui a été testé et ce qui ne l’a pas été. Conservez la configuration pertinente, les journaux expurgés de toute valeur secrète, l’identité d’exécution observée, les résultats des tâches et la décision de sécurité. Indiquez également les limites connues : intervention humaine au redémarrage, tâches interdites sur le nœud, dépendance à une session précise ou procédure de retrait du Runner.

À partir de ces preuves, la décision peut être formulée sans ambiguïté :

• Autoriser si la politique FileVault est respectée, le compte est limité, les tâches admises sont de confiance et l’essai de reprise couvre un build représentatif.
• Limiter si le nœud convient uniquement à des tâches internes contrôlées ou si les travaux de signature doivent être réservés à une file distincte.
• Reporter si l’origine des tâches, les accès au trousseau, le fonctionnement après redémarrage ou la responsabilité d’intervention restent indéterminés.

Un Mac acheté et géré en interne peut convenir lorsque l’usage est durable, que l’équipe doit maîtriser le matériel et qu’elle peut assurer les interventions physiques, les mises à jour, la gestion des comptes et la reprise. En contrepartie, le coût total comprend davantage que l’achat : préparation, maintenance, surveillance, remplacement en cas de panne et temps consacré à l’exploitation. Ces postes doivent être estimés à partir des coûts internes, sans extrapoler un tarif générique.

Un Mac distant loué peut mieux répondre à un besoin temporaire, à un pilote ou à une capacité de CI que l’équipe ne souhaite pas exploiter physiquement. Il ne supprime pas les vérifications de sécurité : avant tout engagement, il faut confirmer les modes d’accès, le contrôle des comptes, les conditions de reprise après redémarrage et la manière dont les tâches de signature sont prises en charge. Pour cadrer ces questions, les pages d’aide sur l’utilisation du service et de présentation de NUKCLOUD peuvent servir de points de départ, sans remplacer une validation écrite des conditions adaptées au besoin.

Le choix dépend donc de la responsabilité que l’équipe souhaite conserver. Un nœud interne offre un contrôle matériel direct, mais reporte sur l’organisation l’astreinte et la maintenance. Une capacité distante peut éviter l’achat et la gestion physique immédiats, mais impose de vérifier le modèle d’accès et les conditions de reprise avant d’y placer du code ou des secrets. Si des tâches stables et fortement chargées exigent un accès physique ou des interfaces locales, l’achat d’un Mac peut rester plus approprié.

Pour un pilote ou un besoin ponctuel, la location d’un Mac distant chez NUKCLOUD peut offrir une expérience opérationnelle mieux adaptée qu’un poste acheté puis préparé à la hâte, à condition que les preuves de livraison, d’accès et de reprise répondent aux contrôles définis dans ce guide. La décision doit rester suspendue si l’environnement ne permet pas de respecter FileVault, de limiter les tâches non fiables ou de maîtriser les clés de signature ; le maintien du Runner en ligne ne justifie pas d’abaisser ces protections.