Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Code Block
/**
* 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;

....
}

/**
* Enumeration type for AccessType
*/
public enum AccessType {
	ModifyProject,
    OperateEntry,
    UseEntry
}
AccessType
  • Until 4.4, CloudStack did not distinguish between a read-only access Vs read-and-use access Vs operate access. 
  • CloudStack access control layer always checked if the caller is owner of the entity and granted all types of access based on that. 
  • With IAM feature following are the types of entity access one can specify:
    1. ListEntry  (read only access)
    2. UseEntry  (read and use access)
    3. OperateEntry (operate/execute access)

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:

...

  • If any policy has a permission attached that 'Allows' the API, grant permission to make this call
  • Else, if no Allow entry is found for any policy for this API, deny the permission
What is 'recursive = true' permission?
  • This flag indicates a permission to an entity which is accessible in a group hierarchy downwards upto the 'leaf' group. The hierarchy is defined using the 'path' property of the group.
  • This design is used to map the 'domain' hierarchy of CloudStack and facilitate access check for entities that span the domain tree like Network, AffinityGroup.
  • This property 'recursive' is not exposed in IAM APIs, but only used by CloudStack orchestration when such domain-wide resources are created in the system through normal CS APIs.

...