No way to disable trust-on-first-use for 'docker pull' with Content Trust

[mrled]

As far as I can tell, there's no way to tell Docker not to trust the first Content Trust certificate it finds. This is something I'd prefer to do manually, rather than have it done for me, because I want to ensure that my keys aren't tampered with on the notary.

Is this possible? If not - would you consider adding the feature?

(For the record, I'd prefer to distribute my root key certificate myself over the management infrastructure I already use, which is currently SSH and Ansible. For my use, I don't mind if Docker automatically trusts a repository key, so long as it doesn't automatically trust a root key, AND provided that it checks the root key along with the repository key and will fail if either one fails to match.)

(Note: I initially posted this as moby/moby#18474 but they asked me to open it over here instead.)

[endophage]

Just restating from linked issue in docker/docker: definitely on our TODO list.

[cyli]

@mrled - we just merged #624, which provides a way to disable trust on first use with notary. We still have yet to propagate this to docker, but just wanted to update you on the progress of this issue.

[lewiada-zz]

Any update on this? This is a very big deal and am looking forward to it being a part of Docker.

[endophage]

@lewiada we haven't done any work on this so far. Unfortunately we've all been working on other priorities.

@cyli @HuKeping @riyazdf as an idea on supporting this (and other notary config) sooner rather than later, would it make sense for the docker integration to simply look for a notary config file in ~/.docker/trust (i.e. ~/.docker/trust/config.json)? I imagine we'd also want to refactor some of our CLI config loading such that the docker integration could also make use of it.

[cyli]

That sounds simple enough, especially since repo names can be wildcarded

[riyazdf]

@endophage that proposal sounds good to me 👍

No need for anything more complicated on the docker-side, and makes notary configs portable to DCT

[endophage]

Cool. I think the one thing we'd need to add is the ability to configure per GUN prefix. i.e. docker.io/* has one configuration, my_stuff.com/* potentially has something else.

If we add a config version at the top level of the JSON struct we can add that later though. Current version would be 0 so that existing configs without a version are correctly parsed with the zero value populated by default. We can bump to 1 when we release the v1.0.0 version of Notary.

[lewiada-zz]

as a thought, there is another huge (usability) benefit that comes with enabling trust-pinning in Docker. Using the strict definition of the TUF root-key requires the root-key to be taken out of the safe each time a new repo is created. In a DevOps environments, we will be creating new repos all the time. A developer or automation tool needs a way to seamlessly obtain a delegated tagging key. Having to put in ticket requests to the holder of the root key is cumbersome, and the developers that I have talked to have completely rejected this idea on the grounds of usability.

On the other hand, if trust-pinning is enabled, one could create a hierarchy with a root-ca (offline) and an issuing-ca (online) so that once a developer is authenticated, the new tagging key could created automatically and the developer or automation tools could request a delegated tagging key.

So not so much a security gain, but a huge workflow / automation gain. I haven't heard others talking about it from that point of view yet, but I think it's an equally big deal.

[endophage]

@lewiada we've been discussing automated flows a lot internally so with that use case, you're the perfect person to tell us what you think about this idea we've been discussing on and off:

Rather than using a CA, which brings additional overhead in managing it correctly, what if you could pin a single root key for multiple repos with some simple wildcarding rule.

Anybody creating a new repo would then include 2 root keys in the new repo with a threshold of 1. Those 2 keys would be:

1. the public shared root key, no need for access to the private part.
2. a randomly generated keypair. Used to sign the initial root then immediately thrown away.

It would still require the shared root key to be brought online in the case that one of the base keys needed to be rotated, but it removes the need for a CA.

N.B. the CA mechanism you describe is one we've always intended to support, this is just an additional, we believe higher security, mode of operation, due to the ability to keep the root key offline, not having to manage and secure a CA in the first place, and avoid sprawl of many root key owners.

---

Update

While we've been discussing this, I realize after writing it down it doesn't solve your specific use case of pinning as the shared root wouldn't have signed the initial root file.

[dbilling]

as an idea on supporting this (and other notary config) sooner rather than later, would it make sense for the docker integration to simply look for a notary config file in ~/.docker/trust (i.e. ~/.docker/trust/config.json)? I imagine we'd also want to refactor some of our CLI config loading such that the docker integration could also make use of it.

Did this idea ever get implemented? Seems like a slam dunk --reading a notary config.json config file into docker would be a fabulous way to get trust pinning enabled quickly without any work for the docker cli.

[justincormack]

There is an open PR at docker/cli#1236 which exposes the full Notary config to the docker trust.

I am not sure it makes sense to have this issue open on this repo now, as Notary is very much a standalone project and this issue is about a Docker feature. I know this was initially moved to here, but the projects have changed since then, can reopen the original issue or make a new one, but hopefully the open PR is helpful. If there are new Notary features needed around root key handling of course they should be opened here.

[dbilling]

Yay! Thank you for the pointer, @justincormack

[endophage]

@justincormack I agree on not tracking docker issues in here any more. As there's already a docker cli issue and PR open, I'll close this.

For those looking:

• Docker CLI issue: Enable trust pinning with docker content trust  docker/cli#84
• Docker CLI PR: Enable notary trust pinning with docker content trust docker/cli#1236