Артефакты и container registry¶
Требования применяются к release images, их хранению в container registry и
выбору точного артефакта для non-production и production. Уровни
обязательности определены в корневом README.md.
Release image — image, предназначенный для доставки в non-production или
production; локально собранный image профиля local release image не
является.
INF-ART-001. Единственный release image¶
Уровень: MUST
Применяется к: release image для non-production или production
Delivery pipeline должен принимать release image и доказательства точного
commit по architecture:DEP-CI-001–DEP-CI-005. Image должен иметь
неизменяемый release identifier по architecture:DEV-BUILD-003; digest
рекомендуется architecture:DEP-SUP-004, но MAY заменяться уникальным
непереиспользуемым release tag. Pipeline должен продвигать тот же
идентифицированный image без пересборки. Выбор registry регулируется
INF-SEC-006 и INF-SEC-014.
Обоснование¶
Пересборка создаёт разные исполняемые артефакты для одной версии.
Проверка¶
- сравнение release identifier и фактического image во всех средах;
- сопоставление pipeline с commit SHA.
Исключения¶
Не допускаются.
INF-ART-002. Неизменяемая ссылка¶
Уровень: SHOULD
Применяется к: non-production и production deployment
Отрендеренной deployment-конфигурации следует реализовывать
architecture:DEP-SUP-004 ссылкой на digest sha256. Для multi-platform image
следует использовать digest OCI index и сохранять выбранный platform manifest
в runtime inventory.
Обоснование¶
Digest однозначно определяет полученные байты.
Проверка¶
- статическая проверка отрендеренного image reference;
- запрос manifest в Registry.
Исключения¶
Local-профиль MAY использовать локально собранный tag. Non-production и production MAY использовать уникальный непереиспользуемый release tag, однозначно связанный с commit и содержимым image; mutable tag недостаточен.
INF-ART-003. Метаданные происхождения¶
Уровень: MUST
Применяется к: release image
Delivery pipeline должен проверить OCI labels source URL, revision и version,
заданные architecture:DEP-IMG-011, и сохранить связь release identifier с
GitLab pipeline, commit и release. При наличии provenance по
architecture:DEP-SUP-005 его subject identifier должен обозначать
поставляемый image; при использовании digest значения должны совпадать.
Обоснование¶
Операции требуют обратной трассировки работающего image к исходникам.
Проверка¶
- инспекция OCI labels;
- запрос GitLab job и release по release identifier.
Исключения¶
Не допускаются.
INF-ART-004. Release gate сканирования уязвимостей¶
Уровень: SHOULD
Применяется к: release image
До production delivery pipeline следует проверять успешный результат
сканирования известных уязвимостей по
architecture:DEP-SUP-001–DEP-SUP-002 и отсутствие просроченного исключения.
Delivery pipeline не следует дублировать сборку или изменять report; report
следует связывать с фактически поставляемым release identifier.
Обоснование¶
Базовая проверка предотвращает поставку известных критичных дефектов и утечек.
Проверка¶
- контролируемый image с тестовой уязвимостью;
- подмена release identifier после сканирования;
- review GitLab report и блокировки.
Исключения¶
Проект MAY не включать vulnerability release gate без ADR. Временное исключение для включённого gate требует владельца, срока и ссылки на риск в GitLab.
INF-ART-005. Retention и rollback¶
Уровень: MUST
Применяется к: container registry с production images
Cleanup policy не должна удалять release image, работающий в любой цели, выбранный для rollback или требуемый действующим сроком аудита. Минимальное число и возраст сохраняемых release images должны покрывать проверенное окно rollback независимо от вида release identifier.
Обоснование¶
Rollback неисполним, если Registry уже удалил предыдущий image.
Проверка¶
- сопоставление cleanup policy с runtime и release history;
- rehearsal pull самого старого допустимого rollback image.
Исключения¶
Image с известной критичной уязвимостью MAY быть удалён раньше после запрета rollback и выбора безопасного roll-forward.
INF-ART-006. Доступность Registry¶
Уровень: MUST
Применяется к: production deployment
До остановки старых экземпляров платформа должна подтвердить возможность получить новый image на целевых узлах. Недоступность Registry не должна приводить к удалению всех работающих реплик; runbook должен учитывать использование уже закэшированного точного release image.
Обоснование¶
Работающий сервис не должен становиться недоступным только из-за неуспешного pull новой версии.
Проверка¶
- rollout при недоступном Registry;
- проверка сохранения готовых старых реплик.
Исключения¶
Single-instance Compose deployment MAY иметь согласованное окно недоступности, но должен остановиться до удаления работоспособного container при ошибке pull.
INF-ART-007. Архитектура процессора¶
Уровень: MUST
Применяется к: цели с schedulable-узлами нескольких CPU architectures либо image, поддерживающему несколько platforms
OCI index должен содержать проверенный manifest для каждой architecture, на которой разрешён workload. Каждый platform manifest должен происходить из того же release commit и пройти применимые release gates. Если image поддерживает только одну architecture, scheduling должен явно исключать остальные узлы.
Обоснование¶
Один tag может разрешаться в разные байты, а scheduler способен выбрать узел без совместимого image.
Проверка¶
- инспекция OCI index и platform manifests;
- pull/start на каждой разрешённой architecture;
- scheduling test несовместимого узла.
Исключения¶
Одноархитектурная платформа не требует OCI index.
INF-ART-008. Проверка источника на границе deployment¶
Уровень: SHOULD
Применяется к: production-платформе, поддерживающей policy проверки image при deployment
Граница deployment должна проверять registry по INF-SEC-014, неизменяемость
release identifier по INF-ART-001–INF-ART-002 и его соответствие
provenance по INF-ART-003. Image из неизвестного registry, mutable tag или
identifier, не связанный с поставляемым release, следует отклонять до запуска
workload. Недоступность проверки не следует интерпретировать как успешное
соответствие.
Обоснование¶
Проверка только в build pipeline не защищает target от прямого применения другого image или подмены deployment-конфигурации.
Проверка¶
- deployment image из неизвестного registry и с mutable tag;
- подмена release identifier после создания provenance;
- отказ источника policy data и проверка результата deployment.
Исключения¶
Платформа без target-side policy MAY выполнять эквивалентную блокирующую проверку непосредственно перед apply и сверять фактический image после rollout.