Allow controlled anonymous access

[deitch]

This is a split from #276

We want to have an option to allow anonymous pull access to a given namespace (and eventually repo). Right now we have 2 levels of access control per namespace:

• public (owner/member can pull+push; no one else can do anything)
• private (owner/member can pull+push; anyone logged in can pull)

We would need 3 levels

• public (owner/member can pull+push; no one else can do anything)
• private (owner/member can pull+push; anyone logged in can pull)
• open (owner/member can pull+push; anyone even not logged in can pull)

This also requires changes to the UI to control the level of openness at the namespace.

[mssola]

This seems like a fair feature to me, but we have to be careful. First of all, how does a non-logged in user know which repos can be pulled ? I guess that you would say that a non-logged in user would get the url somehow (e.g. a logged in user passes this other user the url) and then pull it. But I'd say that it would be convenient to have the list of "open" repos somewhere accessible for non-logged in users.

@flavio @deitch what do you think ?

[deitch]

Yes, quite. It is the same problem that the official hub.docker.com registry has. How do you find public repos, without exposing private ones? The official registry handles it in 3 ways:

1. you already know the URL (everyone knows about busybox or centos;7 or ruby:latest)
2. The Web search interface, which only lets you see those that you have at the very least pull rights for.
3. docker search which to the best of my knowledge only returns those that you have at the very least pull rights for. But I didn't see an option there to select a registry...

[mssola]

@deitch your second point hits the nail for me. I think that we should do like Docker Hub here: expose the search element even when the user is logged out. We already filter repos in the search feature, so this would work automatically when exposed for non-logged in users. Therefore:

• Show the top navigation bar for non-logged in users too.
• The top navigation bar would have the search widget available, and any search would be automatically filtered for open repos.
• The top navigation bar would have an "Explore" link, just like Docker hub, in which the non-logged users would have a list of all the "open" repos.

[flavio]

I don't know if adding a 3rd level of access is the right choice. Why don't we add a global flag that makes 'public' namespaces readable also by users that are not logged into the registry?

I also like the idea of having an "explore" feature.

BTW, we have to double check registry actually allows not-logged users to complete a docker pull

[dohnto]

I would definitely utilize this feature in our use case.

Actually I have created a very similar piece of software as Portus. I had more granular permission system (a pull/push permission could be given to a user or team to namespace or whole repository) and also anonymous users could browse the registry front-end and then pull the repositories, which were marked as public.

In our case, this feature would be very desired due to different automated daemons (marathon+mesos), which could pull repositories without creating no special user for them (I know I can use portus user) or by hacking the raw requests.

[mssola]

This is another feature that I'd like to see for the next release. In two steps:

1. Allow public namespaces to be pullable by non-logged users.
2. Provide a UI for exploring public repositories even when non-logged.

I'd implement the first point for this release, and leave the second point for another time. For the first point I'm not sure how to proceed. We have these options:

1. Public also means that non-logged in users can pull. The downside of this is that we then lose the possibility to define namespaces as public inside of Portus. This hurts settings such: a team that has private namespaces, a namespace for anyone inside of the organization (that is in Portus) and a namespace for anyone else (the rest of the world).
2. We provide a configurable value: if enabled, then the current behavior is kept, otherwise we go to the first point.
3. Mixed solution: public is no longer a boolean value. Instead it can have three values: private, protected and public. Then instead of saying whether a namespace is public or not, we would say "what's the visibility of this namespace?". Private would mean that only the current members can pull, protected means that anyone that is logged in can pull, public means that anyone can pull.

@flavio I've checked registry, and you can pull without being logged in. The only thing that does not allow this from happening is Portus. However, if you want to push and you're not logged in, then Docker will ask for permissions.

What do you think?

[deitch]

@mssola I don't understand your point, I think because I don't get the alternate namespaces. I get public - open to everyone - and I get private - open to me and anyone I name as a member, depending on their access rights (pull, pull/push). What is the third value? When would we require a repo to be pulled by anyone logged in? If it is public, then I don't care who pulls it; if it is private, no one can pull except those I named. What is the use case for restricting it to anyone logged in?

[mssola]

What is the use case for restricting it to anyone logged in?

This is the current behavior of public :) These would be namespaces that are available company-wide, but not outside of the company. Yes, you could just make it private and then add users, but imagine the situation in which you have a ton of users, this won't escalate nicely ;)

[deitch]

Oh, right. The way this is handled on github and docker hub is to set it to private, allow read-only access to a group named for your company, and then add users to that group. If you are running github enterprise inside your network, you can just keep it network segregated.

Personally, I don't see the use for it, but I am not so narrow-minded as to believe I know all of the use cases (thankfully), and hoping I never will be! :-)

[mssola]

Ok, after talking about it internally, we've decided that the best way to go is with the second point. This is the easiest way to go and it already provides what we need.

The third option is the most flexible, but we don't have experiences with deployments with tons of users yet. Moreover, if there are tons of users in the system, other questions can be raised like: maybe adding users one by one is not the best option in this case, and we need to add members to a team in a more clever way (changing this would invalidate what I said in my previous comment).

All in all, let's not anticipate and let's go for the safest option which is the second one :)

[deitch]

My turn to disagree. I think having public mean one thing in one config and another thing in another is asking for trouble. Different users of Portus will read public as different thing. Issues raised here will be unclear. I think consistency and clarity trump features. I would sooner see it not support public, then have an ill-defined public, and only add it later.

My $0.02

[mssola]

@deitch you've got a point :) So, let's go with the simpler approach (public means also for not signed-in users), and if the community requests for a "protected" approach we'll add it afterwards.

[dohnto]

To mention just one project, which uses this 3 level visibility, see Gitlab.

[mssola]

@dohnto I'm aware that Gitlab does it :) However, it's easier for us to first give a simpler implementation and then add the "protected" visibility level later on if users request it (or if we decide that's worth giving it a shot :P).

[diranged]

@mssola,
So this is a pretty important issue for many people I imagine. Is there anything to do here to help come up with the final design, or is it just about getting time to implement the code now?

[mssola]

@diranged the original issue was to allow access to anonymous users. This is right now the behavior of public. So, the only thing missing is to allow the protected policy (which would work as the old public used to: public inside of the company).

There's an open issue for that: #606. It's inside of the milestone "Tentative for 2.1", which means that we will try to implement it if we've got time, otherwise it would have to wait for another release. Of course, you can step in :) The main thing is that we need to transition from the public/private policies being a boolean (both on the DB and on the UI), and implement this new policy. So, from the design point of view, I don't think there's much to discuss :)