Not clear how to configure public registry with auth for upload

[Tom Haddon]

We'd like to use this charm to configure a publicly available registry with authenticated upload for images.

It seems like if we configure basic auth, we can't then have non-authenticated users download images.

[Kevin W Monroe (kwmonroe)]

This will be challenging. I don't see a clean way for a single registry to provide both unauth'd pulls and auth'd pushes. Topics I've read lean towards 2 registries that share a storage backend with a proxy that allows pulls / blocks pushes for the unauth'd client and allows all requests for the auth'd client.

I'm working on a bundle that does just that. Hopefully this will satisfy this request.

[Junien F (axino)]

Perhaps we can do auth ourselves by fronting with, say, an apache2 that allows GETs for everyone but PUT/POST/DELETE for a restricted list of authenticated users ?

[Mike Wilson (knobby)]

It depends on how you want to auth users. I'm not sure you could do a `docker login` with that setup. It might be easier than running two docker registries and hoping that there isn't a collision with one guy downloading an image from the public side while another uploads that same image to other side. I'm pretty sure that would be undefined behavior.

Both ways have their downsides and Docker hasn't really solved this problem.

[Tom Haddon (mthaddon)]

We believe we can do this via running two registries with different frontend domains (e.g. have auth on upload.docker-images.canonical.com and the public registry on docker-images.canonical.com). We can just configure both to have the same swift credentials, and only allow auth on upload.docker-images.canonical.com as necessary, but make docker-images.canonical.com globally readable.

We may need a config option to say that a particular registry is read-only (I'm not sure what the permissions are without any auth configured), but otherwise this seeems feasible. I'll create a ticket to track the work to do this internally and we'll update this bug when we're done.

[Dean Henrichsmeyer (dean)]

I realize this is a bit of a bike shed but I don't think we should have
docker in the hostname. registry.* or something more generic would be more
appropriate. Thanks.

[Junien F (axino)]

Would oci-images.c.c work ? (https://en.wikipedia.org/wiki/Open_Container_Initiative)

[Paul Collins (pjdc)]

I've implemented this config item and updated the staging deployment.

PR: https://github.com/CanonicalLtd/docker-registry-charm/pull/22

Available from cs:~canonical-sysadmins/docker-registry which please
note is much newer than the versions currently published to any channel.

And, per RT#114764, I've used this to rearrange the staging deployment.

[Paul Collins (pjdc)]

I just noticed that #50 is published to edge, so my remark above is incorrect.

[Kevin W Monroe (kwmonroe)]

This is fixed in cs:~containers/docker-registry-56 (currently in the beta channel). The process for deploying public/private registries is now documented in the charm readme:

https://github.com/CanonicalLtd/docker-registry-charm/blob/master/README.md#read-only-mode

[Kevin W Monroe (kwmonroe)]

This has made its way into the latest stable charm:

https://jujucharms.com/u/containers/docker-registry