Подпись контейнера Cosign прошла — без проверки личности этого мало

Чтобы подписать контейнерный образ без постоянного ключа, опубликуйте его в реестре, сохраните адрес с дайджестом и выполните подпись Cosign после входа через OIDC. Порядок подписи контейнера в Sigstore предусматривает временный ключ и команду для опубликованного образа. Проверяющей стороне понадобится тот же адрес, иначе она может проверить другое содержимое.

Для допуска образа одной действительной подписи недостаточно: проверка должна получить заранее разрешённые личность подписанта и издателя OIDC. Параметры проверки Cosign позволяют задать оба значения и по умолчанию сопоставляют дайджест образа с дайджестом в подписанной нагрузке. Успех команды имеет смысл для выпуска только при совпадении всех этих условий.

Сохраните адрес образа после публикации

Начните с образа, который уже отправлен в реестр. Возьмите дайджест из результата публикации и составьте адрес в форме «реестр/проект/образ@sha256:дайджест». Здесь дайджест обозначает конкретное содержимое опубликованного образа, а не удобное имя выпуска. В ручном сценарии сохраните полный адрес в переменной окружения IMAGE; в конвейере передавайте его между заданиями как результат этапа сборки.

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

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

Подпишите образ через OIDC

Для ручного запуска после публикации выполните cosign sign "$IMAGE". Команда предложит пройти аутентификацию у поддерживаемого поставщика личности, если подходящий токен не получен автоматически. Cosign создаёт временную пару ключей и связывает сертификат с личностью, подтверждённой через OIDC; постоянный закрытый ключ в настройках конвейера для этого режима не нужен.

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

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

Проверьте личность и издателя сертификата

Для условного входа сотрудника через Google команда проверки выглядит так: cosign verify --certificate-identity="[email protected]" --certificate-oidc-issuer="https://accounts.google.com" "$IMAGE". Адрес почты здесь условный; укажите разрешённый адрес реального подписанта. Первый параметр задаёт личность, которую нужно найти в сертификате, второй — ожидаемого издателя OIDC. Адрес образа должен оставаться тем же, что использовался при подписании.

Значения параметров задавайте до чтения подписи по принятому правилу выпуска. Если извлечь их из обнаруженного сертификата и затем передать обратно команде, проверка подтвердит согласованность подписи с выбранными после факта условиями. Она не установит, что подписант имел право выпускать образ. Право на запись в реестр и право подписывать релиз также следует считать разными условиями политики.

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

Встройте условие допуска в конвейер

В GitHub Actions токен OIDC выдаётся заданию с правом на его получение. Пример конвейера Sigstore получает дайджест из шага публикации, подписывает опубликованный образ и проверяет подпись по адресу рабочего процесса и издателю токена. Такое правило связывает допуск с конкретным файлом процесса и веткой, а не только с названием репозитория.

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

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

Сохраните проверку утверждений нагрузки

Обычная подпись Cosign для контейнера содержит дайджест образа в подписанной нагрузке. При стандартной проверке этот дайджест сравнивается с проверяемым образом. В результате команда связывает сертификат и подпись с конкретным содержимым, а не просто устанавливает существование действительной подписи на каком-либо объекте. Именно поэтому адрес с дайджестом полезен и как вход проверки, и как вход развёртывания.

Параметр --check-claims=false отключает проверку утверждений нагрузки. Он предназначен для иных форматов подписанных данных; при обычной проверке контейнера его добавление убирает стандартную сверку дайджеста. Криптографическая проверка при этом может пройти, но такой успех уже не даёт прежнего основания считать, что подпись относится к проверяемому образу.

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

Читайте также:

• Microsoft меняет контроль ИИ-агентов — одной проверки модели уже мало
• Красивой выкладки мало: правила мерчандайзинга, которые проверяют по цифрам
• Как проверить состояние SSD в Windows и понять показатели SMART