В документации GitHub указано: macOS larger runners не предоставляют статический IP и Azure private networking (описание сетевых ограничений).
Симптом: сборке нужен внутренний сервис или фиксированный адрес в allowlist. Быстрое решение: не назначайте macOS larger runners без проверки; сначала подтвердите ограничения, затем испытайте посредника или выберите Mac с необходимым сетевым маршрутом.

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

Сценарий: все зависимости доступны извне

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

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

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

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

Преимущество размещённого runner в этом сценарии — меньшая нагрузка на команду по обслуживанию физического узла. Недостаток — вы зависите от предоставляемых платформой сетевых возможностей и не можете считать сетевое окружение эквивалентом корпоративной подсети. Проверьте актуальные ограничения macOS larger runners в официальной документации по размещённым runner.

Сценарий: сборке нужен частный реестр или сервис

Может ли macOS larger runner обращаться к частному хранилищу пакетов?

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

Нарисуйте короткую схему для каждого необходимого вызова:

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

Затем сверяйте предложенный способ подключения с документацией именно по macOS larger runners. Материалы о сетевом подключении для GitHub-hosted runners могут описывать общие подходы, но это не доказывает, что конкретная возможность доступна целевому runner. Например, инструкция по подключению к API-шлюзу через OIDC описывает вариант аутентификации. Она сама по себе не подтверждает сетевую достижимость любого внутреннего адреса из macOS runner.

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

Важно: успешная проверка OIDC подтверждает получение или предъявление идентичности в соответствующем контуре, а не автоматически создаёт маршрут до внутренней сети. Отдельно проверяйте аутентификацию, разрешение доступа и сетевую связность.

Для промежуточного доступа документация GitHub описывает варианты с API-шлюзом и сетевым покрытием, включая подход на основе WireGuard. Выбирайте их только после проверки применимости к нужному macOS runner, целевому сервису и политике организации. Если область действия документации не охватывает ваш вариант, фиксируйте его как гипотезу, а не как готовую функцию.

Сценарий: межсетевой экран требует фиксированный адрес

Поддерживают ли macOS larger runners статический IP для allowlist?

По документации GitHub, статический IP для macOS larger runners не предоставляется. Там же указано, что Azure private networking для этого типа runner недоступна (ограничения macOS larger runners). Если правило межсетевого экрана действительно требует постоянный исходящий адрес, не переносите на macOS описание возможностей другого типа runner.

Сначала уточните, что именно означает «нужен allowlist». В разговоре этим словом могут обозначать разные требования: фиксированный адрес источника, разрешение на исходящий запрос, ограничение входящих соединений или допуск только аутентифицированной рабочей нагрузки. Попросите владельца сервиса или сетевой команды назвать точное условие и показать соответствующее правило. IP-фильтр нельзя заменить токеном без согласования; токен, в свою очередь, не подтверждает требуемый сетевой маршрут.

Если статический адрес — жёсткое условие, оцените собственный Mac, размещённый так, чтобы его сетевой путь соответствовал корпоративной политике. Это не означает, что регистрация собственного runner автоматически откроет ему доступ к внутренним сервисам. Важны расположение узла, правила маршрутизации, DNS, исходящий фильтр и разрешения на самом целевом сервисе.

Возможные варианты и компромиссы:

  • Размещённый macOS runner: меньше задач по обслуживанию хоста, но его нельзя считать источником со статическим IP, если это прямо не подтверждено для выбранной конфигурации.
  • Собственный Mac в контролируемой сети: позволяет проектировать маршрут и правила под предприятие, но команда отвечает за обновления, доступ, мониторинг и восстановление узла.
  • Промежуточный сервис или шлюз: может быть уместен, если нужная операция представима через ограниченный API и способ поддерживается конкретной конфигурацией. Маршрут и область полномочий нужно испытать отдельно.
  • Смешанная схема: публичную сборку можно отделить от шага, которому требуется доступ к внутреннему ресурсу; при этом нужно безопасно передать артефакт и ограничить право публикации.

Для доступа к private networking важно сверять не только название продукта, но и область применимости. В частности, документ об Azure private networking для GitHub-hosted runners описывает свой целевой охват. Не распространяйте его на macOS larger runners вопреки указанным выше ограничениям.

Сценарий: доступ можно организовать через контролируемого посредника

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

Рассмотрите вариант с OIDC, если сервис или шлюз умеет проверять идентичность workflow и политика предприятия допускает такую схему. Ограничьте полномочия конкретными репозиториями и задачами, не выдавайте широкую учётную запись только ради проверки связности. Зафиксируйте, какие утверждения идентичности проверяются и где регистрируется результат. В документации GitHub есть пример аутентификации API-шлюза через OIDC, но целевой сценарий всё равно требует собственной проверки.

Сетевое покрытие оценивайте отдельно от API-шлюза. Проверьте, откуда устанавливается туннель, какие узлы могут связываться через него и кто хранит необходимые ключи. Нельзя считать, что наличие инструкции по WireGuard автоматически означает поддержку именно вашего macOS runner или разрешение использовать такое соединение в вашей организации.

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

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

Сценарий: для сети нужен собственный Mac Runner

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

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

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

Сравните ответственность до выбора:

  • Собственный узел в корпоративной сети: даёт возможность настраивать путь к внутренним ресурсам, но требует владельца патчей, учётных записей, мониторинга, очистки рабочих каталогов и восстановления.
  • Удалённый Mac с доступом через VNC или SSH: может помочь администрировать узел, однако удалённое управление не является сетевой изоляцией и не заменяет контроль заданий runner.
  • Размещённый runner: снимает с команды часть обязанностей по эксплуатации хоста, но не решает требование фиксированного IP или частного маршрута, если такой возможности нет в документированных условиях.

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

Сценарий: часть этапов должна идти по разным маршрутам

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

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

Затем испытайте реальный путь: направьте публично доступную задачу на размещённый runner, а задачу с внутренней зависимостью — на узел или посредника с подтверждённым маршрутом. Проверьте происхождение результата, передачу артефакта, подпись и доступ к финальному хранилищу. Если смена runner приводит к различию окружений, зафиксируйте это как отдельный риск совместимости.

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

Перед принятием решения пройдите чек-лист:

  • [ ] Перечислены все внешние и внутренние адреса, к которым обращается workflow.
  • [ ] Для каждого частного сервиса определены инициатор соединения, требуемый маршрут и способ аутентификации.
  • [ ] Подтверждено, требует ли сетевое правило именно статический IP, а не иной вид идентификации или допуска.
  • [ ] Ограничения macOS larger runners сверены с официальной документацией, без переноса функций с Linux или Windows.
  • [ ] Посредник или туннель испытан на целевом macOS runner; его область применимости не предполагается по аналогии.
  • [ ] Собственный Mac проверен на разрешение имён, подключение к сервисам, отказ при недостаточных правах и аудит.
  • [ ] Для каждого этапа разделены артефакты, секреты и право публикации.
  • [ ] Указаны эксплуатационные владельцы, нерешённые ограничения и критерии возврата к прежней схеме.

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

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