Any plans to add content trust or is it not the concern of Portus?

[codemedic]

There seem to be some conflict of use-cases between Portus and notary 0.2, i.e delegations.

Is this something that you have plan to add, or is it that it is completely transparent to Portus.

[holgerreif]

Well, both notary and Portus support authentication schemes but with different targets.

Notary supports signing of images. The decision whether a push is allowed or not depends on the key used to sign the image. With the mentioned delegation it is possible to allow additional keys to be used for signing. Notary itself does neither provides authorisation for pulls or a web frontend for management. It is designed to work with Docker Trusted Registry (AFAIK), while Portus is targeted at the open source registry.

Thus neither use cases confilct nor I see any use case where Portus and notary work together. I don't see a use case where they fit together.

[mssola]

@holgerreif thanks for the explanation, good summary 👍
@codemedic I'm closing this issue, but feel free to continue the conversation if you have any more doubts. Next time though, maybe our Google group is better suited for these kinds of questions 😉

[ArcticSnowman]

FYI Harbor has support https://github.com/goharbor/harbor/blob/master/docs/user_guide.md#content-trust

[Jean-Baptiste-Lasselle]

Well, both notary and Portus support authentication schemes but with different targets.

Notary supports signing of images. The decision whether a push is allowed or not depends on the key used to sign the image. With the mentioned delegation it is possible to allow additional keys to be used for signing. Notary itself does neither provides authorisation for pulls or a web frontend for management. It is designed to work with Docker Trusted Registry (AFAIK), while Portus is targeted at the open source registry.

Thus neither use cases confilct nor I see any use case where Portus and notary work together. I don't see a use case where they fit together.

Ok, so let me sum this up :

• The decision whether a push is allowed or not depends on the key used to sign the image. : who refuses the docker push ? Not the portus docker v2 auth service, I believe, and given what I have read about the subject on all issues.
• So it's the docker client,
• And how does the client verifies the signature ? using the public key you added to your user with docker trust add signer --key ...
• And how were you allowed to execute docker trust add signer --key ... ? Because you successfully authenticated to the notary service
• And how did you login into the notary service ? With the auth token inside ~/.docker/config.json
• And how did you get the token inside ~/.docker/config.json ? Because you successfully authenticated, not to the portus docker auth v2 service, but to the portus general authentication.

In other words, If I sum up what you are saying, we are allowed to push images if and only if we are authenticated as Portus user.

Hey you know what, it was already the case with portus, without any Content Trust management service.

So, how much of Content Trust Management is there in your described scenario ?

To make it clear :

• on the docker push side: there would be content trust management, if it was portus talking to notary to check that the signature of the image actually is associated with the public key / certificate of a legitimately added signer . But it's not, is it ? (Actually asking, still learning after 2 months of portus dissections)
• on the docker pull side : well there portus is not involved any more there, it 's the target infrastructure (where you docker pull to deploy, say a k8s cluster), the trust service (notary), and the TUF databae which should decide who to trust, and even more, see trust treshold concept. (TUF databse : metadata db, you find in that database, all infos about your image, that are not already in your image, so stored linked to the signer ID thanks to signature). Funny, What if a clair scanner could have a signer ? And store found vulnerabiities in TUF database ?
• Of course, we want different trust tresholds, for different infrastructures, don't we? So it can't be just one source of truth, and it actually isn't about truth but about trust. And trust is by nature, much more relative, than truth, even if there is no such thing as absolute truth. Isn't it ? :)

So, preventing the docker push based on signature does not make any sense ... unless you have Identity Federation between portus and the rest of the Continuous Delivery pipelines, to lock it down with a Content Trust Management Policy. Because at this level, all that it would ensure, it WHO, has signed the image, and knowing who he is, you will you know how much you trust him.

What do you think ? (I am really asking, I am working on understanding every detail of the whole TUF)

[Jean-Baptiste-Lasselle]

Update to my previous message

Alright, Now I believe I have now the definitive arguments to show that preventing image push is non-sense regarding content trust :

• I will quote the docker DTR documentation itself,
• And that is not "just a little sentence" in parenthesis or a comment in a bash script

Here you go :

Enabling DCT is a bit like applying a “filter” to your registry. Consumers “see” only signed image tags and the less desirable, unsigned image tags are “invisible”

Source (picked on the 26th of February, 2020) : https://docs.docker.com/engine/security/trust/content_trust/#image-tags-and-dct

It's just that they don't see the non signed image. They don't see it but it's there, the unsigned images were not prevented from bieng push in the registry, based on anything coming from TUF, like notary.

Now, do we have a consensus on that?

@ArcticSnowman @dsmalko @ereslibre @dmacvicar @rds13 @codemedic Your opinion ?

[ArcticSnowman]

So my take away would be that the feature request for Portus would be for it to have an integration with Notary (or other trust agents) such that only trusted images can be pulled. Correct?

[Jean-Baptiste-Lasselle]

So my take away would be that the feature request for Portus would be for it to have an integration with Notary (or other trust agents) such that only trusted images can be pulled. Correct?

Absolutely correct, and there I found a massive proof of the validity of my somewhat energiful reaction :

https://github.com/IBM/portieris

Content Trust Management in Kubernetes is for example here implemented using a Kubernetes Admissions Controller. The term is so clear, I have no doubt you understand what it does, based on signatures.

What I will work with on the project I am working on currently, is that managers validating UAT for example, add their notary signatures, one after the other, and the images shift from namespace to namespace, dev, then integration, then uat, then staging, then qa, then sme, then business-analysts, etc... until last signature allows deployemtn to finak production cluster. So the challenge is to manage multiple Portieris, like airlocks in a submarine. So I baptized it airlock.

Truth is I just got the idea of the name, out of describing it to you. So I bought the domain name, and created github org : https://github.com/air-lock

:)

p.s.: I want to say I think there is not a lot to do to get this integration, including modifying a little the portus source code so that it does not crash on notary webhooks, (really not a lot)