Added REST storage for images/signatures resource

[miminar]

The new images/signatures resource allows to update image' signatures. There's a new images API client call images.UpdateSignatures() for this purpose.

A cluster-wide role system:image-signer is necessary to add/remove/modify signatures.

A follow-up for #8371

[miminar]

/cc @mtrmac @deads2k

[test]

[soltysh]

Will review once the first part is in.

[mtrmac]

Thanks, I have successfully used this from an independently written client in containers/skopeo#93 ; but I ran into a fairly serious difficulty about the permissions design.

The way things work now, the first user uploading a specific image can include any signatures they want in the original imagestreammapping object; any other user uploading the image, even in a different namespace and completely unaware of the first user, has signatures in their imagestreammapping ignored, and when they are not a member of the system:image-signer role, they can not add their signatures at all.

This is bad for multitenancy or for the stand-alone Atomic Registry; everyone should be able to upload any images they please in their own namespace, and add any signatures they please to images in their own namespace.

It is fine if removing signatures is restricted; adding a signature should never break anything or cause the image to be removed, so removing signatures is not needed except for an “approval/revoking approval” workflow.

Could the permission design be modified so that adding signatures (through the new /images/…/signatures endpoint at least, possibly also through an imagestreammapping) did not require any additional permissions?

(Even with that, the signatures would not be namespaced, and the existence a tenant’s signature would be visible to other tenants. That is a slight privacy leak, but perhaps not a showstopper.)

[liggitt]

the first user uploading a specific image can include any signatures they want in the original imagestreammapping object

@miminar, is that intentional?

Could the permission design be modified so that adding signatures (through the new /images/…/signatures endpoint at least, possibly also through an imagestreammapping)...

We wouldn't let normal users interact with unnamespaced objects in that way. If we wanted regular users to add signatures, there would need to be a namespaced API to allow that.

...did not require any additional permissions?

I would expect it to be a subresource, which would allow granular control over whether signing was enabled. Access to that subresource could possibly be added to existing roles if that makes sense.

[deads2k]

I think we can resolve many use-cases by having signatures live as a subresource on images. The status-y parts would be stripped when POSTing to the subresource. The status-y parts could be set via a direct image update/patch or via a status endpoint (if we split the signature, but right now nothing in an image is split along spec/status lines). This would mean that image signatures start out as only available to people more trusted that project-admins and editors.

I agree that we'll end up wanting to allow any editor to add a signature to an image, but the "scope" of that signature is less clear. Because there are size limits for an etcd record, allowing any editor to add any number of signatures won't scale out for large environments. There are definitely cases where you want to share the signature (QA signs an image and the production namespace should get that sig when they retag) and there are definitely cases where you don't want to share it ("bob signed his istag of the openshift/rhel 7.2, but I don't know who bob is and don't care"). If we stored these signatures in a different etcd hierarchy, we could automatically inject signatures from your namespace. If you want to see other signatures, maybe you need a different API call with a special filter.

Either way, I think I see the images/signatures endpoint as a good starting point for "special" components to use for signing.

[miminar]

the first user uploading a specific image can include any signatures they want in the original imagestreammapping object

@miminar, is that intentional?

It is. An uploader of a new image should be allowed to upload any signatures he wants. New image is tagged just in one namespace so the uploader may be considered as the sole owner of the image at that time.

Modification of signatures of existing image is another story because the image may be tagged in multiple namespaces with different owners. That's why changing the existing signatures is restricted.

Could the permission design be modified so that adding signatures (through the new /images/…/signatures endpoint at least, possibly also through an imagestreammapping) did not require any additional permissions?

This could be done. I'm however reluctant to allow removal of existing signatures while creating images using imagestreammapping. In this case we could just append all the new signatures to the old ones.

However, I don't consider imagestreammapping to be the right resource for updating image signatures. It's designed for registry to create a new image entry and tag it into existing image stream at the same time.

For this purpose, I'd rather add a new subresource imagestreamimages/signatures or perhaps just add an AddSignatures() call toimagestreamimages. It would permit just additions. It would be scoped to user's namespace, so he would be able to add signatures to any image tagged into his namespace.

Any signature removal of existing image should be done through the unnamespaced images/signatures resource requiring cluster-wide image-signer role.

Either way, I think I see the images/signatures endpoint as a good starting point for "special" components to use for signing.

👍

[liggitt]

An uploader of a new image should be allowed to upload any signatures he wants. New image is tagged just in one namespace so the uploader may be considered as the sole owner of the image at that time.

I'm not sure whether I'd expect the first person to push an image to be able to surface their signatures into any other namespace they want. @smarterclayton, was that what you expected?

[miminar]

I'm not sure whether I'd expect the first person to push an image to be able to surface their signatures into any other namespace they want. @smarterclayton, was that what you expected?

@liggitt shall we rather allow for per-project image signatures? And allow to pin a signature to an image by a cluster image-signer. I don't disagree. My only concern is signature redundancy and possible complexity.

[smarterclayton]

With pull through present, it's not sufficient to say "first pusher gets to
push signatures". For now, only admins can push signatures. David and I
went through some options here, but for the short term signatures are for
admins and infrastructure, and these APIs are targeted towards that.

On Wed, Jun 8, 2016 at 9:41 AM, Michal Minar notifications@github.com
wrote:

I'm not sure whether I'd expect the first person to push an image to be
able to surface their signatures into any other namespace they want.
@smarterclayton https://github.com/smarterclayton, was that what you
expected?

@liggitt https://github.com/liggitt shall we rather allow for
per-project image signatures? And allow to pin a signature to an image
by a cluster image-signer. I don't disagree. My only concern is
signature redundancy and possible complexity.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9181 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABG_p5JpexFFrnZ9rUVBnCdYBx36Mou2ks5qJsZtgaJpZM4IvEFx
.

[mtrmac]

Either way, I think I see the images/signatures endpoint as a good starting point for "special" components to use for signing.

👍

Yeah, let's get this merged and then figure out the per-namespace aspect; it does need to be figured out eventually.

[miminar]

Rebased. Removed an option to set signatures during Create(image). Signatures can now be updated only using images/signatures subresource.

We can add imagestream-scoped modification of iimage signatures (additions only) in a follow-up PR.

[smarterclayton]

Let's hold off on adding user focused signing until we have a design
proposal for securing it and limiting the impact on the cluster. There
were enough questions raised that I'm not sure I want to go forward until
we have agreement. Let's focus on admin and infra signing for now.

On Mon, Jun 13, 2016 at 4:38 AM, OpenShift Bot notifications@github.com
wrote:

continuous-integration/openshift-jenkins/test SUCCESS (
https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/4751/)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9181 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABG_px6o_GqN14L_RUQsfgFzOYto_8dJks5qLRchgaJpZM4IvEFx
.

[deads2k]

Don't add anything else to this file. See line 7.

[openshift-bot]

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/6704/)

[deads2k]

lgtm [merge]

[openshift-bot]

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/6704/) (Image: devenv-rhel7_4649)

[openshift-bot]

Evaluated for origin merge up to cf163c2

[miminar]

@deads2k, @mtrmac thank you! I'm glad we came to settlement ... finally 😄

Thanks to all the involved for valuable input.