Безопасен ли self-hosted Mac Runner в GitHub Actions? Чек-лист приёмки 2026

GitHub предупреждает, что self-hosted Runner может быть скомпрометирован недоверенным кодом workflow, который на нём выполняется (официальное руководство по безопасному использованию GitHub Actions). Поэтому безопасность self-hosted Mac Runner в GitHub Actions зависит не от того, что это Mac или приватный репозиторий, а от доверия к коду, прав запуска, доступа к секретам и очистки между заданиями.

На этой неделе проверьте, какие события направляют код на Runner и какие секреты там доступны. Пока вы не можете отделить недоверенные PR от задач подписи и публикации, не используйте этот Runner для релизов с производственными учетными данными.

Материал для независимых разработчиков, настраивающих GitHub Actions для сборки iOS-приложения.
Для небольшой команды, которая должна отделить обычные проверки от сертификатов и ключей публикации.
Для ответственного за релизы, которому нужно подтвердить права доступа, очистку среды и безопасное совместное использование Runner.

Сначала определите, какие задания Runner вправе выполнять

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

В таблице — стартовое разделение по уровню доверия. Это не готовая конфигурация: сверяйте каждую строку с реальными условиями запуска и настройками репозитория.

Проверьте не только имя события, но и путь от события к исполняемому коду. GitHub описывает события, запускающие workflow, а для pull_request_target отдельно предупреждает об опасности небезопасной обработки кода PR. Этот триггер получает контекст базовой ветки; если затем без должных мер загрузить и выполнить код PR, проверка может перейти границу привилегий (рекомендации GitHub по безопасному использованию pull_request_target).

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

Быстрая оценка готовности

Оценки ниже — рабочая схема принятия решения, а не официальный рейтинг GitHub или характеристика конкретного Mac.

Если обнаружен стоп-сигнал в доступе к ключу или исполнении недоверенного кода, не компенсируйте его успешным тестовым релизом. Сначала сузьте права или разделите задания и хосты, затем повторите проверку.

Для PR нужна граница между проверкой кода и привилегированным запуском

Проверка PR полезна именно потому, что оценивает ещё не принятый код. Поэтому внешний или недоверенный PR следует считать потенциально способным выполнить команды в доступной ему задаче. Проверьте, какой Runner получает задание, доступны ли ему секреты и может ли код менять или использовать шаги с привилегированными полномочиями.

Для первичной проверки используйте Runner без сертификатов, закрытых ключей и учетных данных App Store Connect. Убедитесь, что он не разделяет рабочую среду с релизной задачей так, что данные одной задачи становятся доступными другой. Если выполняете код PR в особом workflow, вручную проследите каждый переход от события к checkout, затем к командам сборки и публикации; одного названия триггера для оценки недостаточно.

Отдельно проверьте повторный запуск workflow и действия, доступные автору PR. Факт, что секреты не вставлены непосредственно в YAML, ещё не означает, что код не может получить их через окружение, доступный инструмент или последующую привилегированную задачу. Ваша цель — подтвердить границу на уровне фактического выполнения, а не только формально увидеть запрос на одобрение.

Для доверенной сборки ограничьте токены, Actions и назначение Runner

Даже если в ветку попадает только проверенный код, сборке не нужен автоматически весь набор прав репозитория. В YAML укажите только необходимые разрешения GITHUB_TOKEN; синтаксис workflow позволяет задавать права явно (документация GitHub по permissions). Сопоставьте разрешения с действиями задачи: чтение исходников, загрузка артефакта или публикация — это разные операции и не должны по умолчанию получать одинаковый доступ.

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

Runner должен быть доступен только тем репозиториям и workflow, которым он действительно нужен. Сверьте настройки с официальным описанием управления доступом к self-hosted Runner: настройка на странице организации или репозитория имеет значение лишь тогда, когда соответствует фактическому кругу пользователей и проектов. Запишите, кто вправе менять эту политику и кто может менять workflow, способный назначить Runner.

Подпись и публикация требуют отдельного доступа к ключевому материалу

Apple указывает, что для подписи приложения нужна целостная подписывающая личность: сертификат и соответствующий ему закрытый ключ (документация Apple о синхронизации подписывающих сертификатов команды). Это означает, что публикационный риск связан не с одним файлом сертификата: важны все данные, позволяющие задаче подписать приложение, а также учетные данные для передачи сборки.

Составьте перечень отдельно для сертификата, закрытого ключа, пароля к связке ключей и учетных данных App Store Connect. Для каждого пункта укажите, какая задача его читает, кто вправе изменить эту задачу и в каких каталогах или журналах данные могут оказаться. Не используйте реальные ключи в тестовом примере, документации или команде, попадающей в лог.

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

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

Между заданиями проверяйте фактическую очистку Mac

Self-hosted Runner нельзя считать чистой изолированной машиной после каждого задания. GitHub рекомендует учитывать риск от недоверенного кода и рассматривать изоляцию среды; описание self-hosted Runner и его ограничений не даёт оснований автоматически приравнивать регистрацию одноразового Runner к очистке нижележащего хоста.

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

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

Несколько репозиториев повышают требования к управлению доступом

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

Не объединяйте проекты только потому, что у них одинаковые требования к Xcode. Сопоставьте владельцев репозиториев, права на изменение workflow, необходимость подписи и последствия утечки. Если независимая команда может изменить код, который запускается на хосте с ключами другого проекта, общей принадлежности к организации недостаточно для обоснования доверия.

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

Четыре решения для типовых сценариев

Публичные PR. Технически проверить код PR можно, но это не означает, что его следует направлять на релизный Mac. Если workflow исполняет непроверенные изменения, используйте среду без производственных секретов и не допускайте доступа к задачам подписи. Если такой границы нет, отключите этот путь к self-hosted Runner.

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

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

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

Решения, которые не стоит принимать по одному признаку

Ниже — ветвящийся критерий допуска. Выбирайте путь только после проверки всех условий в соответствующей строке.

• Если PR запускаются на среде без секретов, привилегии workflow ограничены и фактический код не попадает в релизный контекст, то оставьте Runner только для такого класса проверок; иначе перенаправьте PR на отдельную изолированную среду.
• Если токен имеет только нужные workflow права, сторонние Actions контролируются, а назначение Runner ограничено авторизованными репозиториями, то переходите к проверке подписи; иначе сначала исправьте доступы.
• Если закрытый ключ доступен только доверенному релизному заданию, а журналы и временные файлы не раскрывают секреты, то проверьте очистку; иначе не допускайте этот хост к публикации.
• Если вы можете подтвердить очистку после успешного и аварийного задания и разделение между проектами, то разрешайте использование в пределах этих правил; иначе исключите общую эксплуатацию и разделите среды.
• Если хотя бы одну критическую границу нельзя подтвердить конфигурацией или записью проверки, то не используйте Runner для производственного релиза с ключами подписи.

FAQ: недоверенные PR, ключи и совместное использование

Можно ли запускать PR из публичного репозитория на Mac Runner?

Технически — да, но не следует направлять недоверенный код на хост, доступный релизным заданиям или содержащий секреты. Проверьте событие, фактически исполняемый коммит и права workflow. Для первичной проверки используйте отдельную среду без ключей и учетных данных публикации.

Нужно ли хранить сертификат и закрытый ключ iOS на Runner?

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

Можно ли нескольким workflow пользоваться одной машиной?

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

Как понять, что после задания не остались секреты?

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

Зафиксируйте приёмку до первого производственного релиза

Сохраните проверяемую запись, а не только отметку «workflow прошёл». Укажите события запуска и фактический код, список разрешений токена, источники Actions, репозитории с доступом к Runner, задачи с доступом к ключам, результаты проверки журналов и очистки, а также действия при сбое. Отдельно зафиксируйте нерешённые риски и лицо, которое принимает решение о выпуске.

Затем выполните представительную проверку: PR без секретов, доверенную сборку и релизную задачу с подписью — раздельно и в тех условиях, которые реально будут использоваться. Сравните конфигурацию workflow с фактическими журналами и состоянием хоста. Успешная сборка подтверждает, что получен артефакт; она не подтверждает, что токены были ограничены, ключи защищены или следующее задание не унаследует остатки.

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

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