Notary Server with Auth sending Hostname

[rikatz]

So, this is more a doubt than a proper issue:

I'm configuring Notary to use an authentication token based service (based on VMWare Harbor Authentication Service).

I'm having an strange behaviour, as when the Docker Distribution Service tries to authenticate against it, it sends the following request (this is the pure Docker Distribution Service, pointing it's authentication to the service):

GET /service/token?account=admin&scope=repository%3Alibrary%2Falpine%3Apush%2Cpull&service=token-service

As you can see, in the scope field it doesn't send my 'hostname/server' name.

The following is my Docker Distribution configured to do the same. This happens when I try to push an image with DOCKER_CONTENT_TRUST=1:

GET /service/token?account=admin&scope=repository%3A192.168.1.34%2Flibrary%2Falpine%3Apush%2Cpull&service=token-service

Now, the scope contains the hostname part, and not only the repo/image part.

Although this is described on the authentication scope documentation (https://docs.docker.com/registry/spec/auth/scope/), I can't understand why the Docker Distribution authentication does not send the hostname part of the image tag, and Notary does.

Is there a reason why this happens, or this is only some kind of inconsistence?

Thanks!!

[HuKeping]

I've run into the same issue when I deployed notary service before.

IMO, it might because when Distribution challenge the request from CLI(etc, docker CLI), the final target is Distribution service itself. The auth server only need to know whether this credential is valid for the resource in this Distribution.

When Notary server challenge the request from CLI(etc, notary CLI), the final target is not Notary service itself but the GUN(global unique name). The auth server need to know whether this credential can access the resource related to this GUN.

[riyazdf]

Adding on to @HuKeping's explanation: a notary server can hold trust data for multiple registries, so it's possible that you have signed metadata for both docker.io/image and private-registry.com/image on the same notary server.

[rikatz]

OK, so on my Token Authentication Service, should I ignore the 'hostname' part and consider that when Notary asks for that, it's for that registry?

[endophage]

@rikatz ideally you should include the hostname. In the notary world this is considered part of the "Globally Unique Name" (a.k.a GUN). A notary server will happily host multiple unique GUNs as long as you can get tokens it accepts for them. When the docker client needs to push trust data to notary, it actually takes the name distribution recognizes, i.e. library/alpine and prepends docker.io, resulting in Notary receiving a token for docker.io/library/alpine.

Note the notary server doesn't actually care what the "hostname" is, it is simply one way to make the names globally unique. The idea in part was eventually, the notary server could have a config option that would require the public part of a root key, included in root.json, is a public cert issued by a recognized CA, with the CN being the GUN of the trust repository. This would mean Notary wouldn't even require token auth to push data, it would simply confirm cryptographic signatures.

[HuKeping]

If we jumped out of the container world, in a hight-level , notary can be used to hold the trust data for multi resource set, their relationship can be marked as 1....n. The auth server, for example AWS IAM can also be used to hold the credential data for multi resource set, their relationship can also be marked as 1....n.

For a running notary service, the relationship with IAM should be 1...1. So when notary sever get a request ask for a certain resource set, it should pass the full name to IAM, if not IAM might lack of enough information to make the decision.

[rikatz]

Closing this, solved on the Harbor code 😄

Thanks guys, for the great job!