cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prachi Damle (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CLOUDSTACK-5920) CloudStack IAM Plugin feature
Date Mon, 03 Feb 2014 23:43:15 GMT

    [ 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:43 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 to.

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.
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.

> 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)

Mime
View raw message