Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Replicate Signing capabilities of images with standard Harbor replication #8303

Closed
michmike opened this issue Jul 17, 2019 · 10 comments
Closed
Assignees
Labels

Comments

@michmike
Copy link
Contributor

michmike commented Jul 17, 2019

we need to make sure that when images are signed, there is a way for replication to honor the signed component of the images.

@reasonerjt
Copy link
Contributor

We leverage docker content trust and notary for signing the image, last time I checked the signature is tied to GUN which is the uri of the image, so when you replicate the uri of the image changed, it should be considered a different resource in notary, and has to be signed again.

This is the biggest gap I can think about right now, we may need to think about other signing solution if we want to support this.

@reasonerjt reasonerjt added area/notary kind/requirement New feature or idea on top of harbor labels Jul 17, 2019
@reasonerjt reasonerjt self-assigned this Jul 17, 2019
@phenixblue
Copy link

phenixblue commented Jul 23, 2019

Ditto to the above. We would like to see this feature to allow for a simpler HA setup of Harbor using bi-directional replication between 2 or more Harbor instances and still allow for proper signing and policy enforcement post replication

@michmike
Copy link
Contributor Author

Hi Daniel, what if we enabled customers to.provide their own vanity URL for a project that's also behind a Load Balancer. two projects that are geodistributed and replicated can have the same URL and the LB can dictate where requests go. Would that be able to ensure signing is replicated?

@michmike
Copy link
Contributor Author

Cc: @alexvmw

@xaleeks xaleeks self-assigned this Jul 29, 2019
@xaleeks
Copy link
Contributor

xaleeks commented Jul 29, 2019

This seems difficult if we go through notary since the hostname is part of the GUN Daniel referenced. as confirmed here: notaryproject/notary#1023

@xaleeks
Copy link
Contributor

xaleeks commented Dec 7, 2019

docker knows of this limitation and has decided to solve this in notary 2.0 for all oci-compliant artifacts, we will be following progress that docker is making on https://cloud-native.slack.com/archives/CQUH8U287

@axi92
Copy link

axi92 commented Jun 17, 2021

Sry to dig this up, but is there any further information how to deal with that problem?

@brackend
Copy link

Hi, can/does Harbor verify the source signature of the incoming image. Although the signature does not transit along with the image because of gun, it should still verify the source signature on reception.

@wy65701436
Copy link
Contributor

wy65701436 commented Apr 11, 2022

Since Harbor v2.5 is GAed, the it provides the cosign as the image sign solution and supports signature replication. As for cosign usage, you can refer to the goharbor.io, and especial for this PR.

And BTW, harbor is planning to deprecate notary v1 support, so we will not introduce any fix & enhancement for notary.

@brackend
Copy link

Thank you Yan!
Linked #16679 to this

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants