Docker Content Trust for docker manifest Command

[riyazdf]

Dependent on #138

We should consider Docker Content Trust implications for docker manifest -- in particular:

DOCKER_CONTENT_TRUST=1 docker manifest push ... should sign the top-level manifest / manifest list hash into Notary
DOCKER_CONTENT_TRUST=1 docker manifest inspect ... should verify signatures for the specified manifest / manifest list

In order to facilitate this we will need manifest-tool or the underlying library we decide to use (will be decided in #138) to expose the hash and byte size of the manifest list when it pushes one (we must sign in the byte size and hash of the manifest list).

We can directly leverage the existing Notary libraries already vendored into docker/cli that are currently used for trusted pushes.

cc @docker/security-team @clnperez @estesp

[endophage]

It would be even better if it exposes the manifest list itself, then we can update DCT's hashes independently of the manifest operations.

[clnperez]

@endophage the inspect output from the manifest command is currently the manifest list. Is this helpful?

./build/docker-linux-amd64 manifest inspect clnperez/hello-world
{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 524,
         "digest": "sha256:f3b3b28a45160805bb16542c9531888519430e9e6d6ffc09d72261b0d26ff74f",
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 525,
         "digest": "sha256:d682c60dd1aa745d1822fb92566cbdb4636dafc93294f44896f541337ddcf77a",
         "platform": {
            "architecture": "ppc64le",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 525,
         "digest": "sha256:bcaee2c8a5b6640409d86629c969164beddaf769bf4bf78aa55e4824fe73a275",
         "platform": {
            "architecture": "s390x",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 524,
         "digest": "sha256:9701edc932223a66e49dd6c894a11db8c2cf4eccd1414f1ec105a623bf16b426",
         "platform": {
            "architecture": "arm",
            "os": "linux"
         }
      }
   ]
}

[endophage]

Probably not. We'd want to actual bytes that were sent to the registry so that we can reliably generate the same hash.

DCT (Notary/TUF) is designed to allow clean upgrade paths for hashing algorithms and we already support both sha256 and sha512. While the registry may currently and for the foreseeable future only use sha256, there's nothing to prevent additional verification being done at download time using additional checksums stored in notary, hence it would be useful at upload time to have the bytes so that we can generate whatever the current set of hashes are.

Additionally, it reduces the number of opportunities for fake/bad hashes to be provided. If for example (and this is just a hypothetical), the checksum was a value returned by the registry and passed all the way back to DCT, it would be desirable to have verification somewhere that the checksum the registry is claiming agrees with the checksum we think it should be claiming based on the data we uploaded. Otherwise a compromised registry can potentially get users to sign bad images. Requiring DCT is passed the same bytes that were uploaded is just such a point of verification.

[clnperez]

You mean layer bytes? The layers all have to exist on the registry already to create a manifest list, so none are pushed during any of these steps.

[endophage]

No, just the manifest list bytes. We only aim to sign the top of the tree, in this case the manifest list, and rely on the Merkle-tree properties of checksums all the way down from there.

[dnephin]

Just a note that #138 has merged, so this issue is unblocked.

[williamdes]

For anyone finding this old issue, the solution to sign a manifest is to use the notary command line.
See: https://github.com/sudo-bot/action-docker-sign#sign-multi-platform-manifests
Ref: sudo-bot/action-docker-sign@ee2b979