Table of Contents | ||||
---|---|---|---|---|
|
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.
Ticket to track the feature implementation: https://issues.apache.org/jira/browse/CLOUDSTACK-5920
Note: IAM feature cannot be put in to current 4.5 codebase due to API gap and limitations found and documented here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+changes
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:
Here are list of entity types supported by IAM model:
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:
Currently CloudStack supports two different views: Full View for root admin user, Restricted View for domain admin and end user. With IAM added, we still need to support this for newly added account groups. Analogy to row filter controlled by Permission, this is like column filter. For this release, we are not supporting dynamic column filter at API level, instead, out-of-box, we will provide two static response views: Full View and Restricted View. When user is granting each API action to a group, they can specify what kind of response view for this API. For this release, we are supporting static response view choice for the following APIs:
For APIs not listed above, response will be the same for all the users(root admin, domain admin, normal user) as usual, by default, it is full response view.
New API's
In Phase1, these new IAM APIs are only limited to root admin.
CloudStack currently has a domain-tree based implementation of access checks, namely com.cloud.acl.DomainChecker. This implementation is based on an adapter interface of Cloudstack - org.apache.cloudstack.acl.SecurityChecker that defines the basic IAM interface to check ownership and access control to objects within the account/ domain.
The IAM plugin will provide another implementation 'PolicyBasedAccessChecker' of the SecurityChecker interface. We will also have to add to this interface some more methods or change some signatures to facilitate group, policy and api name (action) based access control.
Code Block |
---|
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 for allowed APIs. # Domain Admin Policy: have permissions to all resources under the belonging domain for allowed APIs. # Resource Owner Policy: have permissions to all owned resources for allowed APIs. 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. 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 h4. Response View (Column Filter) Currently CloudStack supports two different views: Admin view for root admin user, User view for domain admin and end user. With IAM added, we still need to support this for newly added account groups. Analogy to row filter controlled by Permission, this is like column filter. For this release, we are not supporting dynamic column filter at API level, instead, out-of-box, we will provide two static response views: Admin view and User view. When user is creating a group, they can specify what kind of view that this group account should see. h2. {color:#000000}{*}IAM Schema{*}{color} !iam_schema.png|border=1! h2. {color:#000000}{*}IAM API{*}{color} *New API's* * createAclGroup ## String name - name of the ACL group. [Required] ## String description - short decsription ## String domainId - UUID of the domain of the account owning the acl group * deleteAclGroup ## String id - UUID of the ACL group. [Required] * listAclGroups ## String name - name of the ACL group. ## String id - UUID of the ACL group. * addAccountToAclGroup ## String id - UUID of the ACL group. [Required] ## List<String> accounts - comma separated list of account id that are going to be assigned to the acl group * removeAccountFromAclGroup ## String id - UUID of the ACL group. [Required] ## List<String> accounts - comma separated list of account id that are going to be removed from the acl group * createAclPolicy ## String name - name of the ACL Policy. [Required] ## String description - short decsription ## String domainId - UUID of the domain of the account owning the acl policy ## String sourcePolicyId - UUID of the policy which should be used as a template to generate the new policy * deleteAclPolicy ## String id - UUID of the ACL Policy. [Required] * listAclPolicies ## String name - name of the ACL policy. ## String id - UUID of the ACL policy. * attachAclPolicyToAclGroup ## String id - UUID of the ACL group. [Required] ## List<String> policies - comma separated list of policy ids that are going to be assigned to the acl group * removeAclPolicyFromAclGroup ## String id - UUID of the ACL group. [Required] ## List<String> policies- comma separated list of policy ids that are going to be revoked from the acl group * createAclPermission ## String action - name of the API allowed/denied. [Required] ## String permission - "Allow"/ "Deny" ## String scope- ("Account" / "Domain" / "Resource") ## String scope id - UUID of the Scope ## String resourceType * addAclPermissionToAclPolicy ## String id - UUID of the ACL policy. [Required] ## List<String> permissionIds - comma separated list of permission ids that are going to be added to the acl policy * removeAclPermissionFromAclPolicy ## String id - UUID of the ACL policy. [Required] ## List<String> permission Ids - comma separated list of permission ids that are going to be removed from the acl policy h2. {color:#000000}{*}IAM Interface{*}{color} h3. IAM Interface to check Entity Access CloudStack currently has a domain-tree based implementation of access checks, namely com.cloud.acl.DomainChecker. This implementation is based on an adapter interface of Cloudstack - org.apache.cloudstack.acl.SecurityChecker that defines the basic ACL interface to check ownership and access control to objects within the account/ domain. The IAM plugin will provide another implementation 'PolicyBasedAccessChecker' of the SecurityChecker interface. We will also have to add to this interface some more methods or change some signatures to facilitate group, policy and api name (action) based access control. {code} /** * SecurityChecker checks the ownership and access control to objects within */ public interface SecurityChecker extends Adapter { ... /** * Checks if the account can access the object. * * @param caller * account to check against. * @param entity * object that the account is trying to access. * @param accessType * * @param action * * @return true if access allowed. false if this adapter cannot provide permission. * @throws PermissionDeniedException * if this adapter is suppose to authenticate ownership and the check failed. */ boolean checkAccess(Account caller, ControlledEntity entity, AccessType accessType, String action) throws PermissionDeniedException; .... } {code} h3. IAM Interface to check API Access IAM Plugin 'PolicyBasedAccessChecker' will also provide a group and policy based implementation of the APIChecker interface. The implementation will check if a given user is permitted to make the given API call by looking at the users' groups and the associated policies of those groups. For given user and given api name, - Find all groups the user belongs too. - Find all 'effective' policies the groups are associated to. Effective includes all policy associations in the DB and the dynamic 'Resource Owner' policy if the resource is owned - If any policy 'Allows' the API, grant permission to make this call - Else, if any policy 'Denies' the API, deny permission to make this call - else, if no Allow or Deny entry is found for any policy for this API, deny the permission {code} // APIChecker checks the ownership and access control to API requests public interface APIChecker extends Adapter { // Interface for checking access for a role using apiname // If true, apiChecker has checked the operation // If false, apiChecker is unable to handle the operation or not implemented // On exception, checkAccess failed don't allow boolean checkAccess(User user, String apiCommandName) throws PermissionDeniedException; } {code} h3. IAM Interface to facilitate Query APIs Besides SecurityChecker and APIChecker interface, IAM plugin will also implement another QueryChecker interface to allow CloudStack to do proper row filter in ListAPI based on caller's policy. {code} /** * QueryChecker returns granted domain, or account or resources for caller. */ public interface QueryChecker extends Adapter { ... /** * List granted domains for the caller, given a specific entity type. * * @param caller account to check against. * @param entityType entity type * @return list of domain Ids granted to the caller account. */ List<Long> getAuthorizedDomains(Account caller, String entityType); /** * List granted accounts for the caller, given a specific entity type. * * @param caller account to check against. * @param entityType entity type * @return list of domain Ids granted to the caller account. */ List<Long> getAuthorizedAccounts(Account caller, String entityType); /** * List granted resources for the caller, given a specific entity type. * * @param caller account to check against. * @param entityType entity type * @return list of domain Ids granted to the caller account. */ List<Long> getAuthorizedResources(Account caller, String entityType); } {code} h2. {color:#000000}{*}Response View{*}{color} Currently CloudStack provides different response views for Root admin and non-root user, some response fields are only visible to root admin. Basically we have provided two static response views (Admin view and User view), domain admin will also a User view. With new IAM service introduced, we should also allow customers to be able to specify what view should be applied to the new Acl group when they are creating a new customized Acl group, for example, customer care group. To achieve that, we will implement as follows: # We will have a column in AclGroup db table to record what view to be used for this group. From Acl group creation UI, user can pick which view to be associated with this group. Note that in this release, we are not going to support full-fledged column filter (that is, allowing users to pick arbitrary columns to be see for each API). We are only supporting static view association at the Acl group level. # We will separate all current both admin and user allowed API commands to two classes: API for admin and API for user. For example, previous ListVMsCmd will be splitted into two classes: *ListVMsCmdByAdmin* and *ListVMsCmd*. {code} @APICommand(name = "listVirtualMachines", description = "List the virtual machines owned by the account.", responseObject = UserVmResponse.class, responseView = ResponseView.User) public class ListVMsCmd extends BaseListTaggedResourcesCmd { ...... } @APICommand(name = "listVirtualMachines", description = "List the virtual machines owned by the account.", responseObject = UserVmResponse.class, responseView = ResponseView.Admin) public class ListVMsCmdByAdmin extends ListVMsCmd { ///////////////////////////////////////////////////// //////////////// API parameters ///////////////////// ///////////////////////////////////////////////////// @Parameter(name=ApiConstants.HOST_ID, type=CommandType.UUID, entityType=HostResponse.class, description="the host ID") private Long hostId; @Parameter(name=ApiConstants.POD_ID, type=CommandType.UUID, entityType=PodResponse.class, description="the pod ID") private Long podId; @Parameter(name=ApiConstants.STORAGE_ID, type=CommandType.UUID, entityType=StoragePoolResponse.class, description="the storage ID where vm's volumes belong to") private Long storageId; } {code} Note that *ListVMsCmdByAdmin* and *ListVMsCmd* are sharing the same API name "listVirtualMachines". From client perspective, this is transparent to them, CloudStack API client will still just invoke previous listVirtualMachine API, and CloudStack API server will internally consult with IAM plugin to determine the group associated with the invoking user and then determine which internal Cmd class to be invoked. There is a new attribute "responseView" introduced for @APICommand annoation, which can be used to instruct CloudStack to generate different response view. By separating the command class into admin cmd class and user cmd class, we can also restrict valid input parameters for different account. For example, in this case, when Admin invokes listVirtualMachine api, he/she can pass hostId, podId and storageId, which parameters are not applicable for end user. h2. {color:#000000}{*}Default Policy Generation{*}{color} For backward compatibility, out-of-box, we provided 3 default policies: Root admin policy, domain admin policy, and end user policy. The process to populate permissions for these default policies are as follows: # Parse all API command classes to check if they are annotated with "authorized" attribute. If so, populate a permission entry for that API for the default policy mapped to that authorized role. # Parse commands.property, create or override permission entries for each API for default policy mapped to API authorized roles. When user creates a customized policy, he can specify a source policy from list of default policies. Then we will create new mapping between these default policy permission entries and the new policy in *acl_policy_permission_map* table. h3. Sample DB entries for the default policies: *account* || id || account_name || uuid /** * Enumeration type for AccessType */ public enum AccessType { ModifyProject, OperateEntry, UseEntry, ListEntry } |
Example: A domainAdmin registers a template T and allows a regular user of the domain to launch a VM using that template.
Entity: TemplateT
Principal1: domainAdmin, Access allowed: OperateEntry (operate access since he can invoke delete/updatepermissions operations on the template)
Principal2: normal domain user, Access allowed: UseEntry (the user can only list the template and use it for launching VM)
The IAM implementation will check if a given user is permitted to invoke the given 'action' / 'accesstype' on the given resource by looking at the account's groups and the associated policies of those groups.
In phase I, all the permissions attached to any policy are by default explicit 'Allow' permissions. As of now 'Deny' permissions cannot be added.
Thus For given user, resource and given api name/accessType, default permission is 'deny', then run through this:
IAM Plugin 'PolicyBasedAccessChecker' will implement the APIChecker interface.
Code Block |
---|
// APIChecker checks the ownership and access control to API requests
public interface APIChecker extends Adapter {
// Interface for checking access for a role using apiname
// If true, apiChecker has checked the operation
// If false, apiChecker is unable to handle the operation or not implemented
// On exception, checkAccess failed don't allow
boolean checkAccess(User user, String apiCommandName) throws PermissionDeniedException;
}
|
The API permissions are also stored in the same db schema as the entity permissions. Since the above entity access already checks if the user is allowed to invoke the given API for the given resource, we need not have one more check just to see if the user can invoke the API.
So PolicyBasedAccessChecker :: checkAccess(User user, String apiCommandName), can return true always and rely on the entity based access check.
Besides SecurityChecker and APIChecker interface, IAM plugin will also implement another QuerySelector interface to allow CloudStack to do proper row filter in ListAPI based on caller's policy. In this phase, we only support explicitly grant permission, not deny permission.
Code Block |
---|
/**
* QuerySelector returns granted domain, or account or resources for caller.
*/
public interface QuerySelector extends Adapter {
...
/**
* List granted domains for the caller, given a specific entity type.
*
* @param caller account to check against.
* @param entityType entity type
* @param accessType access type
* @return list of domain Ids granted to the caller account.
*/
List<Long> getAuthorizedDomains(Account caller, String entityType, AccessType accessType);
/**
* List granted accounts for the caller, given a specific entity type.
*
* @param caller account to check against.
* @param entityType entity type
* @param accessType access type
* @return list of account Ids granted to the caller account.
*/
List<Long> getAuthorizedAccounts(Account caller, String entityType, AccessType accessType);
/**
* List granted resources for the caller, given a specific entity type.
*
* @param caller account to check against.
* @param entityType entity type
* @param accessType access type
* @return list of resource Ids granted to the caller account.
*/
List<Long> getAuthorizedResources(Account caller, String entityType, AccessType accessType);
/**
* Check if this account is associated with a policy with scope of ALL
* @param caller account to check
* @param action action.
* @param accessType access type
* @return true if this account is attached with a policy for the given action of ALL scope.
*/
boolean isGrantedAll(Account caller, String action, AccessType accessType);
/**
* List of IAM group the given account belongs to
* @param accountId account id.
* @return IAM group names
*/
List<String> listIAMGroupsByAccount(long accountId); |
By invoking these QuerySelector APIs, CloudStack API engine can pre-construct proper SQL where clause to achieve proper row filter for accessibility control.
IAM feature will be making use of CloudStack's plugin framework and will be implemented as a separate plugin. The end goal is to be able to host the IAM server as an independent service listening at an endpoint which the CS API service calls to do access checks.
IAM plugin will be developed under cloudstack-services project so that in future it can be easily separated as a service.
Following is the code base structure for the IAM feature:
cloud-iam service will be having two parts:
...
Following component diagram illustrates these boundaries:
Gliffy Diagram | ||
---|---|---|
|
Currently CloudStack provides different response views for Root admin and non-root user, some response fields are only visible to root admin. Basically we have provided two static response views (Full view and Restricted view), domain admin will also have a User view. With new IAM service introduced, we should ideally also allow customers to be able to specify what view should be applied to each API when they are granting each API action to an IAM policy. To achieve that, we will implement as follows:
We will separate all current both admin and user allowed API commands to two classes: API for admin and API for user. For example, previous ListVMsCmd will be splitted into two classes: ListVMsCmdByAdmin and ListVMsCmd.
Code Block |
---|
@APICommand(name = "listVirtualMachines", description = "List the virtual machines owned by the account.", responseObject = UserVmResponse.class, responseView = ResponseView.Restricted, entityType = { IAMEntityType.VirtualMachine }) public class ListVMsCmd extends BaseListTaggedResourcesCmd { ...... } @APICommand(name = "listVirtualMachines", description = "List the virtual machines owned by the account.", responseObject = UserVmResponse.class, responseView = ResponseView.Full) public class ListVMsCmdByAdmin extends ListVMsCmd { ///////////////////////////////////////////////////// //////////////// API parameters ///////////////////// ///////////////////////////////////////////////////// @Parameter(name=ApiConstants.HOST_ID, type=CommandType.UUID, entityType=HostResponse.class, description="the host ID") private Long hostId; @Parameter(name=ApiConstants.POD_ID, type=CommandType.UUID, entityType=PodResponse.class, description="the pod ID") private Long podId; @Parameter(name=ApiConstants.STORAGE_ID, type=CommandType.UUID, entityType=StoragePoolResponse.class, |
...
|
...
|
...
|
...
|
...
|
...
description="the storage ID where |
...
vm's volumes belong to") private Long storageId; } |
Note that ListVMsCmdByAdmin and ListVMsCmd are sharing the same API name "listVirtualMachines". From client perspective, this is transparent to them, CloudStack API client will still just invoke previous listVirtualMachine API, and CloudStack API server will internally consult with IAM plugin to determine the group associated with the invoking user and then determine which internal Cmd class to be invoked. There is a new attribute "responseView" introduced for @APICommand annoation, which can be used to instruct CloudStack to generate different response view. By separating the command class into admin cmd class and user cmd class, we can also restrict valid input parameters for different account. For example, in this case, when Admin invokes listVirtualMachine api, he/she can pass hostId, podId and storageId, which parameters are not applicable for end user.
For backward compatibility, out-of-box, we provided 3 default policies: Root admin policy, domain admin policy, and end user policy. The process to populate permissions for these default policies are as follows:
When user creates a customized policy, he can specify a source policy from list of default policies. Then we will create new mapping between these default policy permission entries and the new policy in iam_policy_permission_map table.
account
id | account_name | uuid | domain_id |
---|---|---|---|
2 | admin | 1c5afd64-482b-11e3-86f3-8118f47f9f9f | 1 |
3 | domainAdmin | 929d172c-b95e-4b86-9474-9789072c9bdb | 2 |
4 | domainUserA | f96ddb47-d3c0-4360-a9cd-613d631c8333 | 2 |
iam_group
id | name | description | uuid | path | removed | created |
---|---|---|---|---|---|---|
1 | REGULAR_USER | Domain user group | d283d4f0-31f0-11e3-ad37-80f85ce25918 | / | NULL | 2013-10-10 14:13:34 |
2 | ADMIN | Root admin group | d283de28-31f0-11e3-ad37-80f85ce25918 | / | NULL | 2013-10-10 14:13:34 |
3 | DOMAIN_ADMIN | Domain admin group | d283e6e8-31f0-11e3-ad37-80f85ce25918 | / | NULL | 2013-10-10 14:13:34 |
iam_group_account_map
id | group_id | account_id | removed | created |
---|---|---|---|---|
2 | 2 | 2 | NULL | 2013-10-10 14:13:34 |
3 | 3 | 3 | NULL | 2013-10-11 00:14:54 |
4 | 1 | 4 | NULL | 2013-10-11 00:19:55 |
iam_policy
id | name | description | uuid | path | removed | created | policy_type |
---|---|---|---|---|---|---|---|
1 | REGULAR_USER | Domain user role | d2838dce-31f0-11e3-ad37-80f85ce25918 | / | NULL | 2013-10-10 14:13:34 | Static |
2 | ADMIN | Root admin role | d2839c56-31f0-11e3-ad37-80f85ce25918 | / | NULL | 2013-10-10 14:13:34 | Static |
3 | DOMAIN_ADMIN | Domain admin role | d283a7f0-31f0-11e3-ad37-80f85ce25918 | / | NULL | 2013-10-10 14:13:34 | Static |
iam_group_policy_map
id | group_id | policy_id | removed | created |
---|---|---|---|---|
1 | 1 | 1 | NULL | 2013-10-10 14:13:34 |
2 | 2 | 2 | NULL | 2013-10-10 14:13:34 |
3 | 3 | 3 | NULL | 2013-10-10 14:13:34 |
iam_permission
id | action | resource_type | scope_id | scope | access_type | permission | removed | created |
---|---|---|---|---|---|---|---|---|
1 | startVirtualMachine | VirtualMachine | NULL | ALL | NULL | Allow | NULL | 2013-10-10 14:13:34 |
2 | startVirtualMachine | VirtualMachine | $domainId | Domain | NULL | Allow | NULL | 2013-10-10 14:13:34 |
3 | startVirtualMachine | VirtualMachine | $accountId | Account | NULL | Allow | NULL | 2013-10-10 14:13:34 |
iam_policy_permission_map
id | policy_id | permission_id | removed | created |
---|---|---|---|---|
1 | 1 | 3 | NULL | 2013-10-10 14:13:34 |
2 | 2 | 1 | NULL | 2013-10-10 14:13:34 |
3 | 3 | 2 | NULL | 2013-10-10 14:13:34 |
Lets consider the StartVM API is being called by a user and run through the access control usecase for each default policy.
The StartVMCmd will contain an annotation on the field that needs to be checked for access:
Code Block |
---|
| 1c5afd64-482b-11e3-86f3-8118f47f9f9f | 1 | | 3 | domainAdmin | 929d172c-b95e-4b86-9474-9789072c9bdb | 2 | | 4 | domainUserA | f96ddb47-d3c0-4360-a9cd-613d631c8333 | 2 | *acl_group* || id || name || description || uuid || domain_id || removed || created | | 1 | REGULAR_USER | Domain user group | d283d4f0-31f0-11e3-ad37-80f85ce25918 | 1 | NULL | 2013-10-10 14:13:34 | | 2 | ADMIN | Root admin group | d283de28-31f0-11e3-ad37-80f85ce25918 | 1 | NULL | 2013-10-10 14:13:34 | | 3 | DOMAIN_ADMIN | Domain admin group | d283e6e8-31f0-11e3-ad37-80f85ce25918 | 1 | NULL | 2013-10-10 14:13:34 | *acl_group_account_map* || id || group_id || account_id || removed || created || | 2 | 2 | 2 | NULL | 2013-10-10 14:13:34 | | 3 | 3 | 3 | NULL | 2013-10-11 00:14:54 | | 4 | 1 | 4 | NULL | 2013-10-11 00:19:55 | *acl_policy* || id || name || description || uuid || domain_id || removed || created || policy_type || | 1 | REGULAR_USER | Domain user role | d2838dce-31f0-11e3-ad37-80f85ce25918 | 1 | NULL | 2013-10-10 14:13:34 | Static | | 2 | ADMIN | Root admin role | d2839c56-31f0-11e3-ad37-80f85ce25918 | 1 | NULL | 2013-10-10 14:13:34 | Static | | 3 | DOMAIN_ADMIN | Domain admin role | d283a7f0-31f0-11e3-ad37-80f85ce25918 | 1 | NULL | 2013-10-10 14:13:34 | Static | | 6 | RESOURCE_OWNER | Resource owner role | d283c794-31f0-11e3-ad37-80f85ce25918 | 1 | NULL | 2013-10-10 14:13:34 | Dynamic | *acl_group_policy_map* || id || group_id || policy_id || removed || created || | 1 | 1 | 1 | NULL | 2013-10-10 14:13:34 | | 2 | 2 | 2 | NULL | 2013-10-10 14:13:34 | | 3 | 3 | 3 | NULL | 2013-10-10 14:13:34 | h3. Sample DB entries for the policy permissions for 'StartVM' operation: *acl_permission* || id || action || resource_type || scope_id || scope || access_type || permission || removed || created || | 1 | startVirtualMachine| VirtualMachine | NULL | ALL | NULL | Allow | NULL | 2013-10-10 14:13:34 | | 2 | startVirtualMachine| VirtualMachine | $domainId| Domain | NULL | Allow | NULL | 2013-10-10 14:13:34 | | 3 | startVirtualMachine| VirtualMachine | $accountId | Account| NULL | Allow | NULL | 2013-10-10 14:13:34 | *acl_policy_permission_map* || id || policy_id || permission_id || removed || created || | 1 | 6 | 3 | NULL | 2013-10-10 14:13:34 | | 2 | 2 | 1 | NULL | 2013-10-10 14:13:34 | | 3 | 3 | 2 | NULL | 2013-10-10 14:13:34 | h3. Access Check Flow Lets consider the StartVM API is being called by a user and run through the access control usecases for various out-of-box policies. The StartVMCmd will contain an annotation on the field that needs to be checked for access: {code} @APICommand(name = "startVirtualMachine", responseObject = UserVmResponse.class, description = "Starts a virtual machine.", entityType = { IAMEntityType.VirtualMachine }) public class StartVMCmd extends BaseAsyncCmd { public static final Logger s_logger = Logger.getLogger(StartVMCmd.class.getName()); private static final String s_name = "startvirtualmachineresponse"; // /////////////////////////////////////////////////// // ////////////// API parameters ///////////////////// // ////////////////////////////////////////////////////////////////////// *@ACL(action="startVirtualMachine")* @Parameter(name = ApiConstants.ID, type = CommandType.UUID, entityType=UserVmResponse.class, required = true, description = "The ID of the virtual machine") private Long id; {code} Thus following will happen if the above regular user 'domainUserA' calls this command: * API access check: # The API layer will call the APICheckers to see if the user is allowed to invoke this API # The PolicyBasedAccessChecker :: checkAccess(user, apiName) will check following: - Find all groups the user belongs too: groupIDs = {1} - Find all 'Effective' policies the groups are associated to: policies = {1, 6} - If any policy 'Allows' the API, grant permission to make this call: Policy Id 6 and Permission Id 3 allow the API to be invoked for this user. /// @ACL @Parameter(name = ApiConstants.ID, type = CommandType.UUID, entityType=UserVmResponse.class, required = true, description = "The ID of the virtual machine") private Long id; |
Regular user 'domainUserA' calls this command for his own VM:
API access check
The API layer will call the APICheckers to see if the user is allowed to invoke this API. The PolicyBasedAccessChecker :: checkAccess(user, apiName) will just return true and rely on next step
Entity Access Check
The @ACL annotation invokes the SecurityChecker implementation. The PolicyBasedAccessChecker:: checkAccess(Account caller, ControlledEntity entity, AccessType accessType, String action) is invoked for the given user account and VM Id for action 'startVirtualMachine'
A Domain Admin 'domainAdmin' calls this command for a VM in his domain:
Entity Access Check
A Root Admin 'admin' calls this command for any VM:
Entity Access Check
Consider following example:
A Domain admin wants to create a 'Service Desk' group for his domain and allow 'ready only' access to the group for all VMs and Volumes within the Domain.
Steps:
NOTE:
For this release, creating a custom policy/group is supported through API only. For further releases, we can provide either a UI or a config file + policy language mechanism to facilitate the custom policy/group creation.