Системный журнал — практичная база знаний по VPS и Linux
docker • 12 минут

Отказ от Docker Content Trust: что меняется и как перейти на современные инструменты подписи

Docker Content Trust (DCT) был одним из первых механизмов, позволяющих проверять подлинность и целостность образов в Docker Hub. Он построен на устаревшем проекте Notary v1, который больше не поддерживается upstream‑сообществом. Из‑за этого Docker решил полностью вывести DCT из эксплуатации, а также закрыть доступ к notary.docker.io. Для большинства пользователей изменение незаметно, так как DCT был опциональной функцией, но тем, кто активно использовал подписи, необходимо перейти на современные решения.

Что такое Docker Content Trust и почему его выводят из эксплуатации

DCT использует модель trust‑on‑first‑use, где подписи хранятся в отдельном сервисе Notary v1. За десять лет экосистема контейнеров перешла к OCI‑нативным инструментам, которые сохраняют подписи непосредственно рядом с образом в реестре, не требуя отдельной инфраструктуры trust. Поддержка Notary v1 прекращена, а количество pulls, использующих DCT, упало ниже 0,05 %. Поэтому Docker сосредотачивает усилия на более современных и стандартизированных способах подписи.

Кто затронут изменением

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

  • Переменная окружения DOCKER_CONTENT_TRUST=1 в профиле оболочки, CI/CD‑pipeline, Dockerfile или манифестах Kubernetes.
  • Вызов команд docker trust sign, docker trust inspect или docker trust revoke в скриптах.
  • Политики приёма в Kubernetes, которые проверяют наличие DCT‑подписей.
  • Публикация образов в Docker Hub с включённым signing через DCT.

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

Как обеспечить работу pulls после отключения

Самый быстрый способ – полностью отключить DCT, после чего обычные операции docker pull и docker push продолжат работать без изменений.

# Удалить переменную из текущей сессии
unset DOCKER_CONTENT_TRUST
# Или явно задать значение 0
export DOCKER_CONTENT_TRUST=0

Не забудьте поискать все места, где переменная может быть задана: файлы ~/.bashrc, ~/.zshrc, скрипты CI (GitLab CI, GitHub Actions, Jenkins), файлы docker-compose.yml и манифесты Kubernetes.

Воспроизводимые сборки с помощью digest’ов

Если вам важна гарантия получения точно того же бинарного контента, используйте digest‑адреса вместо тегов. Digest – это хеш содержимого образа и никогда не меняется, даже если тег переприсваивается другому образу.

# Получить digest уже загруженного образа
docker pull busybox:latest
docker images --digests busybox
# Пример вывода:
# REPOSITORY   TAG       DIGEST                                                                    IMAGE ID
# busybox      latest    sha256:f85340bf...   abc123def456
# Запустить pull по digest
docker pull busybox@sha256:f85340bf...

Digest обеспечивает целостность контента, но не подтверждает личность издателя. Для этого нужны криптографические подписи.

Подпись образа с помощью Cosign (Sigstore)

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

# Установить Cosign (пример для Linux)
curl -LO https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64
chmod +x cosign-linux-amd64
sudo mv cosign-linux-amd64 /usr/local/bin/cosign
# Войти в Docker Hub (или другой реестр)
docker login
# Подписать образ
cosign sign --key cosign.key myrepo/myimage:tag
# Проверить подпись
cosign verify --key cosign.pub myrepo/myimage:tag

Подпись образа с помощью Notation

Notation – клиент проекта Notary, использующий традиционную PKI‑модель. Подписи также хранятся как OCI‑reference артефакты.

# Установить Notation (пример)
curl -LO https://github.com/notaryproject/notation/releases/latest/download/notation-linux-amd64.tar.gz
tar -xzf notation-linux-amd64.tar.gz
sudo mv notation-linux-amd64 /usr/local/bin/notation
# Сгенерировать пару ключей
notation cert generate test-key
# Подписать образ
notation sign --signature myrepo/myimage:tag.sig --key test-key.pem myrepo/myimage:tag
# Проверить подпись
notation verify --signature myrepo/myimage:tag.sig --key test-key.pem myrepo/myimage:tag

Проверка подписей в кластере Kubernetes

Подпись – только половина задачи. Нужно обеспечить, чтобы в кластер допускались только подписанные образы.

  • Kyverno + Cosign: политика Kyverno может автоматически проверять Cosign‑подписи перед тем, как pod будет допущен к запуску.
  • Ratify + Gatekeeper / OPA: Ratify интегрируется с admission‑контроллерами и умеет верифицировать Notation‑подписи.

Оба решения работают без необходимости запуска отдельного trust‑сервера, поскольку подписи уже находятся в реестре.

Docker Hardened Images как готовая замена

Если вы использовали DCT главным образом для проверки базовых образов из Docker Hub, рассмотрите переход на Docker Hardened Images (DHI). Каждый такой образ уже содержит криптографические подписи, provenance‑аттестации и SBOM. Они регулярно пересборжаются при появлении новых CVE и предоставляют более высокий уровень безопасности «из коробки».

План миграции и рекомендации

  1. Отключите DCT во всех местах, где он может быть задан.
  2. Переключитесь на использование digest‑адресов там, где необходима воспроизводимость.
  3. Выберите инструмент подписи: Cosign для OIDC‑ориентированных workflows или Notation для традиционной PKI.
  4. Настройте CI/CD‑pipeline, чтобы автоматически подписывать образы после сборки.
  5. Внедрите политики проверки подписей в кластере Kubernetes (Kyverno или Ratify).
  6. Для базовых образов рассмотрите переход на Docker Hardened Images.
  7. Документируйте изменения и обучите команду новым командам и процессам.

Следуя этим шагам, вы сохраните возможность проверять подлинность и целостность контейнеров, не полагаясь на устаревшую инфраструктуру Notary v1, и получите более современный, стандартизированный подход к безопасности образов.