# Digest совпадает, но кому доверять: проверка подписи контейнерного образа

Диагностика: Digest совпадает, но кому доверять: проверка подписи контейнерного образа. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/artifact-signature-verification/
Language: ru

Совпадение digest подтверждает идентичность содержимого, но само по себе не устанавливает доверие к издателю. Для подписанного образа проверяйте signature и ожидаемую identity или доверенный ключ. Любая существующая подпись не является автоматически подходящим основанием для deployment.

## Определите политику доверия

Запишите, какой издатель или build identity разрешён для конкретного image. Для keyless verification важны expected certificate identity и OIDC issuer. Для проверки ключом нужен доверенный источник самого public key. Получить подпись и ключ из одного непроверенного места недостаточно, чтобы установить нужного издателя. Политика должна существовать до проверки результата, иначе оператор может принять произвольную identity только потому, что инструмент успешно проверил её криптографическую подпись.


[Официальный источник 1](https://docs.sigstore.dev/cosign/verifying/verify/).

## Сопоставьте подпись и объект

Cosign verification проверяет подпись и, при штатной проверке соответствующих claims, связь с digest образа. Не отключайте check-claims ради удобного зелёного результата без понимания последствий. Сохраните точную ссылку image, digest и ожидаемые параметры identity/issuer либо key source. Registry tag остаётся mutable, поэтому проверенный tag и позднее загружаемый tag могут разрешиться по-разному. Завершённая процедура должна переносить в deployment именно идентичность проверенного содержимого.


[Официальный источник 2](https://kubernetes.io/docs/tasks/administer-cluster/verify-signed-artifacts/).

## Разберите учебный release

Представим два образа с валидными подписями разных build identities. Политика разрешает только identity проекта A. Подпись проекта B может быть криптографически корректной, но не соответствовать этой политике. После успешной проверки A сохраняется его digest, затем он используется в manifest. Пример не утверждает наличие подписей у любого стороннего образа. Если издатель не публикует подходящий механизм, отсутствие проверки следует обозначить явно, а не выдумывать доверенную identity.

| Проверка | Какой вопрос закрывает |
| --- | --- |
| Digest | Какие байты выбраны |
| Signature | Соответствует ли подпись проверяемому объекту |
| Identity/issuer | Кто разрешён политикой |
| Manifest | Что реально будет запущено |

## Выберите место enforcement

Проверка в release pipeline и admission policy решают разные организационные задачи. Для admission нужен поддерживаемый controller и явно настроенная политика, а не только установленный cosign на ноутбуке. Документация Kubernetes показывает проверку подписанных artifacts как конкретный пример. Не переносите её identity на произвольный workload image. Для air-gapped или offline verification отдельно проверяйте поддержку bundles и доверенных материалов в используемой версии, не обещая автоматическую работу без сети.

## Сохраните доказательство решения

Артефакт содержит digest, identity policy, версию инструмента, результат и manifest reference без секретных credentials. Повторите негативный тест с неподходящей identity на стенде: он должен быть отвергнут даже при валидной чужой подписи. Затем проверьте, что running image соответствует выбранному digest. Подпись не доказывает отсутствие уязвимостей, пригодность модели или корректность лицензии. Она закрывает конкретную границу происхождения и целостности, которую следует сохранять отдельно от остальных проверок deployment.

Сохраняйте результат отрицательной проверки рядом с положительным. Иначе успешная команда может означать слишком широкую trust policy, которая принимает нескольких издателей вместо предусмотренного единственного источника конкретного release.

Связанные разборы: [software stack reproducibility](/ru/journal/software-stack-reproducibility/); [hardware security](/ru/journal/hardware-security/).