Сообщить об ошибкеКороткий ответ
Единого верного уровня строгости нет: разумный подход — ввести подпись образов (например, cosign/Sigstore) и генерацию provenance на этапе CI, затем принудительно проверять подпись и происхождение перед деплоем через admission-контроллер, постепенно повышая требуемый уровень SLSA по мере роста зрелости пайплайнов, а не пытаясь сразу достичь максимального уровня для всех сервисов одинаково.
Как это работает подробнее
подпись образа криптографически связывает конкретный digest образа с источником (CI-система, идентичность через OIDC), что позволяет на этапе деплоя проверить, что образ действительно собран доверенным пайплайном и не был подменён в registry. Provenance (например, в формате in-toto/SLSA) дополнительно фиксирует, из какого коммита, какими шагами и на каком раннере был собран артефакт, что важно для расследования компрометации пайплайна.
Сравнение
- Компромисс. строгая верификация (принудительная проверка подписи/provenance везде, высокий уровень SLSA для всех сервисов) даёт сильную защиту от компрометации цепочки поставок, но увеличивает операционную сложность, замедляет онбординг новых сервисов и требует зрелой CI-инфраструктуры; более мягкий подход (подпись/provenance только для критичных сервисов) проще внедрить, но оставляет часть системы уязвимой. Критерий выбора — критичность сервиса, зрелость CI-платформы и готовность команд к дополнительным шагам в пайплайне; решение нужно обсуждать с владельцами сервисов и фиксировать как осознанный риск там, где требования ослаблены.
Что использовать на практике
- Практика. внедрение начинают с генерации подписи и provenance в CI без принудительной проверки (чтобы не сломать существующие деплои), затем вводят admission-политику (Kyverno/Sigstore Policy Controller), которая блокирует запуск неподписанных образов для чувствительных namespace, и только затем расширяют требование на все окружения. Уровень SLSA (1–4) выбирают по критичности сервиса — не все внутренние инструменты нуждаются в максимальном уровне изоляции сборки.
- Проверка. Ожидаемое поведение: cosign verify успешно подтверждает подпись только для образов, собранных именно указанным пайплайном на указанной ветке; попытка задеплоить образ, собранный вручную на ноутбуке разработчика или смёрженный из другого источника, не пройдёт проверку подписи на admission-webhook — это проверяется попыткой применить манифест с таким образом и наблюдением отказа деплоя.
Подводные камни
- Ошибка. требовать максимальный уровень SLSA для всех сервисов без учёта реальной критичности и зрелости команды, что замедляет разработку без соразмерного выигрыша в безопасности; подписывать образ, но не проверять подпись при деплое, оставляя подпись чисто формальной мерой; хранить приватный ключ подписи в CI-переменной как статический секрет вместо keyless-подписи через OIDC-identity.