Подписание Docker-образов с Cosign: Sigstore, Keyless, Kyverno

Почему подписание Docker-образов срывается на этапе выкладки

Классический сбой выглядит так: сборка отработала, образ ушёл в реестр под плавающим тегом, а через час на узле в рабочей среде запущен совсем другой набор слоёв. Причины бывают бытовые — кто-то пересобрал локально и дописал тег поверх, сборочное задание упало на середине и выложило предыдущий результат, зеркало реестра отдало закешированную копию. Тег — изменяемая метка, и она ничего не говорит о том, что именно загрузилось.

Отличить подмену от нормального релиза по внешним признакам почти нельзя: тот же тег, тот же порт, приложение стартует и проходит базовые пробы. Неподписанный образ в проде живёт до первого инцидента — его замечают по факту утечки, постороннего сетевого трафика или потерянных данных, а не на этапе выкладки. Разбор потом занимает дни, потому что связать работающий контейнер с конкретным набором исходников и номером сборочного запуска постфактум нечем.

Проверка происхождения образа нужна ровно затем, чтобы этот вопрос закрывался за секунды. Криптографическая подпись фиксирует, что артефакт собран конкретным сборочным заданием из конкретного состояния исходного кода, а проверяющий механизм в кластере просто не даёт запустить то, чья подпись не сходится. Тогда подмена артефакта между сборкой и выкладкой упирается в отказ на входе, а не в разбор последствий.

Разбираем, как это закрывается: подписание Docker-образов, Keyless через Sigstore и политики Kyverno, которые пропускают в кластер только проверенное.

Что даёт проверяемая цепочка поставки: эффект в измеримых величинах

Подпись образа превращает вопрос «откуда этот артефакт» в машинную проверку. Пока образ не подписан ключом сборочного процесса, развёртывание отклоняется на входе в кластер — до того, как контейнер получит доступ к сети и секретам. Это и есть контроль целостности артефактов: сверяется не имя тега, а конкретный слепок сборки.

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

На разборе инцидента журнал проверок отвечает, какая сборка и какой подписант породили артефакт в конкретном окружении. Локализация занимает минуты вместо перебора версий вручную, а окно простоя ограничивается одним откатом на предыдущую подписанную сборку.

Отдельное следствие — устранённый класс отказов. Подмена тега, образ из локальной сборки, откат на неподписанный артефакт больше не доходят до боевого контура: их отклоняет политика на входе в кластер. Проверяемая цепочка поставки перестаёт быть отчётом для аудита и становится штатным механизмом, который экономит часы на каждом релизе и каждом разборе.

Подписание артефактов: ключевой, бесключевой и гибридный режимы

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

На стороне кластера режим задаёт правило допуска: проверка по публичному ключу либо по удостоверению и издателю сертификата. Типичная ловушка — правило, которое смотрит только на факт подписи: тогда проходит образ, подписанный любым удостоверением, и смысл проверки теряется. Поэтому сравнение режимов подписи делают до внедрения и фиксируют области проверки явно.

Внедрение по шагам: от аудита конвейера до передачи эксплуатации

Порядок работ строим так, чтобы подпись образов не остановила текущие выкатки: сначала фиксируем реальное состояние, затем вводим правила и только потом включаем блокировку.

1. Аудит конвейера сборки. Инвентаризация: где и чем собираются образы, какие реестры задействованы, кто деплоит, какие политики допуска уже есть. Результат — карта зависимостей и точки встраивания подписи.

2. Схема доверия. Решаем, что удостоверяет личность сборщика: бесключевой режим с удостоверением от системы сборки или ключ в хранилище секретов. Фиксируем список доверенных удостоверений.

3. Настройка подписи. Cosign подписывает образ после публикации, запись уходит в журнал прозрачности. Проверяем на одном сервисе, что теги и дайджесты не расходятся.

4. Настройка проверки артефактов. Правило допуска в кластере сверяет подпись и удостоверение до старта контейнера — сначала в режиме предупреждения, чтобы увидеть, что отвалится.

5. Прогон на стенде. Полный цикл: сборка, подпись, проверка, откат на прежний образ, поведение при недоступности журнала. Замеряем задержку выкатки и долю ложных отказов.

6. Приёмка и передача эксплуатации. Переводим проверку в блокирующий режим, отдаём регламент: как подписать вручную, как добавить доверенное удостоверение, что делать при инциденте.

Комплект передачи: политики допуска, схемы и регламенты

Работающая проверка — это половина результата. Вторая половина — комплект, по которому другой инженер сможет эту проверку поддерживать, менять и при необходимости отменять без автора. Ниже — что именно остаётся у вашей команды после передачи.

• Политики допуска. Какие образы запускаются в кластере, обязательна ли подпись, что делать с неподписанными сборками, какие исключения открыты и до какой даты действуют.
• Разграничение ролей. Кто вправе подписывать артефакт, кто — менять политику, кто — только читать журнал. Право подписи и право допуска разведены: сборщик не разрешает себе выкладку единолично.
• Схема потоков сборки и выкладки. Один лист: где ставится подпись, где проходит проверка, что происходит при отказе и куда уходит уведомление. По нему новый инженер входит в контур без переспрашиваний.
• Регламент реагирования на инцидент. Компрометация ключа или учётной записи подписи: как отозвать, как перепроверить уже выложенное, за какое время обязан уложиться дежурный.
• Документация по подписи. Как выпускается краткоживущий сертификат, к какой личности сборки он привязан, как воспроизвести проверку вручную на своей машине вне контура.
• Инструкция для дежурного. Разбор типовых отказов — образ не подписан, подпись просрочена, недоступен сервис идентичности — с командами и границей «делаю сам / эскалирую».
• Журнал проверок. Что и как долго хранится, как выгрузить отчёт для внутреннего аудита и доказать, что в прод не попадал неподписанный артефакт.

Комплект собирается под ваши процессы и передаётся вместе с разбором: показываем, как менять политику, не ломая выкладку. Политика без регламента превращается в настройку, которую боятся трогать, — поэтому документация идёт в поставку, а не остаётся в переписке.

Кейс: убрали подмену артефактов между сборкой и выкладкой

У заказчика сборка и выкладка жили в одном конвейере, но право на релиз оставалось за инженером, а образы адресовались тегами. В один из дней в продакшен ушёл образ из чужой ветки: тег успели перезаписать между сборкой и выкладкой, и проверить связь релиза с исходным коммитом было нечем. Инцидент локализовали больше трёх часов — связь искали по логам.

Подписание docker-образов мы поставили в тот же конвейер: выкладка идёт по digest, а не по тегу, а каждая сборка получает короткоживущий сертификат в keyless-режиме Sigstore — долгоживущий ключ не хранится. На входе в кластер политика Kyverno отклоняет образ, если подпись невалидна или выпущена не тем конвейером.

Метрики до и после

• Отклонённая выкладка: раньше проверок не было ни одной — теперь на входе отсекается примерно каждая двадцатая попытка, и это подмены, а не рабочие релизы.
• Время локализации инцидента: с трёх часов до пятнадцати минут — по подписи видно конвейер, ветку и коммит.
• Ручные операции на релиз: с пяти до нуля; откат идёт по ранее подписанному digest, а не по «предыдущему тегу».

С какими оговорками применим результат

Схема работает там, где сборка централизована и у неё есть собственная учётная запись. Если часть сервисов собирают подрядные команды, начинаем с режима предупреждения: политика пишет событие в журнал, но не блокирует выкладку, — и включаем блокировку после того, как подписаны все ветки. Для приватных реестров отдельно настраиваем доверие к удостоверяющему центру, иначе легитимные образы не пройдут проверку.

Чем проверка при выкладке отличается от проверки в хранилище?

Проверка при выкладке и контроль в хранилище образов — две разные точки контроля, и закрывают они разные классы отказов. Подписание docker-образов фиксирует, кто и что именно выпустил, но саму подпись можно проверить в двух местах: реестр отсекает неподписанное на входе, среда исполнения подтверждает подлинность в момент запуска.

Политика в реестре срабатывает в момент записи: если у образа нет валидной подписи Sigstore или не выполнены требования к базовому слою, он не попадает в хранилище. Разработчик узнаёт об этом сразу, а не после развёртывания, и в реестре не накапливаются артефакты с неясным происхождением. Но точка контроля здесь одна — только запись.

Контроллер допуска в среде ловит то, что приходит мимо обычного канала: образы из другого реестра, локально загруженные архивы, теги, перезаписанные после публикации. Он отклоняет запуск, если подпись формально есть, но выдан не тот, кто должен подписывать: при keyless-подписи проверяется конкретная учётная запись и её эмитент, а не сам факт наличия сертификата.

Без этого уточнения проверка работает, но пропускает всё — любой валидный сертификат открывает доступ к среде. И ограничение у контроллера допуска своё: он проверяет только создание, уже запущенный контейнер он не остановит, поэтому политика в реестре остаётся обязательной. Нужны обе точки контроля — одна чистит вход, вторая гарантирует факт в среде.

Технические сомнения инженеров: ключи, отзыв, доверенные источники

Подпись помогает ровно настолько, насколько предсказуемы ответы на неудобные вопросы: что делать при компрометации ключа, что с образами, выложенными до внедрения, кто и как меняет политику допуска. Ниже — то, что чаще всего обсуждаем на согласовании, потому что без этих ответов проверка в кластере остаётся формальностью.

Работаем с Cosign: подпись лежит рядом с образом в реестре, а проверка выполняется в момент допуска. Тогда ротация, отзыв и доверенные источники решаются инфраструктурно, а не перепиской в чате.

Уже выложенные неподписанные образы — удалять?

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

Как определяется доверенный источник?

Правило допуска привязывает образ к конкретному реестру и удостоверению сборки, выданному доверенным центром. Тогда для новых сборок подпись можно не хранить в виде долгоживущего ключа: подделать её нельзя, а утечь — нечему.

Кто владеет политиками допуска?

Политики — часть репозитория, а не настройка в личном кабинете: любое изменение проходит ревью и попадает в историю. У каждого правила есть владелец из команды, поэтому ужесточение требований не превращается в неожиданную блокировку релиза.

Обсудим задачу: разберём ваш конвейер и вернёмся с планом

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

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

В ответ вы получаете план внедрения: последовательность этапов, объём работ по каждому, точки отката, изменения в правах и критерии, по которым проверите, что подпись действительно работает. Опишите задачу и приложите срез — вернёмся с оценкой и планом.