Оставляйте постоянный Mac только для заданий из доверенного частного репозитория, если вы ограничили доступ к Runner и проверяете остаточные данные после сборки. Для внешнего кода и задач с высокими привилегиями выбирайте изолированную одноразовую среду либо не запускайте их на этой машине. Удаление рабочей папки не создаёт полноценную изоляцию, а аренда удалённого Mac сама по себе не меняет модель безопасности Runner.

План: на этой неделе проследите путь кода от события GitHub Actions до Runner и отдельно отметьте, какие задания получают токены, сертификаты и доступ к Keychain.

Кому пригодится: независимым разработчикам, которые собирают iOS-приложения и выбирают между повторным использованием Mac и отдельной средой.
Небольшим командам, которым нужно отделить обычные сборки от подписи и публикации.
Тем, кто поддерживает автоматический выпуск и хочет понять, какие данные остаются на постоянно работающем узле.

01

Выбор GitHub Actions macOS Runner начинается с источника кода

Название Runner не определяет, безопасно ли запускать на нём задачу. Начните с происхождения кода: доверенная ветка вашего репозитория, Pull Request от участника с правом записи или изменение от внешнего автора. Затем оцените, какие секреты и системные ресурсы доступны задаче.

У постоянного Runner есть две отдельные характеристики:

  • Процесс Runner остаётся онлайн. Он может получать новые задания, пока зарегистрирован и доступен.
  • Состояние машины может сохраняться. После завершения задания могут остаться файлы, кэш, настройки инструментов или данные, которые создала сама задача.

Поэтому доступность процесса не означает чистое окружение, а очистка workspace не доказывает, что вся машина возвращена в исходное состояние. В документации GitHub отдельно рассматриваются повторное использование self-hosted Runner и его рабочая среда. Применяйте эти рекомендации к конкретной конфигурации: поведение зависит от того, как настроены Runner, задания и последующая обработка.

Практический пример: ваша основная ветка запускает сборку приложения, а workflow для Pull Request собирает код внешнего автора. Если оба задания используют одну постоянную машину, границу нельзя определять только по разным именам workflow. Нужно выяснить, кто может направить задачу на Runner, какие данные ей доступны и что произойдёт с остаточным состоянием после выполнения.

02

Сопоставьте сценарии, а не только способы размещения

Таблица поможет выбрать жизненный цикл среды. «Временная» здесь означает среду, которую вы действительно уничтожаете или возвращаете в исходное состояние после задания; одна лишь очистка каталога не делает постоянную машину одноразовой.

Сценарий Постоянный Mac Изолированная одноразовая среда Ключевое решение
Сборка из доверенной ветки частного репозитория без секретов публикации Может подойти, если доступ к Runner и состояние workspace контролируются Подходит, но добавляет управление жизненным циклом среды Ограничьте репозитории и проверяйте остаточные файлы
Pull Request от участника с правом записи Возможен при проверенных правах, событиях и разрешениях задания Предпочтительнее, если изменения не должны делить состояние с другими задачами Не полагайтесь только на внутренний статус ветки
Изменение от внешнего автора Не направляйте на машину с секретами или доверенными данными Выбирайте отделённую среду без чувствительных секретов либо откажитесь от такого запуска Проверяйте событие, токены и доступ к Runner
Подпись и отправка сборки Допустимо лишь при жёстко ограниченном доступе к ключам и запуску Удобнее разделить выпуск и обычную сборку, если жизненный цикл среды это позволяет Не предоставляйте секреты обычному Job
Задача, которой нужен сохранённый кэш или подготовленная среда Повторное использование может упростить обслуживание, но требует контроля содержимого Потребуется отдельно продумать перенос кэша и диагностики Не смешивайте кэш с секретами и пользовательскими данными

У постоянного хоста есть очевидные плюсы: его можно оставить доступным для доверенных сборок, а подготовленную среду — обслуживать как отдельный узел. Обратная сторона — вам нужно контролировать регистрацию Runner, доступ к нему, состояние файловой системы и восстановление после подозрительного задания.

Временная среда уменьшает период, в течение которого на одном и том же экземпляре накапливается состояние, только если её действительно изолируют и уничтожают или надёжно сбрасывают. Она не гарантирует автоматического сохранения журналов и не становится безопасной от одного слова «одноразовая». GitHub рекомендует рассматривать временные Runner как способ снизить риск для задач с недоверенным кодом; детали реализации и необходимые меры зависят от вашей инфраструктуры.

Если вы сравниваете аренду среды с собственной машиной, оценивайте не только сам хост, но и то, кто отвечает за регистрацию Runner, его обновление, восстановление и доступ к ключам. Текущие варианты аренды Mac можно сопоставить с вашими требованиями к доступу и рабочему процессу, но цена или удалённый доступ не являются доказательством изоляции.

03

Pull Request требует проверки события и полномочий

Не определяйте доверие по тому, что задача запускается «в том же репозитории». Проверьте, какое событие активирует workflow и кто может изменить сам workflow. Справочник GitHub по событиям запуска описывает различия между событиями; сверяйте их с настройками конкретного репозитория.

Для внешнего Pull Request особенно важно не направить непроверенный код на постоянный Mac. Даже если секреты обычно недоступны этому типу запуска, процесс сборки может взаимодействовать с файловой системой, инструментами и состоянием хоста. Сверьте фактические разрешения, а не только ожидаемое поведение: проверьте доступность группы Runner и конфигурацию workflow.

Отдельно проверьте pull_request_target. Это событие работает в контексте базового репозитория и может получить доступ к привилегированному контексту. Если затем workflow получает и исполняет код изменения, возникает опасное сочетание. Следуйте официальным рекомендациям по безопасному использованию pull_request_target: не запускайте непроверенный код с привилегиями базового репозитория.

Проверьте также, кто вообще может отправить Job на конкретный Runner. Группы Runner позволяют ограничивать доступ репозиториям и рабочим процессам, а настройки доступа помогают проверить, какие репозитории используют группу. Если такой контроль не настроен, считать постоянный Mac узлом только одного доверенного проекта нельзя.

04

Подпись и публикация должны иметь отдельные полномочия

Сборка приложения и его выпуск — не одно и то же действие. Обычному Job обычно не требуется доступ к приватному ключу подписи, паролю Keychain или учётным данным для публикации. Если один Runner используется для обеих задач, разделяйте доступ на уровне событий, окружений и разрешений, а не только названиями заданий.

Для каждого workflow ответьте на вопросы:

  • Может ли он получить сертификат или ключ из хранилища секретов?
  • Кто вправе запустить его вручную и изменить его конфигурацию?
  • Доступен ли ему Keychain с материалами подписи?
  • Может ли код Pull Request влиять на процесс, который читает секреты?
  • Сохраняются ли секреты или временные файлы после завершения?

Ограничивайте разрешения токена минимально необходимыми. В синтаксисе workflow GitHub позволяет задавать permissions; проверьте документацию по разрешениям GITHUB_TOKEN и конфигурацию каждого Job. Не предполагайте, что настройки одного workflow автоматически ограничивают все остальные.

Для постоянного Mac задайте узкий список репозиториев и доверенных сценариев, которым разрешено использовать Runner. Задание подписи запускайте только из контролируемого процесса выпуска. Храните журнал разрешений и подтверждение того, какие роли и workflow могут получить доступ к секретам. В диагностических данных скрывайте значения токенов, паролей и приватных ключей.

05

Порядок проверки перед выбором постоянного Mac

Используйте эту последовательность до того, как направить на хост сборки, подпись или код Pull Request.

  1. Инвентаризируйте источники кода. Выпишите события, запускающие workflow: изменения доверенных веток, внутренние и внешние Pull Request, ручной выпуск. Отметьте, кто может инициировать каждое событие и редактировать соответствующие файлы workflow. Если вы не можете надёжно отделить недоверенный код, не допускайте его на постоянный Runner.

  2. Проверьте назначение Runner. Сопоставьте Runner и его группу с репозиториями и workflow, которые могут отправлять задания. Не считайте, что тег сам по себе ограничивает доступ. Используйте настройки доступа и групп, а результат зафиксируйте отдельно от конфигурации самих workflow.

  3. Сравните разрешения Job с его задачей. Для обычной сборки проверьте GITHUB_TOKEN, секреты и доступ к артефактам. Для выпуска отдельно проверьте полномочия загрузки и подписи. Если Job не нужен токен или секрет, уберите его доступ. Сверяйте фактические настройки с синтаксисом permissions в workflow.

  4. Определите, что остаётся после выполнения. Проверьте каталог рабочего пространства, временные файлы, кэш, логи, артефакты и состояние Keychain. Найдите не только заранее известные файлы, но и места, куда инструменты сборки записывают данные. Составьте процедуру очистки и отдельно отметьте, что она не очищает и почему.

  5. Проведите проверочный запуск без секретов публикации. Возьмите представительную сборку и проверьте, что ожидаемый workflow попал на нужный Runner. После завершения осмотрите рабочую область и доступные журналы. Успешный тест сборки подтверждает работоспособность конкретного сценария, но не доказывает изоляцию от другого кода.

  6. Проверьте диагностику и восстановление. Решите, какие журналы нужно сохранить вне хоста и как удалить или повторно зарегистрировать Runner при инциденте. GitHub отдельно описывает наблюдение и устранение неполадок Runner и удаление Runner. Сохраняйте обезличенные логи, результат задания и запись об очистке; не оставляйте секреты в отчёте.

06

Очистка полезна, но не заменяет изоляцию

После Job проверяйте рабочие каталоги и временные файлы, созданные сборкой, а также артефакты и кэш, если они содержат данные проекта или могут повлиять на следующие задания. Проверьте доступ к Keychain и временные учётные данные. Удаляйте то, что задача могла оставить, и подтверждайте результат осмотром состояния, а не только успешным завершением команды очистки.

Однако каталог workspace — лишь часть машины. Задание, исполняющее недоверенный код, может взаимодействовать и с другими доступными ресурсами. Поэтому доказательство «папка удалена» не отвечает на вопросы о том, что происходило во время выполнения и какие полномочия имела задача. Рекомендации GitHub по безопасности self-hosted Runner важны именно для оценки всего окружения, а не только оставшихся файлов.

Временная среда тоже требует процедуры завершения. Если экземпляр уничтожается после задания, заранее организуйте передачу диагностических данных: временный Runner не сохраняет их автоматически. Если используется перерегистрируемый Runner, фиксируйте, какой экземпляр был снят, какие данные сохранены и что будет создано заново. Не называйте такую схему безопасной без проверки её фактического жизненного цикла.

Для инцидента подготовьте понятный порядок: остановить выдачу новых задач на подозрительный Runner, сохранить нужные обезличенные журналы, отозвать или заменить затронутые учётные данные и восстановить узел из известного состояния. Заранее определите ответственного и место хранения записей. Это операционная проверка, а не обещание, что выбранная архитектура исключает компрометацию.

07

Частые вопросы и выбор среды

Вопросы о повторном использовании Runner, внешних Pull Request, очистке и хранении ключей подписи разобраны в FAQ статьи. Если после проверки вы обнаружили, что одна машина одновременно принимает недоверенный код и имеет доступ к секретам выпуска, сначала разделите эти сценарии. Не рассчитывайте решить конфликт простым удалением рабочей папки.

Если вам нужен отдельный macOS-хост для доверенной сборки или выпуска, удалённый Mac может избавить от необходимости покупать и постоянно обслуживать собственную физическую машину. Но он не исправит чрезмерные разрешения workflow, не отделит автоматически внешние Pull Request и не изолирует секреты. Перед выбором сверьте описание доступных вариантов Mac с вашим способом подключения, конфигурацией Runner и правилами хранения ключей.

Для временного проекта или отдельной сборочной задачи аренда Mac у VpsMesh может быть удобнее покупки устройства, если вам нужен доступ к macOS, а эксплуатацию Runner и границы секретов вы готовы настроить самостоятельно. Если же вам необходима подтверждённая одноразовая изоляция, сначала проверьте, что выбранная инфраструктура действительно создаёт и уничтожает отдельную среду: аренда удалённого Mac сама по себе этого не гарантирует.