[jira] [Comment Edited] (CLOUDSTACK-5920) CloudStack IAM Plugin feature

["Prachi Damle (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13890127#comment-13890127 ] 

Prachi Damle edited comment on CLOUDSTACK-5920 at 2/3/14 11:42 PM:
-------------------------------------------------------------------

Hi Daan,

The rbac design includes access control over both - at api level and at resource level.
It is possible to limit what APIs an account can invoke, as well it is possible to define what resources the account can invoke those actions too.

example:
UseCase: I want to create a set of accounts that have permissions to all list Apis only
Solution:
- Create a group for these accounts
- Create a custom policy and add permissions to this policy for every API that is allowed.
- Attach this policy to the group

UseCase: I want to grant permissions to all VMs in my account for Start/Stop/List actions,  to another account.
Solution:
- Create a custom policy and add permissions granting access per API one can invoke for the ResourceType VM under scope Account and scopeId = <Vm owner accountId>
- Permissions will look like:
id | action | resource_type |  scope_id | scope | access_type | permission 
1 | startVirtualMachine | VirtualMachine | <account_id> | ACCOUNT | UseEntry | Allow	
1 | stopVirtualMachine | VirtualMachine | <account_id> | ACCOUNT | UseEntry | Allow	
1 | listVirtualMachines| VirtualMachine | <account_id> | ACCOUNT | UseEntry | Allow	

- Attach this policy to the account you want to grant access too.

Thus the permission grant involves API's as well as resources.


was (Author: prachidamle):
Hi Daan,

The rbac design includes access control over both - at api level and at resource level.
It is possible to limit what APIs an account can invoke, as well it is possible to define what resources the account can invoke those actions too.

example:
UseCase: I want to create a set of accounts that have permissions to all list Apis only
Solution:
- Create a group for these accounts
- Create a custom policy and add permissions to this policy for every API that is allowed.
- Attach this policy to the group

UseCase: I want to grant permissions to all VMs in my account for Start/Stop/List actions,  to another account.
- Create a custom policy and add permissions granting access per API one can invoke for the ResourceType VM under scope Account and scopeId = <Vm owner accountId>

Permissions will look like:
 acl_permission

id | action | resource_type |  scope_id | scope | access_type | permission 
1 | startVirtualMachine | VirtualMachine | <account_id> | ACCOUNT | UseEntry | Allow	
1 | stopVirtualMachine | VirtualMachine | <account_id> | ACCOUNT | UseEntry | Allow	
1 | listVirtualMachines| VirtualMachine | <account_id> | ACCOUNT | UseEntry | Allow	

- Attach this policy to the account you want to grant access too.

Thus the permission grant involves API's as well as resources.

> CloudStack IAM Plugin feature
> -----------------------------
>
>                 Key: CLOUDSTACK-5920
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5920
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: API, Management Server
>    Affects Versions: 4.3.0
>            Reporter: Prachi Damle
>            Assignee: Prachi Damle
>             Fix For: 4.4.0
>
>
> Currently CloudStack provides very limited IAM services and there are several drawbacks within those services:
> -  Offers few roles out of the box (user and admin) with prebaked access control for these roles. There is no way to create additional roles with customized permissions.
> -  Some resources have access control baked into them. E.g., shared networks, projects etc. 
> -  We have to create special dedicate APIs to grant permissions to resources.
> - Also it should be based on a plugin model to be possible to integrate with other RBAC implementations say using AD/LDAP in future 
> Goal for this feature would be to address these limitations and offer true IAM services in a phased manner.
> As a first phase, we need to separate out the current access control into a separate component and create a standard access check mechanism to be used by the API layer. Also the read/listing APIs need to be refactored accordingly to consider the role based access granting.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)