5

在 docker trust 通过 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}"

但是推送命令以：

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"

所以我对正在发生的事情感到茫然，可能不明白它想要做什么。有没有人有任何见解？

4

2 回答 2

2

我还在学习 docker，但你确定它正在查找的是root.json而不是root.json。

根据此处的配置，它应该在roots.json中查找受信任的证书。

也许您推送到错误的文件以识别您的根源，或者您的帖子中可能有错字。

无论如何，这很有帮助： https ://github.com/cirocosta/docker-cli/blob/master/vendor/github.com/theupdateframework/notary/trustpinning/certs.go

在那里可以看到这些错误是如何生成的，并附有关于这些错误发生原因的注释。

例如，关于您的密钥轮换错误：

// 当我们未能执行完整的根密钥轮换时，将返回 ErrRootRotationFail // 由于未能添加新的根证书或删除旧的根证书

于 2019-03-23T17:31:44.520 回答
0

it's only a locally corrupted state right? You should be able to fix it with a notary remove server.example.com/test1.

The fix I want to get in for this is lazy initialization where one no longer has to explicitly call notary init. As part of lazy initialization, we would always query the server for existing data before assuming it needs to be created locally.

A shorter term fix may be to check the server, or if network connectivity isn't available, the local cache, for existing data. At the moment I believe init assumes the repo doesn't exist and overwrites any existing cache.

Also please make sure to configure DNS and made host entry in host file.

For the purposes of UCP Signing Policy, configured via the “Content Trust” section of the Admin Settings, it’s necessary that we can identify the image was signed by a member of the UCP organization. We do that by making use of client bundles that you can download for your user account from UCP. Client Bundles contain a “cert.pem” file which is an x509 certificate signed by the UCP Certificate Authority, and a “key.pem” file which is the private key matched with the certificate.

You need to create the “targets/releases” delegation and one other delegation, e.g. “targets/my_user” and add the “cert.pem” as the public signing key to both. When another service then inspects the trust data, they can determine that the certificate belongs to a member of the UCP organization and their signatures should be trusted. You then need to import the key.pem so it is available for signing when you push.

The documentation 23 provides more information and specific commands to run, specifically the “Initialize a Repo” section.

于 2019-03-23T18:19:36.613 回答