Wiki Markup |
---|
h1. {color:#000000}{*}Background{*}{color}
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 API to grant permissions.
Goal for this feature would be to address these limitations and offer true IAM services in a phased manner
h1. {color:#000000}{*}Architecture and Design description{*}{color}
h2. {color:#000000}{*}IAM Taxonomy{*}{color}
{gliffy:name=iamTaxonomy|align=left|size=L|version=3}
h4. Group
Group contains a number of CloudStack accounts. Customers should be able to Create, Edit, List and Delete Groups. Editing includes adding or removing accounts to or from a group. For backwards compatibility, out of box, CloudStack will provide 3 default groups:
* Root Admin Group
* Domain Admin Group
* End User Group
h4. Account
Account is just our current CloudStack Account, all the permission controls are done at Account level. We can assign an Account to more than one Group.
h4. User
CloudStack user just contains login credentials, and this is not the level that we are performing permission control.
h4. Policy
Policy is a set of permission. Customer should be able to attach several policies to a Group to define the permission for that group. By default, we have the following 3 types of policy templates:
# Root Admin Policy: have permissions to all resources in the CloudStack.
# Domain Admin Policy: have permissions to all resources under the belonging domain.
# Resource Owner Policy: have permissions to all owned resources.
Other than that, customer should be able to define customized policies by grant or deny permission to customize permissions for the group. So far, for cross-account permission grant, we are currently supporting the following 3 types of granting/denying:
* Grant by Domain and Resource Type: grant permissions to all resources of the given resource type under the given domain.
* Grant by Account and Resource Type: grant permissions to all resources of the given resource type under the given account.
* Grant by individual resource: grant permission to an individual resource.
h4. Policy Permission
A policy consists of set of Permissions. A Permission is a way of defining access control.
Using Permission, customer defines what actions are allowed or denied, on what resources, under which account or domain.
A single permission definition consists of:
* Action (API Name)
* Allow / Deny
* Scope {Account | Domain | Resource}
* Scope Id {Id of the above defined scope}
* Resource Type
h2. {color:#000000}{*}IAM Schema{*}{color}
h2. {color:#000000}{*}IAM API{*}{color}
h2. {color:#000000}{*}IAM Interface{*}{color}
|
Currently CloudStack provides very limited IAM services and there are several drawbacks within those services:
Goal for this feature would be to address these limitations and offer true IAM services in a phased manner
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
Group contains a number of CloudStack accounts. Customers should be able to Create, Edit, List and Delete Groups. Editing includes adding or removing accounts to or from a group. For backwards compatibility, out of box, CloudStack will provide 3 default groups:
Account is just our current CloudStack Account, all the permission controls are done at Account level. We can assign an Account to more than one Group.
CloudStack user just contains login credentials, and this is not the level that we are performing permission control.
Policy is a set of permission. Customer should be able to attach several policies to a Group to define the permission for that group. By default, we have the following 3 types of policy templates:
Other than that, customer should be able to define customized policies by grant or deny permission to customize permissions for the group. So far, for cross-account permission grant, we are currently supporting the following 3 types of granting/denying:
A policy consists of set of Permissions. A Permission is a way of defining access control.
Using Permission, customer defines what actions are allowed or denied, on what resources, under which account or domain.
A single permission definition consists of:
...