search

SUSE / Portus

Authorization service and frontend for Docker registry (v2)
http://port.us.org/
Apache License 2.0
3k stars 472 forks source link

Nested Teams -- or adding multiple teams to a namespace? #771

Open diranged opened 8 years ago

diranged commented 8 years ago

I realized that I misunderstood how the whole public/not-public namespace issue worked. I thought that if a namespace was not public, any authenticated user through Portus could still pull from that registry. I see now after doing some testing that this is not the case. That makes sense actually. Private namespaces are indeed private.

Ok here's the scenario I'm trying to handle though.

1) We have an eng team of ~60 -- and I do not want to manage the employees in many teams manually. That sounds like a nightmare. I know that LDAP group support is already an issue (#734) -- so I'll leave this alone for the time being.

2) We want to give our entire engineering organization pull access to all namespaces (/prod, /dev-test, /foobar-team-stuff, etc). We only want to control push access to namespaces and limit that to certain groups. Right now, it seems like the only way to do this is to maintain nearly a team per namespace, and individually add members to every single namespace as necessary.

Am I misunderstanding something? Is there a simple way for us to create a "global" team thta gives people pull access to every single image in the repo, and then individually control push access?

mssola commented 8 years ago

Your situation makes sense, and that's something that I already thought about, but didn't implement for time constraints and keeping things simple for the first big release :) I think that what you are actually looking for is #606. An internal policy would allow pull from anyone logged in, but push access only to team members. Would that work for you ?

diranged commented 8 years ago

@mssola, So thinking about this further, I think there are two different issues here.

Mark Namespaces as "Protected"

One option here is to be able to mark individual namespaces as protected -- thus ensuring that only an authenticated user can pull images from them. This solves our use case perfectly, and I think makes sense for almost any private registry system. This is tracked in #606 and I think should be implemented ASAP. (If I was any good at Ruby, which I'm not, I'd help write the patch for ya).

Nested Teams still make sense too

The other issue here is the idea that a single namespace should be able to leverage multiple teams. Github used to do their permissions structure in the same way that you guys are. A single namespace (or repo) could have a team assigned to it, and that team object actually managed the permissions of the users inside the team. They've recently changed their system though so that a team is nothing but a collection of users, and when a team is added to a repo it is given the appropriate privs (read, write, admin).

This fundamental model change is strong, and I would encourage Portus to mimic it. It allows administrators to maintain a small and predictable set of groups of users, and then individual namespace owners to give those groups the correct permissions to the namespace.

In our case, we would have the following groups:

Then you could imagine namespaces like:

The above model lets you re-use the teams and mix-and match them as appropriate for different repos.

mssola commented 8 years ago

Argh, sorry! I read your whole comment but then forgot to answer about team nesting :sweat_smile:

I cannot find the issue right now, but I remember having a bit of a discussion of a team or a user having multiple namespaces. In this case, it would be a bit different to what you are proposing. Right now the relationship is that a namespace belongs to a team, not the other way around; and teams are supposed to keep track of the permissions of each team member. That being said, the idea was to allow teams to have more than one namespace. I think that this would already cover you needs and it would be less disruptive than changing the relationship from team owns a namespace to team belongs to namespace.

What do you think ?

diranged commented 8 years ago

I'm not sure without understanding more of the implementation details. For my specific need, #606 actually should basically cover it. Really the team issue I'm bringing up is a suggestion for the wider audience of users. I think its pretty clear that Github realized they had gotten the Team/Project relationship wrong when they up and rebuilt it last year. I know that its disruptive to change the model, but I think you should consider it. The model of a namespace having different teams added (with specific permissions) maps more closely I think to the way organizations actually think.

The "engineering" team is "bob, jane and joe" -- always. Now, for the /dev namespace we want "engineering" to be able to push, but for the /prod namespace we just want them to be able to pull.

mssola commented 8 years ago

The "engineering" team is "bob, jane and joe" -- always. Now, for the /dev namespace we want "engineering" to be able to push, but for the /prod namespace we just want them to be able to pull.

It seems to be more flexible, but it would be too disruptive. Maybe this is something that we should consider for another release (we already have a lot to do for the next release :sweat_smile:).

diranged commented 8 years ago

@mssola -- that I totally understand. I think that #606 is going to solve our most immediate problems. I'd like to leave this ticket open to track the larger issue of potentially reevaluating the relationship between teams and namespaces. It can be addressed in a future major release.

mssola commented 8 years ago

@diranged agreed :+1:

flavio commented 8 years ago

It seems to be more flexible, but it would be too disruptive. Maybe this is something that we should consider for another release (we already have a lot to do for the next release :sweat_smile:).

I agree with that and I'm glad that #606 can help @diranged on the short term. However on the long term I like his proposal about nested teams.

holgerreif commented 8 years ago

Following is a proposal on how to set up the future team / namespace relationship. It should serve as a base for discussion rather than for immediate implementation. It extends on the comment by @diranged.

Current situation

(Summary from port.us.org doc) A team is a group created by portus admin. Team members are added by portus admin either individually or by connecting it with an LDAP group (to be implemented by #734). Team members can have one out of three different roles: Owner, Contributor, Viewer. Role owner can manage group membership and member roles too.

This gives us the following relationship

Future situation

A (team) namespace is owned by a team. I will call it the controlling team. The primary purpose of this team is to delegate access rights to other teams (or individuals). Those teams as a whole (and not their individual members) will get a role of Viewer or Contributor.

So in principle the controlling team just needs members with owner roles to manage (controlling) team membership, namespaces and access to them. However for backward compatibility, for use within small setups and possibly for ease of implementation viewer and contributor roles are honored as well when evaluating access rights to repos.

We end up with the following relationship

Possible workflow for determining access control

  1. user needs to authenticate itself
  2. check if this user is configured as individual on this namespace with apropriate access right (read or write)
    • if user is found you're done
  3. iterate over all teams with the apropriate access right for the namespace
    • if user is found you're done
  4. check if user is member of controlling team with apropriate access right
    • if user is found you're done
  5. deny access

Open questions

mssola commented 8 years ago

@holgerreif thanks for adding to the discussion :+1:

A (team) namespace is owned by a team. I will call it the controlling team. The primary purpose of this team is to delegate access rights to other teams (or individuals). Those teams as a whole (and not their individual members) will get a role of Viewer or Contributor.

So in principle the controlling team just needs members with owner roles to manage (controlling) team membership, namespaces and access to them. However for backward compatibility, for use within small setups and possibly for ease of implementation viewer and contributor roles are honored as well when evaluating access rights to repos.

Instead of calling it the controlling team, I'd call it just "owner". Then, the team that owns a namespace can add more teams to it with some permission options. To me, this looks like umask :) :

In order to improve this:

(optional) A namespace is associated with one ore more individuals configured with access rights

I don't quite like this honestly. Let's keep it simple for now.

(optional) An indivdual has access rights to one or more (team) namespaces (in addition to his personal namespace)

Since I don't agree with the previous point, this results to what we currently have: users have access to their personal namespace and to tone namespace.heir respective team memberships.

Is it desirable to create a new team by the team controlling the namespace or should it still be the task of portus admin?

This would make sense if we allowed nested teams (which neither you nor me like :P). Otherwise, I propose to keep it as it is.

Has the team to have visibility only for this name space?

With this proposal, a team would have visibility over the owner namespaces, and the namespaces in which it has been added (with proper restrictions as defined previously).

Do we need a owner role within this team to manage group membership?

By group you mean set of teams ? I'd say that team owners can add/remove new teams as desired. It's implicit that owners are responsible for this I'd say.

Is it desirable to add not only teams but individuals as well? This might be usefull especially if team cannot be created by portus admin only.

Not for now I'd say. As I said previously, let's keep it simple for now. We can think about this in another iteration.

Is owner (or manager) role for management independent of the viewer/contributor role for read/write/none-acces to content?

As stated previously in my comment, no. An owner has read/write access and deals with team/user memberships.

Do we need nested teams (I'm not convinced on this)?

I don't think so since this proposal already covers whatever feature nested teams might provide.

holgerreif commented 8 years ago

When creating the construct of a (single) "controlling" group I had in mind to make the change less disruptive. However having more then one owning group could be helpful (and makes the whole thing "more complete")

If a team is added with contributor rights, then owners of said team will be "deprecated" to just contributors.

Well, the owners of said team are still repsonsible for managing the team membership (as long as this team ist not bound to an LDAP group). The deprecation is only with repect to owning the namespaces. This in accordance with

Do we need a owner role within this team to manage group membership?

By group you mean set of teams ? I'd say that team owners can add/remove new teams as desired. It's implicit that owners are responsible for this I'd say.

One point is still open for me

Has the team to have visibility only for this name space?

With this proposal, a team would have visibility over the owner namespaces, and the namespaces in which it has been added (with proper restrictions as defined previously).

Say we have two owner teams O1 and O2 owning namespaces N1 and N2 and both of them create a team T with access rights to their namespace: Is this the same team T in both cases?

I feel, if O1 and O2 are allowed to create teams for their namespace then we end up with nested teams and we need to maintain team membership twice (if both teams T should have the same members). I would prefer to have portus admin create the team T before and the "owner of the owner team" can select an additional team from the list of teams available inside portus.

Does this make sence?

BTW not dealing with individual is absolutely fine with me.

mssola commented 8 years ago

Well, the owners of said team are still responsible for managing the team membership (as long as this team is not bound to an LDAP group). The deprecation is only with respect to owning the namespaces.

That's correct. I was only saying that in regards to how these members can interact with the namespaces they just "gained" :) That why I opened #802, because this can quickly be confusing for users that are not so savvy on how things work in Portus :)

Say we have two owner teams O1 and O2 owning namespaces N1 and N2 and both of them create a team T with access rights to their namespace: Is this the same team T in both cases?

I feel, if O1 and O2 are allowed to create teams for their namespace then we end up with nested teams and we need to maintain team membership twice (if both teams T should have the same members). I would prefer to have portus admin create the team T before and the "owner of the owner team" can select an additional team from the list of teams available inside portus.

Does this make sence?

But we said that we wouldn't allow nested teams right ? So, saying that teams O1 and O2 create T does not make sense. It's simply not possible by the design of this proposal :) So, what it's being proposed I think is that teams would still be created by Portus admins, and then owners of teams can decide whether they want to include a team for their namespaces.

holgerreif commented 8 years ago

Okay, so we are in agreement: creation/removal of teams remains responsibility of portus admin.

mssola commented 8 years ago

A note on team/namespace creation permissions from #966 (by @holgerreif):

  1. Creation of teams:
    • admin privilege required
    • no privilege required (default)
  2. Creation of namespaces
    • admin privilege required
    • team owner privilege required (default)

Even if currently looks like a binary option I wouldn't implement it as binary flag, since this might cause problems in future whent the rights management scheme needs extensions...