GitHub Actions self-hosted Mac Runner: одноразовый или постоянный? Выбор 2026

Граница доверия важнее принадлежности Runner

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

Удобно разделить задания на три класса:

• Доверенный код из защищённой ветки. Сборка выполняется по контролируемому workflow, а изменения и выпуск проходят установленную проверку. Постоянный узел можно оценивать, если после каждого запуска проверяется состояние рабочей среды.
• Код внешнего участника или непроверенного изменения. Сборка может исполнять команды из репозитория, включая скрипты зависимостей. Такие задачи следует считать недоверенными, пока проверка не докажет обратное. Рекомендации GitHub по безопасному использованию Actions отдельно предупреждают о рисках выполнения недоверенного кода на self-hosted Runner.
• Подписанный выпуск или операция с повышенными правами. Этот контур получает доступ к средствам подписи, публикации или внутренним сервисам. Его нельзя смешивать с произвольными проверками кода только потому, что обе задачи запускаются в одном репозитории.

Особое внимание нужно уделять workflow, использующим pull_request_target: этот триггер требует отдельного анализа того, откуда берутся команды и данные. Руководство GitHub по безопасному применению pull_request_target описывает риск, связанный с обработкой недоверенного содержимого в контексте повышенных прав. Не выдавайте такому workflow секреты только на основании того, что он определён в доверенном репозитории.

Выбор жизненного цикла и повторное использование

Термины здесь обозначают разные события. Завершение задания говорит, что GitHub Actions закончил выполнение workflow. Снятие регистрации Runner прекращает использование конкретной записи исполнителя. Очистка хоста удаляет или делает недоступными данные, созданные во время задания. Пересоздание чистой среды заново подготавливает основание для следующего задания. Подтверждение одного события не подтверждает остальные.

Поэтому ответ на вопрос о разнице между одноразовой и постоянной моделью — не только в том, останется ли запись Runner в настройках. Постоянная модель облегчает повторное использование настроенного Mac, но увеличивает значение контроля остатков между заданиями. Одноразовая модель ограничивает срок жизни регистрации, но сама по себе не гарантирует чистое состояние диска, пользовательской сессии или Keychain.

Параметр --ephemeral позволяет настроить Runner для одноразового использования; GitHub также описывает регистрацию JIT Runner в документации по self-hosted Runner. Применение этого режима — часть жизненного цикла, а не проверка уничтожения хоста. Процедура удаления self-hosted Runner также описывает снятие исполнителя с регистрации, но не заменяет внутреннюю процедуру организации по очистке Mac.

Очистка хоста и Mac CI

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

Для Mac CI план очистки должен учитывать как минимум:

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

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

Чтобы оценить Mac CI environment isolation, проверяйте не название режима, а наблюдаемый результат. Например, выполните тестовое задание, которое создаёт контрольный файл в рабочем каталоге, оставляет процесс и помещает тестовый маркер в предусмотренную тестовую область. После очистки запустите независимую проверку под тем же контекстом, который будет использовать следующее задание. Зафиксируйте, что именно проверялось, кто подтвердил результат и где хранится запись. Такой тест не доказывает отсутствие всех возможных способов сохранения данных, но обнаруживает разрыв между заявленной и фактической процедурой.

Секреты, токены и сеть

Риск Mac Runner credential security определяется не только тем, где секрет хранится в настройках GitHub. Нужно установить, какие задания могут его получить, в каком контексте он раскрывается, куда процесс может отправить данные и останется ли секрет доступен после завершения работы.

Начните с перечня доступов:

• какие секреты доступны конкретному workflow и окружению;
• какие разрешения назначены GITHUB_TOKEN;
• может ли процесс обращаться к Keychain и средствам подписи macOS;
• доступны ли Runner внутренние адреса, репозитории артефактов и сервисы публикации;
• какие учётные записи или файлы остаются на хосте после завершения задания.

GitHub объясняет управление Secrets в Actions и модель разрешений токена GITHUB_TOKEN. Эти настройки помогают ограничивать доступ на уровне workflow и токена, но не превращают общий Mac в изолированную виртуальную машину для каждого задания. Если задача может исполнять произвольный код в окружении, ей может быть доступно больше, чем видно из списка Secrets: например, файлы, уже оставленные на рабочем узле, или сетевые службы, доступные с него.

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

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

Инструменты, базовое состояние и диагностика

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

Не следует оценивать варианты по обещанному времени сборки без собственного измерения. Для каждого режима сравните на одинаковом наборе workflow:

• версию Xcode и состояние выбранных SDK;
• разрешённые версии зависимостей и воспроизводимость их получения;
• наличие изменений в рабочем каталоге после завершения;
• доступность и состояние симуляторов для следующей задачи;
• сохранность диагностических данных после ошибки;
• возможность повторить сборку на восстановленном узле.

Отдельно проверьте, какие события видны в журнале Runner и какие данные остаются у команды после удаления среды. В рекомендациях GitHub по мониторингу и диагностике self-hosted Runner на Mac описаны способы наблюдать за работой исполнителя. Если хост уничтожается после задачи, журналы и результаты диагностики нужно передавать во внешний контур до его удаления. Иначе можно получить «чистую» среду, но потерять возможность установить причину падения сборки.

Практический порядок проверки выглядит так:

1. Зафиксируйте источник задания. Определите, может ли workflow исполнять код из внешнего изменения, кто одобряет его запуск и какие события запускают обработку.
2. Инвентаризируйте доступы. Сопоставьте Secrets, права GITHUB_TOKEN, Keychain, локальные файлы и сетевые назначения с конкретной задачей.
3. Выберите границу выполнения. Разведите недоверенные проверки, доверенные сборки и операции подписи там, где их права или уровень доверия различаются.
4. Настройте регистрацию. Для одноразового режима используйте предназначенный GitHub механизм ephemeral или JIT и отдельно определите, кто завершает жизненный цикл самого Mac.
5. Опишите очистку. Укажите, удаляется ли рабочее состояние, сбрасывается ли пользовательская среда или пересоздаётся хост; назначьте ответственного и фиксируйте результат.
6. Проверьте восстановление. После тестового задания убедитесь, что контрольные файлы и процессы не доступны следующему запуску, а необходимые инструменты возвращаются в ожидаемое состояние.
7. Перенесите журналы. Сохраните нужные записи до очистки или удаления среды и проверьте, что по ним можно разобраться в тестовом сбое.
8. Повторите испытание с разными классами задач. Успех доверенной сборки не подтверждает безопасность запуска внешнего кода или операции с правами выпуска.

Пример команды конфигурации для ephemeral Runner:

./config.sh \
  --url https://github.com/ORG/REPOSITORY \
  --token "$RUNNER_REGISTRATION_TOKEN" \
  --ephemeral

Значения URL и токена здесь — заполнители, а не рабочие реквизиты. Не записывайте регистрационный токен в репозиторий, команду с раскрытым секретом в журнал или общий файл конфигурации. Перед использованием проверьте актуальные требования GitHub к выбранному способу регистрации и отдельно автоматизируйте действие, которое очищает или пересоздаёт хост. Появление Runner в интерфейсе и его последующее снятие с регистрации сами по себе не подтверждают очистку.

Матрица выбора для платформенной команды

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

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

Когда имеет смысл оценить удалённый Mac

Собственная машина в офисе или уже имеющийся общий Mac могут быть подходящим выбором, если организация контролирует сеть, физический доступ и обслуживание. Но такой вариант несёт конкретные обязанности: закупку и замену оборудования, поддержку доступности, управление удалённым доступом и самостоятельную проверку очистки после CI-задач. Универсальный облачный исполнитель, в свою очередь, не заменяет macOS-среду для задач, которым нужен реальный Mac. Это не означает, что аренда автоматически решает проблему изоляции: ответственность за состояние хоста и очистку необходимо выяснить отдельно.

NodeMini может быть вариантом для оценки, если команде нужен удалённый доступ к реальному Mac без самостоятельного размещения оборудования. Перед пилотом проверьте в описании удалённого Mac подходящий тип доступа и границы предоставляемой среды, а у NodeMini уточните, кто отвечает за очистку или пересоздание хоста между CI-задачами. Если эти условия не подтверждаются, не используйте аренду как доказательство изоляции: сначала организуйте отдельный проверяемый контур. Для вопросов по доступу и организации эксплуатации можно также свериться с центром помощи NodeMini.