Доверие Docker: не удалось повернуть доверие к новому доверенному корню: не удалось проверить данные с текущими доверенными сертификатами - PullRequest
Новая
       38

Доверие Docker: не удалось повернуть доверие к новому доверенному корню: не удалось проверить данные с текущими доверенными сертификатами

4 голосов
/ 18 марта 2019

Я неожиданно получил это сообщение после того, как месяц доверия докеров работал нормально для меня через GitLab CI.

У меня есть Gitlab Runner, который монтирует ~ / .docker / trust (чтобы он сохранился) и отправляет его в наш реестр QA. 

tag_image_test:
  stage: tag_image
  script:
    - docker login -u "gitlab-ci-token" -p "$CI_BUILD_TOKEN" $CI_REGISTRY
    - docker pull "${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_SLUG}"
    - export DOCKER_CONTENT_TRUST=1
    - export DOCKER_CONTENT_TRUST_SERVER=$QA_REGISTRY_SIGNER
    - export DOCKER_CONTENT_TRUST_ROOT_PASSPHRASE=$QA_REGISTRY_SIGNER_ROOT_PASSPHRASE
    - export DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE=$QA_REGISTRY_SIGNER_REPO_PASSPHRASE
    - docker login -u "$QA_REGISTRY_USERNAME" -p "$QA_REGISTRY_PASSWORD" $QA_REGISTRY_URL
    - export PROJ_PATH=$(echo -en $CI_PROJECT_PATH | tr '[:upper:]' '[:lower:]')
    - docker tag "${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_SLUG}" "${QA_REGISTRY_IMAGE}/${PROJ_PATH}:${CI_COMMIT_REF_SLUG}"
    - docker push "${QA_REGISTRY_IMAGE}/${PROJ_PATH}:${CI_COMMIT_REF_SLUG}"

Однако команды push заканчиваются на: 

time="2019-03-18T11:51:14Z" level=debug msg="failed to verify TUF data for: qa.registry.local/mygroup/myimage, valid signatures did not meet threshold for "
time="2019-03-18T11:51:14Z" level=debug msg="downloaded 1.root is invalid: could not rotate trust to a new trusted root: failed to validate data with current trusted certificates"
time="2019-03-18T11:51:14Z" level=debug msg="Client Update (Root): could not rotate trust to a new trusted root: failed to validate data with current trusted certificates"
could not rotate trust to a new trusted root: failed to validate data with current trusted certificates

Когда я смотрю на файл root.json, срок действия истекает не долго: 

"expires":"2029-02-08T15:07:05.172338131Z"

То же самое для targets.json: 

"expires":"2022-02-10T15:07:05.173954376Z"

Так что я растерялся из-за того, что происходит, и, вероятно, не понимаю, что он пытается сделать. У кого-нибудь есть понимание?

Ответы [ 2 ]

1 голос
/ 23 марта 2019

Я все еще изучаю докер, но вы уверены, что он ищет root.json , а не roots.json .

На основеКонфигурация здесь, она должна искать в roots.json доверенные сертификаты.

Возможно, вы нажимаете неверный файл, чтобы определить свои корни, или вы можете просто опечатать вВаш пост.

В любом случае это полезно: https://github.com/cirocosta/docker-cli/blob/master/vendor/github.com/theupdateframework/notary/trustpinning/certs.go

Как генерируются эти ошибки, можно увидеть в комментариях о причинах возникновения таких ошибок.

Например,, относительно вашей ошибки ротации ключей:

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

0 голосов
/ 23 марта 2019

это только локально поврежденное состояние, верно? Вы должны быть в состоянии исправить это с нотариусом удалить server.example.com/test1.

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

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

Также, пожалуйста, обязательно настройте DNS и сделайте запись хоста в файле хоста.

В целях Политики подписи UCP, настроенной через раздел «Доверие к контенту» в Настройках администратора, необходимо, чтобы мы могли идентифицировать изображение, подписанное членом организации UCP. Мы делаем это, используя клиентские пакеты, которые вы можете загрузить для своей учетной записи пользователя из UCP. Пакеты клиента содержат файл «cert.pem», представляющий собой сертификат x509, подписанный центром сертификации UCP, и файл «key.pem», представляющий собой закрытый ключ, соответствующий сертификату.

Вам необходимо создать делегирование «цели / релизы» и еще одно делегирование, например, «Target / my_user» и добавить «cert.pem» в качестве открытого ключа подписи для обоих. Когда другая служба затем проверяет данные доверия, они могут определить, что сертификат принадлежит члену организации UCP, и их подписи должны быть доверенными. Затем вам нужно импортировать key.pem, чтобы он был доступен для подписи при нажатии.

Документация 23 содержит дополнительную информацию и конкретные команды для запуска, в частности, раздел «Инициализация репо».

...