Now that we have login authentication for the portal, the next step is to come up with an infrastructure for granting and enforcing permissions on objects.
At the moment I'd like to follow the same overall approach that we took for oVirt, with a few modifications.
At the lowest level, we maintain a list of "privileges" in the database which represent a particular type of allowed action. These could be very fine-grained levels such as "start instance", "create instance", "create pool", "view instance statistics", "grant user access", etc., or we could use more general privileges such as "modify", "view", "control instances", etc.
Privileges will be fairly closely tied to available actions, so we would not provide an API to add/remove these -- they're fairly closely tied to the actions we've already implemented in the portal code.
Going up one level, a "role" is an associated group of privileges (but not yet tied to a particular resource). Roles exist mainly for convenience -- a set of privileges often used together are grouped in a role to simplify granting permissions to a user. So, for example, an "admin" role might combine "create instance", "create Pool", "start Instance", etc. -- or if we're using less fine-grained privileges, "admin" might include "create", "modify", and "view" privileges.
For oVirt we never got to the point of providing an API for manipulating roles (i.e. create a new role that combines privileges X, Y, and Z), but we could do that here as a future enhancement.
A Permission record (or perhaps "granted permission") associates a user with a resource and a particular role. For example, when a user creates a portal pool, a permission record will be created that assigns the creating user an "admin" role for the pool. This user might later grant a lesser "instance management" role to another user for this same pool -- in order to delegate permission to start/stop instances, etc. In addition we might want to control access to images, so we might want to grant users permission to use specific images for instance creation.
What other actions need permissions defined on them? Some possibilities:
1) Provider creation: Should only certain users be allowed to associate the portal with external cloud providers? What object would these permissions be attached to?
2) Create new pool/cloud account for a provider: Is this allowed for any user, or will a user need permissions granted for the provider object to allow the user to add a new pool/cloud account.
3) Create new pool for existing cloud account: Other than providing appropriate cloud account credentials, are there additional permissions required if the cloud account is already used by another user for a different pool (since one cloud account can be used for multiple portal pools)?
4) High-level admin role: Able to grant permissions for 1), add new user accounts, etc
In addition to using a polymporphic association for the "permission object" rather than just a pool (to support permission grants on a variety of resource types), we might need to make the field nullable so that we can define "global" roles for permissions not attached to a specific resource (who can create providers, who can grant top-level permissions, etc)
As for the UI, we can use the ovirt permissions UI as the starting point. For the associated object (pool, provider, etc) we add a permissions tab with a table/grid of users showing assigned roles. The global roles would need to be accessed as a separate tab somewhere on the main UI.
Scott
Is the assumption that the driver is unaware of these permissions, and enforces a different set based on the credentials which are passed over?
-- bk
On 10/01/2009 12:54 PM, Scott Seago wrote:
Now that we have login authentication for the portal, the next step is to come up with an infrastructure for granting and enforcing permissions on objects.
At the moment I'd like to follow the same overall approach that we took for oVirt, with a few modifications.
At the lowest level, we maintain a list of "privileges" in the database which represent a particular type of allowed action. These could be very fine-grained levels such as "start instance", "create instance", "create pool", "view instance statistics", "grant user access", etc., or we could use more general privileges such as "modify", "view", "control instances", etc.
Privileges will be fairly closely tied to available actions, so we would not provide an API to add/remove these -- they're fairly closely tied to the actions we've already implemented in the portal code.
Going up one level, a "role" is an associated group of privileges (but not yet tied to a particular resource). Roles exist mainly for convenience -- a set of privileges often used together are grouped in a role to simplify granting permissions to a user. So, for example, an "admin" role might combine "create instance", "create Pool", "start Instance", etc. -- or if we're using less fine-grained privileges, "admin" might include "create", "modify", and "view" privileges.
For oVirt we never got to the point of providing an API for manipulating roles (i.e. create a new role that combines privileges X, Y, and Z), but we could do that here as a future enhancement.
A Permission record (or perhaps "granted permission") associates a user with a resource and a particular role. For example, when a user creates a portal pool, a permission record will be created that assigns the creating user an "admin" role for the pool. This user might later grant a lesser "instance management" role to another user for this same pool -- in order to delegate permission to start/stop instances, etc. In addition we might want to control access to images, so we might want to grant users permission to use specific images for instance creation.
What other actions need permissions defined on them? Some possibilities:
Provider creation: Should only certain users be allowed to associate the portal with external cloud providers? What object would these permissions be attached to?
Create new pool/cloud account for a provider: Is this allowed for any user, or will a user need permissions granted for the provider object to allow the user to add a new pool/cloud account.
Create new pool for existing cloud account: Other than providing appropriate cloud account credentials, are there additional permissions required if the cloud account is already used by another user for a different pool (since one cloud account can be used for multiple portal pools)?
High-level admin role: Able to grant permissions for 1), add new user accounts, etc
In addition to using a polymporphic association for the "permission object" rather than just a pool (to support permission grants on a variety of resource types), we might need to make the field nullable so that we can define "global" roles for permissions not attached to a specific resource (who can create providers, who can grant top-level permissions, etc)
As for the UI, we can use the ovirt permissions UI as the starting point. For the associated object (pool, provider, etc) we add a permissions tab with a table/grid of users showing assigned roles. The global roles would need to be accessed as a separate tab somewhere on the main UI.
Scott
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
Bryan Kearney wrote:
Is the assumption that the driver is unaware of these permissions, and enforces a different set based on the credentials which are passed over?
-- bk
I would assume so, yes. In the portal we certainly can't give more to an account than it already has on the cloud. Also these are permissions granted to portal users -- which won't have a one-to-one correspondence with cloud users. In other words we might have several different portal users that are all using the same RHEV-M account -- either in separate portal pools, or with shared access to a single portal pool -- in the latter case we might have one user with more restrictive permisions. i.e. user foo might be able to create/start/stop/destroy instances but user bar might only be able to start and stop. The RHEV-M account will be the same for both. Of course, if the rhev-m account doesn't have destroy permission then having portal destroy permission won't help.
The idea is that portal permissions define what portal users are allowed to do via the portal -- some portal actions (most, actually) require cloud actions done with the permissions granted on thecloud side to the cloud account -- but permissions for the cloud account aren't controlled by the portal. This is done by the native cloud interface.
So for the most part the driver can ignore this entirely. The driver doesn't even know that there are multiple portal users sharing a single account (or one user with access to multiple accounts).l
On 10/01/2009 12:54 PM, Scott Seago wrote:
Now that we have login authentication for the portal, the next step is to come up with an infrastructure for granting and enforcing permissions on objects.
At the moment I'd like to follow the same overall approach that we took for oVirt, with a few modifications.
At the lowest level, we maintain a list of "privileges" in the database which represent a particular type of allowed action. These could be very fine-grained levels such as "start instance", "create instance", "create pool", "view instance statistics", "grant user access", etc., or we could use more general privileges such as "modify", "view", "control instances", etc.
Privileges will be fairly closely tied to available actions, so we would not provide an API to add/remove these -- they're fairly closely tied to the actions we've already implemented in the portal code.
Going up one level, a "role" is an associated group of privileges (but not yet tied to a particular resource). Roles exist mainly for convenience -- a set of privileges often used together are grouped in a role to simplify granting permissions to a user. So, for example, an "admin" role might combine "create instance", "create Pool", "start Instance", etc. -- or if we're using less fine-grained privileges, "admin" might include "create", "modify", and "view" privileges.
For oVirt we never got to the point of providing an API for manipulating roles (i.e. create a new role that combines privileges X, Y, and Z), but we could do that here as a future enhancement.
A Permission record (or perhaps "granted permission") associates a user with a resource and a particular role. For example, when a user creates a portal pool, a permission record will be created that assigns the creating user an "admin" role for the pool. This user might later grant a lesser "instance management" role to another user for this same pool -- in order to delegate permission to start/stop instances, etc. In addition we might want to control access to images, so we might want to grant users permission to use specific images for instance creation.
What other actions need permissions defined on them? Some possibilities:
- Provider creation: Should only certain users be allowed to associate the portal with external cloud providers? What object
would these permissions be attached to?
Create new pool/cloud account for a provider: Is this allowed for any user, or will a user need permissions granted for the provider object to allow the user to add a new pool/cloud account.
Create new pool for existing cloud account: Other than providing appropriate cloud account credentials, are there additional permissions required if the cloud account is already used by another user for a different pool (since one cloud account can be used for multiple portal pools)?
High-level admin role: Able to grant permissions for 1), add new user accounts, etc
In addition to using a polymporphic association for the "permission object" rather than just a pool (to support permission grants on a variety of resource types), we might need to make the field nullable so that we can define "global" roles for permissions not attached to a specific resource (who can create providers, who can grant top-level permissions, etc)
As for the UI, we can use the ovirt permissions UI as the starting point. For the associated object (pool, provider, etc) we add a permissions tab with a table/grid of users showing assigned roles. The global roles would need to be accessed as a separate tab somewhere on the main UI.
Scott
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
On Thu, 2009-10-01 at 12:54 -0400, Scott Seago wrote:
Now that we have login authentication for the portal, the next step is to come up with an infrastructure for granting and enforcing permissions on objects.
At the moment I'd like to follow the same overall approach that we took for oVirt, with a few modifications.
At the lowest level, we maintain a list of "privileges" in the database which represent a particular type of allowed action. These could be very fine-grained levels such as "start instance", "create instance", "create pool", "view instance statistics", "grant user access", etc., or we could use more general privileges such as "modify", "view", "control instances", etc.
I think I agree with this approach - though once we get into making a detailed list of privileges, we definitely need to account for monitoring, as that is likely to be a billable action, so we dont want just any user monitoring their instances (unless we are doing this for all machines and distributing the cost per user, I suppose)
Privileges will be fairly closely tied to available actions, so we would not provide an API to add/remove these -- they're fairly closely tied to the actions we've already implemented in the portal code.
Going up one level, a "role" is an associated group of privileges (but not yet tied to a particular resource). Roles exist mainly for convenience -- a set of privileges often used together are grouped in a role to simplify granting permissions to a user. So, for example, an "admin" role might combine "create instance", "create Pool", "start Instance", etc. -- or if we're using less fine-grained privileges, "admin" might include "create", "modify", and "view" privileges.
For oVirt we never got to the point of providing an API for manipulating roles (i.e. create a new role that combines privileges X, Y, and Z), but we could do that here as a future enhancement.
In general, do you have any thoughts on format of the portal api? For instance, could we go with REST, as we do with framework, vs a separate 'service layer' like we had to do with ovirt (due to the complexity of actions, I believe)?
A Permission record (or perhaps "granted permission") associates a user with a resource and a particular role. For example, when a user creates a portal pool, a permission record will be created that assigns the creating user an "admin" role for the pool. This user might later grant a lesser "instance management" role to another user for this same pool -- in order to delegate permission to start/stop instances, etc. In addition we might want to control access to images, so we might want to grant users permission to use specific images for instance creation.
Related to this- I think perhaps there may be some benefit to separating out 'cloud accounts' from pool creation in some way. I mention it here because it could impact the design of how we assign permissions/privileges/roles/. I was thinking it might be useful to have a way for an admin to just set up, say, corporate cloud accounts. That admin may then give certain users permission to create pools for specific corporate accounts. However, these users may well not have the actual username and password for the cloud account, so they might get a list of accounts they can create a pool on instead of fields for username and password. Smaller installations (or even certain larger ones I guess) might additionally allow users to both create a pool and add an account at the same time, but this seems like more of a specific (and even less common) use case rather than a general approach, to me.
What other actions need permissions defined on them? Some possibilities:
- Provider creation: Should only certain users be allowed to associate the portal with external cloud providers? What object would these permissions be attached to?
I definitely think so, as alluded to above. Pulling something up from later in this email, I think this would map to some sort of admin role, with a create_provider privilege (or similar), and the permission could be attached to a global PortalObject, or something along those lines.
- Create new pool/cloud account for a provider: Is this allowed for any user, or will a user need permissions granted for the provider object to allow the user to add a new pool/cloud account.
Again, I think these are two things, and that we do indeed need permissions for both. A user may be able to create a pool, but not a cloud account (though not sure the reverse would ever be true). So perhaps a user has a role like pool_admin, and that contains a create_pool privilege, which can then be mapped to specific Provider objects at the discretion of a sysadmin.
- Create new pool for existing cloud account: Other than providing appropriate cloud account credentials, are there additional permissions required if the cloud account is already used by another user for a different pool (since one cloud account can be used for multiple portal pools)?
I think this would be the create_pool concept outlined above.
- High-level admin role: Able to grant permissions for 1), add new user accounts, etc
Absolutely
In addition to using a polymporphic association for the "permission object" rather than just a pool (to support permission grants on a variety of resource types), we might need to make the field nullable so that we can define "global" roles for permissions not attached to a specific resource (who can create providers, who can grant top-level permissions, etc)
As we discussed on the phone, I think it would be cleaner from a code design standpoint to go the route of having some sort of global object that generic permissions can be attached to, rather than having checks for nil. This is what I called PortalObject above (though not at all pushing that specific name, maybe GenericPermission or something else would make more sense)
As for the UI, we can use the ovirt permissions UI as the starting point. For the associated object (pool, provider, etc) we add a permissions tab with a table/grid of users showing assigned roles. The global roles would need to be accessed as a separate tab somewhere on the main UI.
We could, but I think that the oVirt UI was a bit weak in the clarity department, and perhaps there is another mechanism other than additional tabs that we may want to consider. I think it would be worth pulling in Jeremy to see if he has any design ideas here. I do agree with the sentiment to keep it as simple as possible though.
Just a random idea that popped into my head - perhaps the perms could be integrated right in the objects' associated pages? For instance, lets say I am a pool_admin, so I have create rights for providers X, Y & Z. When I look at the list of providers I have access to, it could say somewhere right on the description/detail for that provider, what I have permission to do (so, 'Create Pools for this provider' maybe even with some icon scheme and an alt on the image saying what it means). However, if I am an admin, maybe I have an addition tool that allows me to grant perms to certain users for all the providers I checked boxes for. I realize there may be other use cases to consider, but this was just a first pass, and it may be nice to keep as much functionality accessible from wherever you are as we can (so long as it can be done in a manner that does not make it confusing for the user). Just my 2 cents.
-j
Jason Guiditta wrote:
On Thu, 2009-10-01 at 12:54 -0400, Scott Seago wrote:
Now that we have login authentication for the portal, the next step is to come up with an infrastructure for granting and enforcing permissions on objects.
At the moment I'd like to follow the same overall approach that we took for oVirt, with a few modifications.
At the lowest level, we maintain a list of "privileges" in the database which represent a particular type of allowed action. These could be very fine-grained levels such as "start instance", "create instance", "create pool", "view instance statistics", "grant user access", etc., or we could use more general privileges such as "modify", "view", "control instances", etc.
I think I agree with this approach - though once we get into making a detailed list of privileges, we definitely need to account for monitoring, as that is likely to be a billable action, so we dont want just any user monitoring their instances (unless we are doing this for all machines and distributing the cost per user, I suppose)
Yes we would definitely want a separate monitor privilege (or several?). Basically we need to come up with the list of privileges we want to check against -- this is the part that requires the most work to change later, since the action-level permission checks check for specific privileges -- unless we want to go crazy and put the privilege-to-action mapping in the db as well, but I think that's overkill.
Privileges will be fairly closely tied to available actions, so we would not provide an API to add/remove these -- they're fairly closely tied to the actions we've already implemented in the portal code.
Going up one level, a "role" is an associated group of privileges (but not yet tied to a particular resource). Roles exist mainly for convenience -- a set of privileges often used together are grouped in a role to simplify granting permissions to a user. So, for example, an "admin" role might combine "create instance", "create Pool", "start Instance", etc. -- or if we're using less fine-grained privileges, "admin" might include "create", "modify", and "view" privileges.
For oVirt we never got to the point of providing an API for manipulating roles (i.e. create a new role that combines privileges X, Y, and Z), but we could do that here as a future enhancement.
In general, do you have any thoughts on format of the portal api? For instance, could we go with REST, as we do with framework, vs a separate 'service layer' like we had to do with ovirt (due to the complexity of actions, I believe)?
Another area we need to discuss further, as it goes beeyond just monitoring. With oVirt we started with a rest API but then later sort of abandoned the idea in favor of QMF. David was working on making the existing oVirt controllers work for the REST api, but we stopped that when QMF came up. I don't think we've thought through this enough to decide where we're going with this, but with a REST API the portal would at least be similar in what it exposes to the other deltacloud components -- although the actions, credentials, etc would all be different -- for portal we'd be passing portal credentials, not cloud ones, etc.
A Permission record (or perhaps "granted permission") associates a user with a resource and a particular role. For example, when a user creates a portal pool, a permission record will be created that assigns the creating user an "admin" role for the pool. This user might later grant a lesser "instance management" role to another user for this same pool -- in order to delegate permission to start/stop instances, etc. In addition we might want to control access to images, so we might want to grant users permission to use specific images for instance creation.
Related to this- I think perhaps there may be some benefit to separating out 'cloud accounts' from pool creation in some way. I mention it here because it could impact the design of how we assign permissions/privileges/roles/. I was thinking it might be useful to have a way for an admin to just set up, say, corporate cloud accounts. That admin may then give certain users permission to create pools for specific corporate accounts. However, these users may well not have the actual username and password for the cloud account, so they might get a list of accounts they can create a pool on instead of fields for username and password. Smaller installations (or even certain larger ones I guess) might additionally allow users to both create a pool and add an account at the same time, but this seems like more of a specific (and even less common) use case rather than a general approach, to me.
The tightly-couple cloud account/pool creation forms was purely a function of coding to the demo and the fact that one of the "user stories" for the demo called for a new user to connect to a cloud (i.e. create a cloud account) and then create an instance on the next form. What you describe above is close to how I was envisioning the pool/account creation before we came up with the more streamlined demo user story.
So to support this we'd have a create_account privilege on provider, and a create_pool privilege on account. A user with the former can add new "corporate accounts", and a user with the latter sees that account in the "choose an account" list for pool creation.
What other actions need permissions defined on them? Some possibilities:
- Provider creation: Should only certain users be allowed to associate the portal with external cloud providers? What object would these permissions be attached to?
I definitely think so, as alluded to above. Pulling something up from later in this email, I think this would map to some sort of admin role, with a create_provider privilege (or similar), and the permission could be attached to a global PortalObject, or something along those lines.
- Create new pool/cloud account for a provider: Is this allowed for any user, or will a user need permissions granted for the provider object to allow the user to add a new pool/cloud account.
Again, I think these are two things, and that we do indeed need permissions for both. A user may be able to create a pool, but not a cloud account (though not sure the reverse would ever be true). So
Well we'd separate the privileges in any case -- for one thing create_pool would be (for non-account-creating users) a permission on the account object, since that's how the UI would know which accounts to include in the "choose an account for your pool" drop-down list. We could _also_ add create_pool to the provider list if we want to let the user create an account and pool together.
perhaps a user has a role like pool_admin, and that contains a create_pool privilege, which can then be mapped to specific Provider objects at the discretion of a sysadmin.
Hmm. I guess there are 2 different uses for create_pool. Create_pool on the provider object determines if a user can create a pool at all -- create_pool on the account object(s) determine which accounts a user can attach a pool to.
- Create new pool for existing cloud account: Other than providing appropriate cloud account credentials, are there additional permissions required if the cloud account is already used by another user for a different pool (since one cloud account can be used for multiple portal pools)?
I think this would be the create_pool concept outlined above.
Yes, the above way of handling it is better than what I described in 3)
- High-level admin role: Able to grant permissions for 1), add new user accounts, etc
Absolutely
In addition to using a polymporphic association for the "permission object" rather than just a pool (to support permission grants on a variety of resource types), we might need to make the field nullable so that we can define "global" roles for permissions not attached to a specific resource (who can create providers, who can grant top-level permissions, etc)
As we discussed on the phone, I think it would be cleaner from a code design standpoint to go the route of having some sort of global object that generic permissions can be attached to, rather than having checks for nil. This is what I called PortalObject above (though not at all pushing that specific name, maybe GenericPermission or something else would make more sense)
As for the UI, we can use the ovirt permissions UI as the starting point. For the associated object (pool, provider, etc) we add a permissions tab with a table/grid of users showing assigned roles. The global roles would need to be accessed as a separate tab somewhere on the main UI.
We could, but I think that the oVirt UI was a bit weak in the clarity department, and perhaps there is another mechanism other than additional tabs that we may want to consider. I think it would be worth pulling in Jeremy to see if he has any design ideas here. I do agree with the sentiment to keep it as simple as possible though.
Just a random idea that popped into my head - perhaps the perms could be integrated right in the objects' associated pages? For instance, lets say I am a pool_admin, so I have create rights for providers X, Y & Z. When I look at the list of providers I have access to, it could say somewhere right on the description/detail for that provider, what I have permission to do (so, 'Create Pools for this provider' maybe even with some icon scheme and an alt on the image saying what it means). However, if I am an admin, maybe I have an addition tool that allows me to grant perms to certain users for all the providers I checked boxes for. I realize there may be other use cases to consider, but this was just a first pass, and it may be nice to keep as much functionality accessible from wherever you are as we can (so long as it can be done in a manner that does not make it confusing for the user). Just my 2 cents.
Integrating the perms into the object's pages is exactly what I had in mind -- for oVirt we do exactly that -- it's just that we're only dealing with pools, so adding permission to a pool's page means adding another tab as the initial view was too cluttered already. As to whether we add another div to the main content area for providers, accounts, pools, etc or whether it's a separate tab, that's a detail we can work with Jeremy on.
-j
Scott
Scott Seago wrote:
Jason Guiditta wrote:
On Thu, 2009-10-01 at 12:54 -0400, Scott Seago wrote:
At the lowest level, we maintain a list of "privileges" in the database which represent a particular type of allowed action. These could be very fine-grained levels such as "start instance", "create instance", "create pool", "view instance statistics", "grant user access", etc., or we could use more general privileges such as "modify", "view", "control instances", etc.
I think I agree with this approach - though once we get into making a detailed list of privileges, we definitely need to account for monitoring, as that is likely to be a billable action, so we dont want just any user monitoring their instances (unless we are doing this for all machines and distributing the cost per user, I suppose)
I've started working on the list of lower-level privileges that we want to track for the portal. The main change from the way I did it with ovirt is I'm separating some of the basic privileges (modify and view) into type-specific values. This allows us to create finer-grained roles if we want to have users with more specialized needs, but we can still lump them together for more general roles such as "admin" or "user". In particular, type-specific modify privileges lets us grant some users the ability to create new pools on a provider without giving them the ability to link to new cloud accounts -- by giving the user a role that contains pool_modify but does not contain account_modify.
Here's the list I have right now defined in privilege.rb (so they can be referenced as constants by the various controller actions for checking a specific privilege). In addition to making sure we haven't missed any, the other question is how we handle the SystemPermission singleton model. Some permissions must be attached there -- 'provider_modify' is needed there to add new providers, since we need a notion of "top level" permissions there. But what about other privileges? Do we use assignment of privileges to that top level object to indicate global overrides for admins -- i.e. an admin with 'account_modify' on SystemPermission can add new accounts anywhere, etc. Or should we only use this object for permissions that _must_ be top-level blanket permissions and require admins to be added manually to various pools, etc. to have administration rights on them?
#default privileges PERM_SET = "set_perms" # can create/modify/delete permission # records on this object PERM_VIEW = "view_perms" # can view permission records on this # object
# instance privileges normally checked at the pool level, although # instance-specific overrides could be a future enhancement. INSTANCE_MODIFY = "instance_modify" # can create, modify, delete, or
# control (start, stop, etc) instances INSTANCE_CONTROL = "instance_control" # can control (start, stop, etc)
# instances INSTANCE_VIEW = "instance_view" # can view instance metadata
# do we need a separate "connect" privilege?
# stats privileges normally checked at the pool level, although # instance-specific overrides could be a future enhancement. STATS_VIEW = "stats_view" # can view monitoring data for # instances
# account privileges normally checked at the provider level, although # account-specific overrides could be a future enhancement. ACCOUNT_MODIFY = "account_modify" # can create or modify cloud accounts ACCOUNT_VIEW = "account_view" # can create or modify cloud accounts
# pool privileges normally checked at the provider level # (and at the account level for choosing which accounts are visible on the # new pool form), although # pool-specific overrides could be a future enhancement. POOL_MODIFY = "pool_modify" # can create or modify a pool POOL_VIEW = "pool_view" # can view a pool
# quota privileges normally checked at the pool or account level, # depending on which quota level we're dealing with # (account level for cloud-imposed quota, pool level for portal quota) QUOTA_MODIFY = "quota_modify" # can create or modify a quota QUOTA_VIEW = "quota_view" # can view a quota
# provider privileges normally checked at the provider level, although # 'new provider' action requires this privilege at the SystemPermission level PROVIDER_MODIFY = "provider_modify" # can create or modify a provider PROVIDER_VIEW = "provider_view" # can view a provider
# normally checked at the SystemPermission level USER_MODIFY = "user_modify" # can create a new user (other than # self-registration) or modify another # user's metadata (for admin-level # actions) USER_VIEW = "user_view" # can view a user's profile data
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?
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? Provider creation gives that user "pool administrator" for the provider. Creating an account gives "account administrator" for the account (what about user admin for the last two?)
Scott
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...
Provider creation gives that user "pool administrator" for the provider. Creating an account gives "account administrator" for the account (what about user admin for the last two?)
Scott
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.
On Oct 8, 2009, at 12:30 PM, Jason Guiditta wrote:
As for the UI, we can use the ovirt permissions UI as the starting point. For the associated object (pool, provider, etc) we add a permissions tab with a table/grid of users showing assigned roles. The global roles would need to be accessed as a separate tab somewhere on the main UI.
We could, but I think that the oVirt UI was a bit weak in the clarity department, and perhaps there is another mechanism other than additional tabs that we may want to consider. I think it would be worth pulling in Jeremy to see if he has any design ideas here. I do agree with the sentiment to keep it as simple as possible though.
I was starting to think you guys didnt like me anymore! I'll check in with you guys tommorow (bug me if i forget).
deltacloud-devel@lists.fedorahosted.org
-
Bryan Kearney -
Jason Guiditta -
Jeremy Perry -
Scott Seago