Подписывать контейнеры стало не модой, а необходимостью. В этой статье разберём, как работает инструмент cosign, какие у него подходы к подписи и верификации образов, и как встроить этот процесс в реальный CI/CD.
Почему подпись контейнеров важна
Контейнерный образ — это артефакт, который может пройти через множество окружений и людей перед развертыванием. Подпись даёт гарантию, что содержимое не изменилось с момента подписания и что автор образа — именно тот, кто заявил права.
Без подписи команды вынуждены полагаться на доверие к регистри и проверкам хэшей, что оставляет бреши в цепочке поставок. Добавление подписи повышает уровень безопасности и облегчает автоматическую политику приёмки образов в production.
Что такое cosign и какие у него ключевые идеи
Cosign — это утилита из проекта sigstore, созданная для подписывания OCI-образов и хранения подписей в регистри как OCI-артефактов. Основные элементы: подпись, публичный ключ и прозрачный лог, куда записывается информация о подписании.
Инструмент поддерживает как работу с локальными ключами, так и «keyless» подпись через поставщиков идентификации, что упрощает работу в CI. Также cosign умеет подписывать не только образы, но и произвольные аттестации и SBOM.
Как это работает технически
При подписании создаётся криптографическая подпись над артефактом; затем подпись заносится в OCI-реестр как отдельный артефакт, связанный с основным образом. Это позволяет хранить подписи рядом с образами и извлекать их при проверке без дополнительных сервисов.
Для keyless-подписей sigstore использует Fulcio — CA, который выдаёт короткоживущие сертификаты на основе OIDC-токена, и Rekor — прозрачный лог. Это даёт видимый след о том, кто и когда подписал образ, что полезно для аудита.
Практика: базовые команды и пример использования
Установить cosign можно из бинарников или через пакетный менеджер. После установки типичный сценарий — сгенерировать ключи или использовать keyless, затем подписать образ и проверить подпись.
Примеры команд в простом виде: cosign generate-key-pair, cosign sign —key cosign.key , cosign verify —key cosign.pub , cosign sign —keyless , cosign verify —keyless . Эти команды покрывают основные рабочие потоки.
Небольшая таблица соответствий команд и задач
| Действие | Команда |
|---|---|
| Генерация пары ключей | cosign generate-key-pair |
| Подпись с ключом | cosign sign —key image:tag |
| Проверка подписи | cosign verify —key image:tag |
| Keyless подпись | cosign sign —keyless image:tag |
Подходы к подписи: ключи против keyless
Классический вариант — управление приватными ключами. Вы храните приватный ключ в защищённом хранилище и используете его для подписи. Это даёт контроль, но требует надёжного KMS и процедур ротации.
Keyless-подпись избавляет от необходимости держать приватные ключи локально: Fulcio выдаёт сертификат, привязанный к идентичности разработчика, на основе OIDC. Подпись при этом записывается в Rekor, что обеспечивает доказуемость.
Сравнение основных характеристик
- Контроль: локальные ключи дают полный контроль над подписью, keyless опирается на провайдера идентификации.
- Операции: keyless проще в CI, не требует сложной интеграции с KMS.
- Аудит: Rekor делает keyless-подписи прозрачными и доступными для проверки.
Аттестации и расширенные возможности
Cosign поддерживает создание аттестаций — произвольных утверждений о сборке, тестировании или составе образа. Такие аттестации записываются как отдельные артефакты и могут содержать SBOM, результаты сканирования или выводы тестов.
Проверка аттестаций делается отдельной командой и позволяет привязать принятие образа к конкретным критериям качества. Это удобно в организациях, где важно подтверждать не только авторство, но и соблюдение процедур.
Интеграция в CI/CD
Практический сценарий: вы подписываете образ в конце пайплайна сборки, а на этапе деплоя выполняете автоматическую проверку подписи и аттестаций. Такая цепочка предотвращает запуск неподписанных или изменённых образов в production.
Для CI cosign часто используют в связке с OIDC-провайдерами и секретными менеджерами. Это снижает количество секретов в пайплайне и упрощает ротацию ключей.
Хранение ключей и KMS
Если выбран режим работы с ключами, хранение в KMS — обязательная практика. Cosign поддерживает интеграцию с AWS KMS, GCP KMS, Azure Key Vault и HashiCorp Vault. Это уменьшает риск утечки приватных ключей и упрощает управление доступом.
Ротация ключей должна быть проработана заранее: подписи старых образов остаются валидными при наличии соответствующих публичных ключей и записей в логах. План ротации включает выдачу новых ключей, публикацию новых публичных ключей и обновление политик проверки.
Политики проверки и автоматизация
Организации обычно формулируют политики, которые описывают, что считать допустимым для деплоя. Это может включать требование подписи определённым ключом, наличие конкретных аттестаций или отсутствие открытых уязвимостей.
Эти правила можно автоматизировать с помощью admission-контроллеров в Kubernetes, которые вызывают cosign verify при попытке создать Pod с определённым образом. Автоматизация облегчает соблюдение правил и уменьшает человеческий фактор.
Типичные ошибки при внедрении
Первая ошибка — отсутствие чёткого управления ключами и процедур ротации. Хранилище ключей без мониторинга или резервного плана приводит к простоям или компрометации.
Вторая ошибка — попытка подписывать всё, но не проверять подписи на этапе деплоя. Подписи бесполезны, если их не использовать для принятия решений. Третья ошибка — полагаться только на локальные проверки без прозрачных логов.
Кейс из практики
В одном проекте мне пришлось настраивать подпись образов для микросервисной платформы. Команда выбрала keyless-подпись, чтобы упростить CI и избежать распределения приватных ключей среди нескольких команд.
Пару недель ушло на интеграцию OIDC, настройку Rekor и внедрение проверки в пайплайн деплоя. Результат — уменьшение числа инцидентов с развёртыванием неподписанных образов и упрощение аудита.
Советы по началу работы
- Начните с простого сценария: подпись одного образа и его верификация вручную.
- Параллельно решите вопрос с хранением публичных ключей и доступом к ним для автоматических проверок.
- Подумайте о том, какие аттестации нужны вашей организации и как их формализовать.
Совместимость и экосистема
Cosign хорошо вписывается в экосистему OCI и работает с популярными регистрами. Многие инструменты для сканирования и управления безопасностью поддерживают или интегрируются с cosign.
Также доступно множество плагинов и библиотек для разных языков, что позволяет встроить подпись и проверку в кастомные процессы без переписывания логики приложения.
К чему готовиться при переходе на подписывание
Технически это не самая сложная задача, но организационно потребуется согласовать процессы. Необходимо определить владельцев ключей, ответственных за процедуры ротации и правила приёмки артефактов.
Также нужен план на случай компрометации ключей: как отозвать подписи, как идентифицировать затронутые образы и как распространить новые публичные ключи по средам.
Заключительные мысли и дальнейшие шаги
Подпись образов с помощью cosign превращает контейнеры в проверяемые артефакты, уменьшая риски при доставке ПО. Выбор между ключами и keyless зависит от требований к контролю и удобству интеграции в CI/CD.
Практическая рекомендация: начните с простого сценария, отработайте ключевые операции вручную, затем постепенно автоматизируйте проверку в пайплайнах и в окружениях развертывания. Так вы получите надёжную и прозрачную цепочку поставки.
