Jason Guiditta wrote:
On Tue, 2009-10-13 at 10:47 -0400, Scott Seago wrote:
As a follow-on to yesterday's post on privileges, we need to consider the grouping of these privileges into roles. This part is not quite as crucial, since the role-to-privilege mapping can be changed dynamically. We should eventually provide APIs for actually creating and modifying roles, but for the initial release we can probably get by with a pre-set default set of roles as we're currently doing with oVirt. The role names themselves probably need a bit of tweaking as well.
Pool roles (these roles are normally attached to individual pools)
User (basic user -- can manipulate instances but not create/destroy or view monitoring stats for them: INSTANCE_CONTROL = "instance_control" INSTANCE_VIEW = "instance_view" POOL_VIEW = "pool_view"
User with Monitoring (all User privileges plus viewing monitoring stats INSTANCE_CONTROL = "instance_control" INSTANCE_VIEW = "instance_view" POOL_VIEW = "pool_view" STATS_VIEW = "stats_view"
Pool User (full access to instances within a pool): INSTANCE_CONTROL = "instance_control" INSTANCE_VIEW = "instance_view" POOL_VIEW = "pool_view" STATS_VIEW = "stats_view" INSTANCE_MODIFY = "instance_modify" QUOTA_VIEW = "quota_view"
provider roles (normally attached to providers)
Pool Creator (can create new pools attached to existing cloud accounts, can't modify quotas on created pools) PROVIDER_VIEW = "provider_view" POOL_MODIFY = "pool_modify" POOL_VIEW = "pool_view" QUOTA_VIEW = "quota_view"
Pool Administrator (can create new pools with new or existing cloud accounts and can modify quotas on created pools) PROVIDER_VIEW = "provider_view" POOL_MODIFY = "pool_modify" POOL_VIEW = "pool_view" QUOTA_VIEW = "quota_view" QUOTA_MODIFY = "quota_modify" ACCOUNT_MODIFY = "account_modify" ACCOUNT_VIEW = "account_view"
account roles (normally attached to accounts) Account Administrator (can edit/delete the account) ACCOUNT_MODIFY = "account_modify" ACCOUNT_VIEW = "account_view"
Account User (can attach this account to a new pool) ACCOUNT_VIEW = "account_view"
site wide roles (normally attached to SystemPermission) Provider Administrator (also attached to provider to indicate the ability to edit existing providers) PROVIDER_MODIFY = "provider_modify" PROVIDER_VIEW = "provider_view"
User Administrator (can create and modify other users) USER_MODIFY = "user_modify" USER_VIEW = "user_view"
Permission Administrator (can grant access to other users; granted to any user at whatever level that user needs to be able to grant access to others) PERM_SET = "set_perms" PERM_VIEW = "view_perms"
Administrator (if we allow cascading of SystemPermission to pools, etc then this should include all the other privileges as well -- to allow for a site-wide admin who can do everything). PROVIDER_MODIFY = "provider_modify" PROVIDER_VIEW = "provider_view" USER_MODIFY = "user_modify" USER_VIEW = "user_view" PERM_SET = "set_perms" PERM_VIEW = "view_perms"
Are there any of the above roles that should automatically get the permission admin privileges as well?
Can't think of any atm, but I will give it more thought again after lunch
The other aspect of this is what permissions are automatically granted upon various actions. For example any user who creates a pool is granted the "pool user role for that pool -- should this include user admin (i.e. ability to share access with others) for the pool as well?
Not sure how exactly to fit this in, but I think if someone is given pool admin, they might need a different role than 'user admin', as really they may only be adding existing users, not modifying them. I was going to say 'user view', which could really be for anybody, but there may need to be something in between, since pool admin may really be adding perms to users to say they can access this pool at a certain level - but they can really take away other privs. OTOH, do we even need this whole path? I thought for deltacloud, we were going the path of pool-per-user? Or am I remembering wrong? /me has not been focused on perm structure lately...
First of all that was a typo -- I meant "permission admin" not "user admin" for the pool -- adding/modifying users would have no relevance at the pool level, since users don't belong to pools. Permission admin is needed at this level -- someone who has permission to add users to _this pool_ -- the main question here is whether _any_ pool admin can share access, or if that's a different admin level.
As for pool-per-user, at the model level we have no restrictions that require at most one permission record for a resource -- so the model lets many users have permissions on it. Forcing it to one wouldn't allow for a separation of monitoring roles -- since you wouln't be able to add another user as a "monitory only" role to a pool. By default I'd imagine that only the creating user has access to a pool when it's created. For a personal dev environment, this is as far as it will go. However if we're supporing qa or prod environments, or shared dev or test instances, we will probably need the ability for the initial pool creator to add other users to the access list.