Как выстроить безопасность цепочки поставок контейнерных образов в Kubernetes-платформе (от сборки до запуска), и какие здесь компромиссы?

Короткий ответ

Единого обязательного стандарта нет, но типовая зрелая цепочка включает: сканирование образов на уязвимости в CI, подпись образов (например, cosign/Sigstore) с проверкой подписи через admission-контроллер (Kyverno/OPA Gatekeeper) перед запуском в кластере, запрет на использование нефиксированных тегов и образов из непроверенных реестров, и регулярное обновление базовых образов — степень строгости каждого из этих шагов зависит от критичности workload и зрелости команд разработки.

Как это работает подробнее

admission-контроллер (валидирующий webhook) перехватывает запросы на создание Pod и может отклонить образ, если его подпись не проходит проверку доверенным ключом, либо если образ происходит не из разрешённого реестра — это переносит контроль "сдвинутым влево" (shift-left) и одновременно обеспечивает enforcement непосредственно в runtime, не полагаясь только на дисциплину CI. Подпись образа (например, через Sigstore/cosign с keyless-подписью на основе OIDC identity CI-системы) даёт криптографическую гарантию, что образ собран именно ожидаемым пайплайном и не был подменён между сборкой и развёртыванием.

• Компромисс. более строгий enforcement (блокировка любого образа с критическими уязвимостями или без подписи) повышает безопасность, но может замедлить скорость поставки и потребовать exception-процесса для легитимных случаев (например, временная уязвимость без доступного патча в стороннем образе); более мягкий подход (только предупреждения и дашборды) безопаснее для скорости разработки, но не даёт реальной гарантии защиты от компрометации цепочки поставок — выбор конкретного баланса должен явно обсуждаться с заинтересованными сторонами, с учётом регуляторных требований и реальной зрелости процессов конкретной организации.

Пример кода

manifest.yamlКопировать

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata: { name: require-image-signature }
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-signature
      match: { resources: { kinds: ["Pod"] } }
      verifyImages:
        - imageReferences: ["registry.example.com/*"]
          attestors:
            - entries:
                - keyless: { issuer: "https://token.actions.githubusercontent.com", subject: "https://github.com/org/repo/*" }

Что использовать на практике

• Практика. внедрение полной цепочки (сканирование + подпись + enforcement + SBOM) требует согласованных изменений в CI всех команд, что может существенно замедлить миграцию существующих пайплайнов и первое время создавать трение (ложные блокировки легитимных деплоев из-за найденных уязвимостей в зависимостях, которые разработчик не может сразу исправить). Поэтому внедрение часто проходит поэтапно: сначала режим аудита (audit/dry-run у admission-политик, без реальной блокировки), сбор статистики нарушений, коммуникация с командами, и только потом включение принудительного блокирующего режима.

Подводные камни

• Риски. частая ошибка — сразу включать блокирующий Enforce-режим admission-политик без предварительного прогона в режиме аудита, что останавливает легитимные деплои; также кандидаты часто путают сканирование образов на уязвимости с криптографической подписью образов, считая одно достаточной заменой другого.