Файл сборки перечисляет не все входные данные. Во время CI пакетный менеджер, плагин или install-скрипт может скачать код из сети, обратиться к новому домену либо получить изменившийся файл по прежнему URL. Если эти запросы не видны команде, воспроизвести артефакт и объяснить его состав после инцидента будет трудно. Выход в интернет нужно проектировать как часть supply chain: проводить через контролируемую точку, записывать зависимости и блокировать неизвестные загрузки.

В октябре 2025 года Launchpad разрешил пользователям включать fetch service для сборки snaps, charms, rocks и пакетов Sourcecraft. Сервис работает как контекстный forward proxy: пропускает внешние запросы по политике, фиксирует обращения и зависимости, готовит manifest и сохраняет скачанные артефакты для архивирования и извлечения метаданных. Из этой реализации следует практичный шаблон для любой CI-платформы.

Сетевой запрос — такой же вход, как исходный код

Команда обычно тщательно проверяет Git commit и параметры pipeline, но оставляет сборочному контейнеру свободный интернет. Тогда два запуска одного commit могут получить разные данные. Причиной станет обновлённый тег, удалённая зависимость, сменившийся redirect или компрометация ресурса, который не был явно учтён.

Первый шаг — изменить модель: каждый внешний ответ влияет на итоговый артефакт. Для расследования нужны не только логи компилятора, но и список сетевых обращений, разрешённый политикой источник, digest полученного объекта и связь с конкретной сборкой. Такой журнал отвечает на вопрос «что попало внутрь», а не только «какая команда выполнялась».

Launchpad Builders не имеют прямого доступа в интернет. Для внешнего запроса сборка получает токен и использует ограниченный proxy. Fetch service добавляет к сетевому контролю контекст сессии: какой build запросил ресурс и какие зависимости были получены. Это сильнее обычного allowlist, который решает только, куда разрешено подключаться.

Ограничивайте полномочия временем одной сборки

Актуальное руководство Launchpad описывает сессию из пяти этапов. Менеджер создаёт session ID и token, сборка использует их для запросов через proxy, затем token отзывается после pull-фазы или завершения работы. Launchpad забирает metadata с запросами и зависимостями, после чего завершает сессию и удаляет её данные из базы fetch service.

Для собственной платформы важен принцип, а не внутренние порты Launchpad. Сетевое полномочие должно принадлежать одной сборке и иметь короткий жизненный цикл. Общий бессрочный proxy credential для всех runner лишает журнал контекста и увеличивает последствия утечки.

Свяжите выдачу доступа с immutable build ID. После стадии, которой нужна сеть, отзовите credential, даже если последующие шаги продолжаются. Metadata перенесите в хранилище артефактов до завершения сессии. Тогда post-build скрипт не сможет незаметно скачать ещё один исполняемый файл, а расследование сохранит связь «сборка — запрос — объект».

Начните с permissive, но назначьте дату перехода в strict

Fetch service поддерживает две политики. permissive записывает нарушение и предупреждает, а strict останавливает запрос, который не прошёл проверку. В Launchpad strict используется по умолчанию, но при внедрении контроля в существующий pipeline немедленная блокировка часто показывает не угрозы, а годы неучтённых зависимостей.

Проведите ограниченный discovery-этап в permissive:

  1. выберите один тип артефакта и несколько репрезентативных сборок;
  2. соберите фактические домены, протоколы, redirects и типы загружаемых объектов;
  3. разделите обращения на обязательные, случайные и необъяснённые;
  4. закрепите версии и digests там, где сборка полагалась на плавающий ресурс;
  5. сформируйте минимальную политику и повторите сборку;
  6. переключите пилот в strict и проверьте обычный и аварийный сценарии.

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

Allowlist должен описывать ресурс, а не только домен

Разрешение всего домена слишком широкое. На одном host могут находиться доверенный registry, пользовательские файлы и endpoint, который возвращает произвольный контент. Launchpad использует inspectors для разных протоколов и типов загрузок; конфигурация может учитывать URL для Git и craft, publisher для snap, а для APT — repository, distribution и component.

Применяйте тот же подход в своей среде. Политика должна отвечать на четыре вопроса:

  • какой клиент или протокол делает запрос;
  • какой namespace, repository или path разрешён;
  • какая идентичность издателя допустима;
  • как проверяется целостность полученного объекта.

Сначала разрешайте точную потребность. Расширяйте правило только после разбора отказа. Запись *.example.org/** удобна, но плохо объясняет, какой ресурс нужен сборке и почему ему доверяют.

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

Manifest даёт трассируемость, но не гарантирует воспроизводимость

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

Для воспроизводимости соедините сетевой manifest с фиксацией версий и проверкой digest или подписи. Храните его рядом с артефактом, build recipe, commit и результатами проверок. При повторной сборке сравнивайте не только успех pipeline, но и набор внешних входов. Новый домен, исчезнувшая зависимость или изменившийся digest — повод остановить продвижение артефакта и разобраться в причине.

Не записывайте в manifest секреты из URL, заголовков и query parameters. Наблюдаемость supply chain не должна создавать новый канал утечки. Сохраняйте минимальные идентификаторы ресурса, digests и технические статусы; чувствительные поля редактируйте до долговременного хранения.

Отказ strict-политики должен быть понятным и обратимым

Когда strict блокирует загрузку, разработчик должен увидеть, какое правило сработало, какой ресурс запрашивался и куда подать изменение политики. Сообщение «network denied» заставит команду искать обход: другой proxy, vendored binary без provenance или временное отключение контроля.

Создайте runbook для трёх случаев: легитимная новая зависимость, недоступность разрешённого источника и подозрительный запрос. Изменение allowlist проводите через review с владельцем и причиной. Аварийный возврат в permissive ограничивайте конкретным pipeline и сроком, сохраняйте все предупреждения и требуйте последующего разбора. Глобальный silent fallback уничтожит саму границу доверия.

Ограничения нужно принять до rollout

В Launchpad fetch service доступен только для snaps, charms, rocks и пакетов Sourcecraft. Это не универсальный контроль всех видов сборок. В собственной платформе тоже останутся runner, протоколы или legacy-процессы, которые proxy пока не понимает. Их нужно видеть в реестре исключений, а не считать автоматически защищёнными.

Контролируемый egress добавляет зависимость от proxy и политики. Ошибка конфигурации остановит сборку, а недоступность сервиса повлияет на delivery. Поэтому rollout начинается с пилота, включает проверку отказа и предусматривает наблюдаемость самой точки контроля.

Главная практика проста: сначала сделайте сетевые входы видимыми, затем сузьте правила и включите блокировку. Сессионный credential уменьшает blast radius, inspectors проверяют контекст запроса, manifest сохраняет фактический состав, а pins и digests превращают наблюдение в воспроизводимый процесс. Свободный интернет удобен для CI, но не оставляет доказательств; контролируемый egress делает сборку объяснимой.

Источник и лицензия

  • Автор: Vaishnavi Asawale (vaishnavi-asawale).
  • Организация и корпоративный блог: Launchpad Blog, Canonical Ltd.
  • Исходная статья: Make fetch service opt-in, 28 октября 2025 года.
  • Лицензия исходного материала: Creative Commons Attribution 2.0 UK: England & Wales.
  • Это самостоятельная русская адаптация: исходный материал переведён, сокращён и редакционно переработан для DevOps/SRE/Platform-аудитории. Актуальные ограничения, режимы и жизненный цикл сессии сверены с руководством Launchpad от 22 апреля 2026 года. Добавлены поэтапный rollout, правила allowlist, обращение с секретами, граница между трассируемостью и воспроизводимостью, а также эксплуатационные сценарии отказа. Canonical и автор исходной статьи не одобряли эту публикацию и не связаны с ней.