SUSE / Portus

Authorization service and frontend for Docker registry (v2)

Home Page:http://port.us.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Mapping legacy repositories to Portus namespace repositories

anrxc opened this issue · comments

commented

Hello. We are migrating our legacy solution to your nice software.

Our legacy repositories were accessed like this:

$ docker pull docker-registry.company.com/useful-software

Our custom solution would decide if that user account is permitted to access this particular repository or not.

Portus seemingly allows all users to pull from the global repository namespace. For example given the 172.17.0.100:5000 registry, Portus automatically creates a namespace with same name and Portus explains: "Visibility - Global namespace cannot be private"

So instead the Team "Software Group" was created with Namespace that belongs to it: "software_group". Now Portus allows authenticated users that belong to the Team to do a pull from:

$ docker pull docker-registry.company.com/software_group/useful-software

Because we have thousands of users this path change will break a lot of legacy deployment tools/automation/scripts.

Do you have any idea how we could possibly keep legacy paths working while still benefitting from all your nice granular access controls?

I am not a great Docker expert, first thing that came to my mind was trying to utilize Nginx frontend for this, since it's already there doing other things for Portus.

I created two rewrites:

  Request:      /v2/useful-software/manifests/latest
  Rewritten to: /v2/software_group/useful-software/manifests/latest

  Request:      /v2/token?account=username-here&scope=repository%3Auseful-software%3Apull&service=172.17.0.100%3A5000
  Rewritten to: /v2/token?account=username-here&scope=repository%3Asoftware_group%2Fuseful-software%3Apull&service=172.17.0.100%3A5000

But unfortunately either this can't work, or it is still missing some needed rewrites because docker client responds: Error: image useful-software not found

..and the Nginx logs show docker client is directed by the manifest to download /v1/repositories/useful-software/images instead of /v2/software_group/useful-software/blobs/sha256...

Thank you.

commented

For anyone stumbling onto this in the future I think I found 1 way to make it work without causing any other issues, security or otherwise.

Token requests should not be rewritten, they can use proxy_pass to retain authentication information docker client sent with the original request. Here's Nginx pseudo configuration that you can apply to Apache, Lighttpd or whatever:

location /v2/  {
    #Requests matching: /v2/useful-software/manifests/latest
    #    Rewrite to: /v2/software_group/useful-software/manifests/latest

...

location /v2/token {
    # Request matching: /v2/token?account=username-here&scope=repository%3Auseful-software%3Apull&service=172.17.0.100%3A5000
    #     proxy_pass https://portus/v2/token?account=username-here&scope=repository%3Asoftware_group%2Fuseful-software%3Apull&service=172.17.0.100%3A5000;