Hi Koushik,
See my answers in line.
Thanks.
-min
On 1/22/14 12:30 AM, "Koushik Das" <koushik....@citrix.com> wrote:
>Some questions:
>
>- Is there a concept of generic permission (any action, any resource
>etc.)? There shouldn't be a need to define hundreds of explicit
>permissions for admin account.
[Min] Out of box we will automatically create default policies for
existing cloud admin, domain admin and normal user, to map to current
account type. Root admin policy has defined generic permission you
mentioned here.
>- I think it would be good to have a notion of parent policy. This will
>avoid duplication of permissions.
[Min] CreateAclPolicyCmd api has parent policy id in the parameter, when
you create a policy, you can specify a parent policy id. Internally we
will copy parent policy permissions to the new policy. We don't want to
create link to parent policy, since this will couple them together to
avoid user from editing permission in only one policy not the other.
>- Can you explain the permission evaluation order? What if one permission
>is allow and another is deny for a given resource, which is given
>priority and where the evaluation ends? Also what is logic to select
>permissions from different policies for a given request (start VM for
>account id 11 (belonging to domain id 1))? For e.g. if the permissions
>are defined like
>
>1|start|VirtualMachine|NULL|ALL|NULL|Allow|NULL|2013-10-10 14:13:34
>2|any|VirtualMachine|domain id = 1|Domain|NULL|Deny|NULL|2013-10-10
>14:13:34
>3|start|VirtualMachine|account id = 11|Account|NULL|Deny|NULL|2013-10-10
>14:13:34
>4|start,stop|VirtualMachine|account id =
>12|Account|NULL|Allow|NULL|2013-10-10 14:13:34
>5|any|any|NULL|ALL|NULL|Allow|NULL|2013-10-10 14:13:34
[Min] For phase 1, our scope is to support only explicit allow permission,
explicit deny will be added in next phase. The evaluation logic will be
the same as AWS IAM evaluation engine. See
http://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_Evalua
tionLogic.html for details.
>
>
>Thanks,
>Koushik
>
>On 22-Jan-2014, at 3:27 AM, Prachi Damle
><prachi.da...@citrix.com<mailto:prachi.da...@citrix.com>> wrote:
>
>Min and myself would like to propose an identity and access management
>plugin for CloudStack for the ACS 4.4 release.
>
>Here is the functional spec we have drafted for the first phase:
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Identity
>+and+Access+Management+%28IAM%29+Plugin
>
>Currently CloudStack provides very limited IAM services and there are
>several drawbacks:
>
>- Offers few roles out of the box (user and admin) with prebaked access
>control. There is no way to create customized policies and permissions.
>- Some resources have access control baked into them. E.g., shared
>networks, projects etc.
>- We have to create special dedicateXXX APIs to grant permissions to
>resources.
>- Also it does not provide the flexibility to integrate with other RBAC
>implementations say using AD/LDAP
>
>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 based on the standard IAM terminologies. Also we
>need to create an access check mechanism to be used by the API layer to
>avoid the checks scattered over the api/service layer. The read/listing
>APIs need to be refactored accordingly to consider the policy based
>access granting.
>
>Please provide feedback/suggestions anyone has.
>
>Thanks,
>Prachi & Min
>
