Симптом: обычная проверка pull request получает доступ к тем же секретам, что и производственный выпуск, поэтому один неверно маршрутизированный job может затронуть сертификаты и внутренние ресурсы.

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

Эта статья предназначена для трёх групп. IT-руководителю она помогает определить требования к изоляции, удалённому восстановлению и аудиту. Руководителю инженерной эффективности — правильно разделить сборку, архивирование, подпись и загрузку. Техническому директору или закупщику — сравнить общую Mac-инфраструктуру, выделенный удалённый Mac и смешанный пул без необоснованных обещаний экономии.

Начните с разделения задач и активов

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

Полезно разделить поток на несколько зон:

  • Обычный пул сборки — исходный код, зависимости, тестовые данные и результаты компиляции.
  • Контролируемый пул архивирования — проверенный коммит, фиксированная версия Xcode и подписываемый кандидат.
  • Производственный узел подписи — закрытые ключи, профиль распространения, временный Keychain и операция выпуска.
  • Контур загрузки — App Store Connect API Key или иной разрешённый механизм загрузки, отделённый от локальной учётной записи администратора.

Apple описывает сертификаты как разные типы активов с различным назначением, поэтому сам факт наличия сертификата на Mac ещё не означает право выполнять весь релизный процесс. Состав сертификатов и их назначение следует сверять с официальным обзором сертификатов Apple, а не с названием переменной в CI.

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

Важно: сертификат, закрытый ключ, Provisioning Profile, запись macOS Keychain, App Store Connect API Key, токен CI и локальная учётная запись Mac — разные активы. Их нельзя описывать одним общим термином «секреты».

Почему переменной окружения недостаточно

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

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

Первый шаг: определите профиль команды

Решение должно начинаться не с покупки Mac, а с определения того, кто может запускать задачи и какие задачи считаются производственными.

Один продукт и небольшая команда

Логическая изоляция на одной машине допустима, если одновременно выполняются все условия:

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

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

Несколько репозиториев или продуктовых команд

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

Вместо одной общей группы задач разумнее использовать три логических пула:

  • общий пул для компиляции и тестов;
  • контролируемый пул для архивирования проверенных изменений;
  • производственный пул для подписи и загрузки.

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

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

Регулируемая среда и высокий уровень аудита

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

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

Роли программы разработчика Apple, локальный администратор macOS, администратор CI и право публикации в App Store Connect не являются взаимозаменяемыми. Перечень ролей и полномочий следует сверять с официальной таблицей ролей Apple Developer.

Для загрузки необходимо отдельно оценить App Store Connect API Key. Apple публикует для него самостоятельную модель доступа, поэтому API Key нельзя смешивать с правами локального пользователя или с закрытым ключом сертификата подписи. Детали следует проверять по официальному описанию App Store Connect API.

Второй шаг: зафиксируйте границы Keychain и сертификатов

macOS Keychain — это не просто папка, куда копируется файл сертификата. В ней хранятся элементы, для которых действуют правила доступа, блокировки и использования процессами.

При проектировании узла необходимо отдельно описать:

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

Возможности Keychain Services и правила работы с элементами описаны в документации Apple по Keychain Services. Для более узкого контроля следует учитывать списки контроля доступа Keychain, а также ограничения доступности элементов после блокировки и перезапуска, изложенные в документации по доступности элементов Keychain.

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

Проверка полномочий по принципу «кто инициирует»

Команда должна отделить четыре события:

  • создание или запрос сертификата;
  • импорт сертификата и закрытого ключа;
  • использование ключа в процессе подписи;
  • отзыв и восстановление после компрометации.

Отзыв сертификата может остановить выпуск, поэтому процедуру нельзя оставлять только у одного администратора. Apple отдельно описывает последствия и порядок отзыва сертификата. В корпоративной матрице также нужно указать, какие профили и автоматические процессы потребуется заменить после отзыва.

Третий шаг: сравните архитектуры до закупки

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

Архитектура Когда подходит Основное преимущество Главный риск Доказательство перед допуском
Общая Mac-машина с логической изоляцией Один продукт, редкие релизы, стабильные права Меньше отдельных узлов и проще начальная доставка Ошибка в аккаунте, маршруте или очистке затрагивает подпись Тест раздельных аккаунтов, Keychain, перезапуска и запрета PR
Выделенный удалённый Mac Постоянные производственные релизы, несколько команд, строгий аудит Ясная граница доверия и предсказуемый контур восстановления Простой узла и отдельные расходы при нерегулярной загрузке Чистое восстановление, отзыв доступа, журнал действий и контроль выхода
Смешанный пул Общие сборки меняются по нагрузке, подпись стабильна Общий ресурс для обычных задач и отдельная защита выпуска Ошибочная маршрутизация между пулами Матрица разрешённых репозиториев, изолированный production-маршрут и тест отказа

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

Для предварительного расчёта команды могут сравнить условия аренды удалённых Mac RUVCLOUD с покупкой собственного оборудования. Но в TCO следует включить не только тариф или цену устройства, а также простой, замену, резервный доступ, работу администратора, безопасное уничтожение ключей и время восстановления.

Четвёртый шаг: примите узел через восстановление

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

Порядок приёмки:

  1. Создать тестовый проект или использовать непроизводственную схему подписи без настоящих распределительных активов.
  2. Проверить вход обычного CI-пользователя и убедиться, что он не может вызвать производственную задачу.
  3. Создать временный Keychain, импортировать только необходимые тестовые материалы и проверить доступ конкретного процесса.
  4. Выполнить компиляцию, архивирование, подпись и загрузку тестового артефакта отдельными этапами.
  5. Перезапустить Mac, закрыть пользовательский сеанс и повторить операции, которые должны работать автоматически.
  6. Заблокировать Keychain и подтвердить, что отказ выглядит ожидаемо, а не приводит к несанкционированному обходу.
  7. Удалить тестовый доступ, отключить старого пользователя и проверить, что прежний Runner не может обратиться к production-маршруту.
  8. Зафиксировать журналы, ответственных лиц, необходимые входные данные и порядок отката.

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

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

Пятый шаг: примените условное решение

Следующий список позволяет выбрать вариант без привязки к размеру команды как к единственному критерию:

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

FAQ для корпоративного решения

Можно ли выполнять сборку и подпись iOS на одном Mac?

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

Нужен ли компании отдельный Mac для подписи релизов iOS?

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

Как разделить сертификаты и Keychain на общем Mac?

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

Как принять удалённый Mac в роли узла подписи?

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

Шестой шаг: подготовьте закупку и пилот

В запросе на инфраструктуру следует описывать не только модель Mac или способ удалённого подключения. Для подписывающего узла важнее следующие вопросы:

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

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

Итог для IT-руководителя

Узел подписи iOS CI не обязан быть отдельным в каждом небольшом проекте, но производственная подпись не должна автоматически соседствовать с обычной компиляцией и непроверенным кодом. Для одной контролируемой команды возможна логическая изоляция, если она подтверждена раздельными аккаунтами, временным Keychain, строгой маршрутизацией и повторным тестом после перезапуска.

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

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