Ключевые тезисы
- Не передавайте на runner долгоживущие облачные ключи: выпускайте разрешения на загрузку в control plane; runner потребляет одноразовые URL или ролевые сессии порядка минут.
- Предподписанные URL хорошо сужают радиус поражения: фиксируйте бакет, префикс, HTTP-глагол, заголовки контрольной суммы и срок действия — в лог пишите
grant_id, а не секрет. - Схемы в духе STS добавляют учёт: assume-role с external ID, теги сессии для
tenant_id/pipeline_idи обязательная ротация, привязанная к длительности аренды runner. - Целостность — это манифест, а не ощущение: фиксируйте дайджесты, идентификаторы ключей подписи и аттестации runner в одной структурированной строке на версию артефакта.
1. Модель угроз: что на самом деле хотят атакующие
Скомпрометированные runner редко выводят данные через «красивые» REST API — чаще снимают переменные окружения, подменяют CI-секреты или переигрывают токены из логов. Цель — чтобы даже при доступе к shell злоумышленник получил не больше короткого окна записи в заранее заданный префикс и не мог выпускать новые гранты изнутри аренды. Это требует разделить авторизацию загрузки (control plane) и механику загрузки (runner) и по возможности не оставлять IAM-пользователей на гостевой системе.
Для платформы Apple история целостности не заканчивается байтами архива: подпись кодом и квитанции нотаризации уже задают дисциплину границы секретов на тех же хостах. Тот же операционный подход применим и к обычным blob-артефактам — см. Apple Silicon, облачный Mac: iOS/macOS CI — codesign, нотаризация, stapler и границы связки ключей: воспроизводимый конвейер и таблица типичных отказов, где разобрано, как учётные данные и идентичность артефакта сопрягаются на runner.
2. Предподписанные URL и краткоживущие STS-сессии
Предподписанные URL переносят решение о праве в control plane: runner получает непрозрачный адрес, в котором уже зашиты политика (глагол, ключ объекта, при необходимости KMS для SSE, потолок размера). Пока секрет не становится «фоновой» переменной окружения, поверхность утечки уже меньше — при условии, что вы запрещаете широкие маски ключей и держите TTL в минутах.
Федерация в стиле STS (assume-role у облачного провайдера, OIDC от CI IdP или собственный брокер) уместна при multipart-загрузках, множестве объектов за сборку или динамических именах ключей. Привязывайте сессию к runner_lease_id, ограничивайте длительность ожидаемым временем job плюс небольшой запас и добавляйте ABAC-теги, чтобы журналы в духе CloudTrail оставались фильтруемыми по арендатору. Не переиспользуйте один и тот же external ID между средами — это незаметно объединяет радиус компрометации.
| Шаблон | Когда уместен | Риски |
|---|---|---|
| Presigned PUT/POST | Мало объектов; жёсткие ключи; минимум логики на runner | Сдвиг часов и истечение срока; логирование полных URL; отсутствие принудительных checksum |
| Краткая роль / сессия | Multipart, динамические манифесты, много слоёв кеша | Избыточные trust policy; сессии живут дольше аренды runner |
| Гибрид | Крупные артефакты через multipart и роль; метаданные — маленьким предподписанным JSON | Разные наборы полей аудита на двух путях |
Логи без утечки полномочий загрузки
Структурированные журналы должны содержать grant_id, бакет, нормализованный префикс объекта, принципала, выдавшего грант, и остаток TTL на старте загрузки — но не query-string предподписанного URL. Для STS фиксируйте role_arn, имя сессии и набор тегов; ротируйте доверенные цепочки по опубликованному графику, чтобы инцидент-менеджмент мог ответить «какая цепочка доверия была активна в 14:03 UTC?» без раскопок тикетов.
3. Проверки целостности runner до этапа «promote»
Считайте каждый выход сборки недоверенным, пока к моменту завершения загрузки не собраны доказательства: криптографический дайджест (SHA-256 или сильнее), при необходимости подписи в духе Sigstore, SHA коммита, версии toolchain и идентификаторы job/workflow OpenClaw. Клиент загрузки должен передавать Content-SHA256 или эквивалент там, где хранилище это проверяет — тогда подмена по пути даёт жёсткий отказ, а не тихую порчу данных.
При нехватке RAM компиляции и тесты становятся нестабильными; команды иногда «лечат сеть», хотя узкое место — конкуренция за память. Опирайтесь на телеметрию размеров runner, чтобы проверки целостности не маскировали хаос на хосте — см. Apple Silicon, облачный Mac Runner: пики памяти и управление swap — совместная работа компиляции, Docker и Xcode: метрики наблюдения, стратегии деградации и границы памяти тарифов про связь сигналов swap и стабильности CI на Apple Silicon.
4. Конвейер приёма и аудиторская цепочка
Спроектируйте три согласованные записи: (1) грант выдан — кто утвердил объём загрузки; (2) аттестация runner — манифест дайджестов и метаданные аренды; (3) подтверждение хранилища — version ID или ETag из бакета. Связывайте их общим artifact_id, который проходит через события OpenClaw, чтобы потребители webhook и запросы SIEM использовали один словарь. Входящие колбэки и поля трассировки лучше выровнять с тем, как вы уже описали низкое доверие к HTTP-границе — см. OpenClaw: колбэки и облачные Mac runner — низкое доверие к входящим, изоляция выполнения и идемпотентные повторы: как спроектировать наблюдаемость и поля аудита.
Неизменяемые логи лучше скриншотов: стримьте структурированный JSON в ваш ярус хранения, маскируйте предподписанные query-string в событиях, храните только отпечатки материалов подписи. Когда аудитор спрашивает «могли ли подменить бинарник в середине конвейера?», ответ опирается на согласованные метки времени control plane, агента runner и доступа к объектному хранилищу — а не на прозу в постмортеме.
5. Заключение
Минимальные привилегии на вывод артефактов — в основном скучная инженерия: короткие TTL, жёсткие префиксы и манифесты. Именно она позволяет наращивать автоматизацию, не превращая каждый облачный Mac runner в «ходячие админские учётки». Закладывайте контролы в шаблоны job OpenClaw заранее: внедрять запрет по умолчанию на ACL объектов после инцидента дороже и шумнее, чем включить его в первый день эксплуатации.
На облачном Mac узкий egress хорошо сочетается с пропускной способностью Apple Silicon
Runner на Apple Silicon быстрее прожёвывают архивы Xcode, когда RAM и диск рассчитаны на пиковое совпадение нагрузок, а macOS естественно стыкуется с OIDC и сценариями связки ключей — это важно, когда загрузка артефактов идёт с того же lease, что и подпись. Выделенная облачная Mac mini даёт предсказуемую конкуренцию по CPU, так что TTL предподписанных URL и длительность STS-сессий можно держать жёсткими без хронических срывов по времени.
Если вам нужны сборки под OpenClaw на железе, которое можно изолировать и измерять, kvmboot: облачная Mac mini M4 — практичная отправная точка — смотреть тарифы и конфигурации и выровнять политику вывода артефактов с реально контролируемым оборудованием.