[
https://issues.apache.org/jira/browse/CLOUDSTACK-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13890127#comment-13890127
]
Prachi Damle commented on CLOUDSTACK-5920:
------------------------------------------
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)
