deis
Proposal: Fine Grained Permissions
From @Joshua-Anderson on July 30, 2015 20:52
Right now, there are two permission levels in deis:
- administrators
- full access
- normal users
- full access to create apps and manage their own apps.
This proposal would overhaul the permission system by allowing much more finer controller over which users can do.
Cluster Permissions
- certs
- add or remove certs from the cluster
- apps
- create/destroy
- app management: view, modify, share, and transfer other user's apps.
App permissions
- config
- read or modify config
- push
- can push code or create a release
- domains
- add or remove domains
- scale
- scale an app up or down
Default Permissions
Administrators have all permissions granted.
An ETCD setting would set the default permissions for new users:
Example key layout:
/deis/controller/permissions/apps true
/deis/controller/permissions/certs true
...
Example Usage
# an admin shares user cert permission with user foo
$ deis perms:create foo --cert --apps
# an app owner removes config permission from user tester
$ deis perms:delete tester --config
# users can view what permissions they have
$ deis perms:view
Cluster Wide Permissions
===================
certs
App epic-app Permissions
====================
config
push
scale
# admins and app owners can also view a users permissions
$ deis perm:list --username=foo
App epic-app Permissions
====================
config
push
scale
Testing
Almost all of this code resides in the controller, so it would mostly involve lots of tests in the controller to make sure all the edge cases are covered.
Migration
Migration should be pretty simple, admins would still have all access, and a migration script would grant all existing users their current permissions.
The same would apply for apps, the app owner would have all access and users who had the app shared would get the subset of permissions they already had.
Copied from original issue: deis/deis#4150
From @fbjork on July 30, 2015 21:5
This looks great. It would solve most of my current needs!
From @Joshua-Anderson on August 3, 2015 18:59
I removed the sharing permission because I felt it was odd and probably problematic to be able to invite users but not set their permissions. I feel that #4173 (Teams) will help better solve this problem.
From @Joshua-Anderson on August 3, 2015 19:1
I removed the users permission because that is better left to administrators. For example, somebody with the users permission could regenerate a administrators token and take control of their account.
From @Joshua-Anderson on August 3, 2015 20:27
I opened a in-depth PR for docs related to permissions at #4186.