search

deis / controller

Deis Workflow Controller (API)
https://deis.com
MIT License
41 stars 53 forks source link

Proposal: Teams #1214

Open deis-admin opened 7 years ago

deis-admin commented 7 years ago

From @Joshua-Anderson on July 31, 2015 23:4

Teams would be a way to share access to a group of apps with a team of people.

Example:

# create a new team called frontend and add current user to it
$ deis teams:create frontend
# add a user called foo to the frontend team.
$ deis perms:create foo --team=frontend
# create a app that is owned by the frontend team
$ deis apps:create epic-app --owner=frontend
# transfer a personal app to the frontend team
$ deis apps:transfer frontend
# List teams a user is a member of:
$ deis teams:list
frontend
...
# To list members of a team:
$ deis teams:members foo
foo
...
# apps:list shows team apps as well as personal apps
$ deis apps:list
epic-app
....
# Leave a team called frontend
$ deis perms:delete --team=frontend
# An admin forces user foo to leave team frontend
$ deis perms:delete foo --team=frontend
# Admins of a team can delete it
$ deis teams:delete frontend

Integration with #4150 - Fine Grained Permissions

Cluster wide permissions

Admins could grant members of a team cluster wide permissions

# grant ops team certs permission
$ deis perms:create ops --certs
App level

You can share apps with teams, whose permission with that app can be limited

# share an app with the frontend team, but don't let them view or set config
$ deis perms:create frontend
$ deis perms:delete frontend --config
Team Permissions:

Their are two types of team members: normal and admins. Team admins can add or remove users from a team, list team members, delete the team, and transfer or share team apps.

The team creator is an admin, and they can make other users admins with:

# make foo a team admin of frontend
$ deis perms:create --team=frontend --team-admin

Copied from original issue: deis/deis#4173

deis-admin commented 7 years ago

From @woopstar on August 1, 2015 7:29

+1 on this one

deis-admin commented 7 years ago

From @krancour on August 4, 2015 23:47

# grant ops team certs permission
$ deis perms:create ops --ops

Should this read:

# grant ops team certs permission
$ deis perms:create ops --certs

?

deis-admin commented 7 years ago

From @Joshua-Anderson on August 4, 2015 23:49

@krancour Thanks, that was a typo.

deis-admin commented 7 years ago

From @krancour on August 4, 2015 23:50

Overall, :+1: on the proposal.

deis-admin commented 7 years ago

From @krancour on August 4, 2015 23:56

# transfer a personal app to the frontend team
$ deis apps:transfer frontend

IMO, it should also be possible to transfer ownership to another user in the event teams aren't in use.

deis-admin commented 7 years ago

From @Joshua-Anderson on August 4, 2015 23:57

@krancour Already done! #4193

deis-admin commented 7 years ago

From @krancour on August 4, 2015 23:59

Nice!

deis-admin commented 7 years ago

From @bacongobbler on August 5, 2015 1:39

My 2 cents on the UX:

create a new team called frontend

To expand, this should also add you to the group, otherwise the group will be created but nobody can add users to it (except admins, of course).

Admins can force members to leave a team

$ deis teams:leave frontend --username=foo

If perms:create is the endpoint for adding members to the team, then shouldn't this be perms:delete foo --team=frontend?

I think we're going to need to take a look at the current perms model and see how this fits in (perhaps replace it with teams? perms has always been a confusing endpoint to explain to users), but this is a good first pass for UX. :+1:

deis-admin commented 7 years ago

From @Joshua-Anderson on August 5, 2015 2:44

To expand, this should also add you to the group, otherwise the group will be created but nobody can add users to it (except admins, of course).

I agree. This was my intent, I just forgot to make it explicit.

If perms:create is the endpoint for adding members to the team, then shouldn't this be perms:delete foo --team=frontend?

Agreed and fixed

think we're going to need to take a look at the current perms model and see how this fits in (perhaps replace it with teams? perms has always been a confusing endpoint to explain to users), but this is a good first pass for UX. :+1:

I agree, I think that is something that should be revistied with v2, but We might be able to do something about it currently if we deprecate it. I'll open a new proposal about that later.

deis-admin commented 7 years ago

From @krancour on August 5, 2015 18:42

I put some more thought into this. I came from a large enterprise with many regulatory access and audit concerns, so rethinking and improving access management is a topic that gets me going. :smile: I think larger customers may need this.

think we're going to need to take a look at the current perms model and see how this fits in (perhaps replace it with teams? perms has always been a confusing endpoint to explain to users), but this is a good first pass for UX.

I agree, I think that is something that should be revistied with v2

Here are my (obviously opinionated) thoughts on what would be a good CLI UX in a V2. Fundamentally, it's about improved consistency, following the principle of least surprise, and deliberately designing the UX to reinforce a user's understanding of the team-based (role-based, really) access model and the relationship between users, teams, and permissions.

Self-registration

Register (same as always):

$ deis register

User Management

List users (requires appropriate permission):

$ deis users:list

Create a user. This does the same thing as register, but instead of being used to register oneself, is used by admins:

$ deis users:create <username>

See info for a user (can be done by self, else requires appropriate permission):

$ deis users:info <username>

Update a user (update mutable fields like email; can be done by self, else requires appropriate permission):

$ deis users:update <username> --<field>=<value>

Delete a user (can be done by self, else requires appropriate permission):

$ deis users:delete <username>

See teams a user belongs to (can be done by self, else requires appropriate permission):

$ deis users:teams <username>

Team Management

List teams (requires appropriate permission):

$ deis teams:list

Create a team (requires appropriate permission):

$ deis teams:create <username>

See team info (may include a description; requires appropriate permission):

$ deis teams:info <team name>

Update a team (update mutable field like description; requires appropriate permission):

$ deis teams:update <team name> --<field>=<value>

Delete a team (requires appropriate permission):

$ deis teams:delete <team>

Manage a team's members

List a team's members (requires appropriate permission):

$ deis teams:members <team name>

Add a member to a team (requires appropriate permission):

$ deis teams:add-member <team name> <member name>

Delete a member from a team (requires appropriate permission):

$ deis teams:delete-member <team name> <member name>

Manage a team's permissions

List a team's permissions (requires appropriate permission):

$ deis teams:permissions <team name>

Add a permission to a team (requires appropriate permission):

$ deis teams:add-permission <team name> --<resource type>=<resource identifier> --action=<action identifier> # More on this below...

Delete a permission from a team (requires appropriate permission):

$ deis teams:delete-permission <team name> --<resource type>=<resource identifier> --action=<action identifier> # More on this below...

Underlying model

The underlying model is a traditional RBAC model (team == role). Permissions are a fine-grained white list of actions that may be performed on a resource or resources. Teams (or roles) are bundles of permissions to which users may be assigned.

Managing permissions does, implicitly require that the resources and actions each permission is comprised of can be called out using well-known or discoverable identifiers. Here's how I would propose those work:

Resource identifiers

These would take the form <resource type>:<resource name>[:<resource modifier>]. Resource type and optional resource modifier would be well-known, hard-coded, and documented. Resource names would be discoverable using commands of the CLI as described above.

Examples:

Wildcards would also be useful:

As would other descriptors:

Action identifiers

Action identifiers applicable to each resource type would be well-known, hard-coded, and documented.

Actions applicable to a user:

Actions applicable to a team:

Actions applicable to a team's membership:

Actions applicable to a team's permissions:

Actions applicable to an app:

Actions applicable to an app's configuration:

Wildcards would also be useful:

Any action: *

Putting it all together

Out of the box, an admin team would already exist. Its permissions would look as follows and would allow and admin to do anything.

$ deis teams:permissions admin
  Resource |            Action
  ---------------------------------
  user:*                            *
  team:*                           *
  team:*:membership      *
  team:*:permissions       *
  app:*                             *
  app:*:config                   *

Using the CLI as described above, the admin could construct teams with appropriate permissions.

A team of developers that can only access and deploy applications owned by their management, but can't see or manage the configuration or do much of anything else on the platform:

$ deis teams:permissions avengers-developers
  Resource                                                            | Action
  -------------------------------------------------------------------------
  app:owned-by(avengers-managers)                    read
  app:owned-by(avengers-managers)                    deploy

A team of managers that can create and manage their own apps, but can't deploy or manage configuration. They can also manage membership in their own team and related teams.

$ deis teams:permissions avengers-managers
  Resource                                                            | Action
  ----------------------------------------------------------------------------------------
  app:owned-by(avengers-managers)                    *
  team:avengers-managers:membership               *
  team:avengers-developers:membership             *

A devops team that can deploy all apps and manage configuration for all apps. They can also create, and fully manage their own applications, but can not administer their own team membership.

$ deis teams:permissions devops
  Resource                                                            | Action
  ---------------------------------------------------------------------------
  app:*                                                                     deploy
  app:*:config                                                          *
  app:owned-by(devops)                                        *
smolinari commented 7 years ago

I am new to Deis, but I have some experience with RBAC systems, and I'd like to slightly disagree with this proposal, if I may (and if I understood the proposal correctly).

In the systems I've been accustomed to, a "groups", or in this case "teams", access feature in a permissions system usually wouldn't extend data or application manipulation permissions per se. It is a data visibility control.

For instance, let's say you have 2 teams "A" and "B" and you have three apps "X", "Y" and "Z". Teaming could mean a Team A would have visibility/ access to apps X and Y and Team B would have access only to apps Y and Z.

In turn, each member's assigned role within the system would determine what they can do with those apps (i.e. read, write, delete or update or even more, see below). So for instance, you could have a delegated admin and a dev in team A, and each can do only what they are allowed to do on the apps visible to them through their team assignment. In other words, the team assignment would NOT give them extra data manipulation permissions (or feature access controls).

Another useful thing to have is any and all actions (features) be "can do" permissions. Like can pull images. Can push images. Can start apps, Can delete, Can Read, whatever. I am not sure of all the features available within Deis, but the actions (or permissions) should be controlling the ability to use any of those features.

As an added suggestion, what is really powerful, should the actions be modelled as "Can dos" like described above, is a "permission set" system. In such a system, you can give each user a "set" of "allowed actions". You would group the actions needed for doing certain managerial or administrative tasks and can give users these sets of permissions, depending on how they need to do their work. This is much, much more flexible than a purely role based access model.

For instance, you could set up a very fine grained "image manager" permission set, and give it to someone who already has a "Developer" role. So, you could give a developer some DevOps tasks. The ability to group up permissions and assign them to users is really, really powerful and makes the permission system very transparent, because you only have to look at a user to see what they are able to do. A user would have a very basic role (i.e. Admin, DevOps, Dev) and some added permission sets, if needed.

I realize that is a lot to ask for, but such a permissions system would make Deis stand out from the rest by a mile on the permissions system front. Having said all that though, I am not sure Deis as a PaaS building software needs that kind of fidelity in user access controls, but it definitely couldn't hurt. 😃

Scott

blakebarnett commented 7 years ago

👍 for this, we need RBAC integration with k8s especially. It would be ideal if the cluster roles were surfaced in Deis and you could assign them (not necessarily managed via Deis though, I can see that getting very complicated quickly). Ideally I could just specify which namespace apps get deployed into and define roles for that namespace (ie. per-team).

bacongobbler commented 7 years ago

@blakebarnett that was the idea behind this: we were planning on writing deis teams that would integrate with RBAC authz such that a namespace would be given a role, users could be granted certain roles that would allow them to deploy their apps into said namespaces. At the time I was looking at working on deis teams, RBAC was in a half-broken or near-unusable state so I (or someone who feels motivated to tackle this) will have to come back to that now that RBAC seems usable.

The OP and previous comments are out of date; assumptions were made against Deis v1 which was based on Fleet/Etcd. We'll have to come up with an updated design doc before working on this one.

xiaoping378 commented 7 years ago

I am new to Deis, i am looking up the solution which it supports teams on k8s, In my opinion, the easiest way is to make multi controllers available on k8s, and one team one controller（workflow）.