-----Original Message-----
From: Min Chen [mailto:min.c...@citrix.com]
Sent: Wednesday, January 22, 2014 10:16 AM
To: dev@cloudstack.apache.org
Subject: Re: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920)
Hi Rajani,
See my answers in line.
Thanks
On 1/22/14 6:29 AM, "Rajani Karuturi" <rajani.karut...@citrix.com> wrote:
>some questions I have:
>1. Do we need groups and policies? Cant we derive group information
>from policy applied? ie) any user can become domain admin if he is
>given the right policies.
[Min] Yes, Group and Policy are standard IAM concepts used to perform access
control which community all understand, it is better for us to follow the
common standard avoid confusion for adoption. With group and policy,
administrator can easily manipulate access controls in his/her organization. If
there is no group, to assign permissions to a bunch of principals (in our case,
accounts), admin has to assign group of policies to each principal one by one,
which is tedious and error-prone.
>2. Can we restrict the permission to Resource Type's CRUD? permissions
>at api level seems to be like too much of control and information to save.
[Min] We thought of this before. But this involves a big effort for us to
category each of our 300 API to classify which CRUD operation is involved in
the api and on which resource type. That is not an easy refactor effort. In
phase 2, we may consider figuring out a way to categorize APIs to that level.
[Prachi] Also two more reasons to go with API names than a broader category:
- It is better to follow AWS IAM design as much as possible for AWS fidelity,
just as Sebastien has already pointed out. AWS IAM works with API names instead
of categorization
- We need to store permissions per API per group/policy anyway analogous to
current commands.properties.
And maintaining it in two different sets (api permissions + permissions for
entity access per broader category) can make it tricky when we need to create
custom policies.
>
>
>-
>Thanks,
>Rajani
>________________________________________
>From: Prachi Damle [prachi.da...@citrix.com]
>Sent: Wednesday, January 22, 2014 3:27 AM
>To: dev@cloudstack.apache.org
>Subject: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920)
>
>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+Ident
>ity
>+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
