-----Original Message-----
From: Chiradeep Vittal [mailto:[email protected]]
Sent: Tuesday, January 21, 2014 4:27 PM
To: [email protected]
Subject: Re: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920)
Also not clear on how the dedicateXyZ problem is being solved in Phase1 (or
not).
>>[Prachi] Yes, the dedicate APIs is not yet included
Can I (end user) create a VPC and allow user Bob to create VMs in my VPC?
>>[Prachi] So looks like for current CS VPC, there is no access checks done on
>>the VPC entry itself - the access checks are all the individual networks of
>>the VPC tiers.
So if user A grants access to the network n1 in the VPC to another user B -
then user B can invoke deployVM API using this networkId.
To do this user A has to:
- Create a policy with 'Allow' permission to this networkId (scope: Resource,
scopeId: n1, resourceType: Network) for 'listNetworks' action/ 'use' access
- Attach this policy to a group and add account to that group.
For phase1 we are still thinking if the IAM APIs (creation of
group/policies/granting) should be root admin only to restrict the scope of the
feature.
But the model does support granting at three levels and will support such use
cases:
- 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.
Prachi
On 1/21/14 4:20 PM, "Chiradeep Vittal" <[email protected]> wrote:
>SAML 2.0 is not precluded with this design, it seems.
>I found the FS both confusing and illuminating. I think what confuses
>me is the interchange of 'acl', 'iam' and 'policy'.
>Especially since ACL is used in the networking context.
>
>IMO, renaming the tables and APIs to not use ACL but IAM would clarify
>matters.
>For example:
>Tables: iam_policy, iam_policy_permission, iam_group
>API: createIAMGroup createIAMPolicy createIAMPermission
>addIAMPermissionToAclPolicy attachPolicyToIAMGroup addAccountToIAMGroup
>(or better, house the api under the client/iam/?command= sub-url)
>Annotation: @IamPolicyCheck
>
>Also, there is no reference to what one would normally find in an IAM
>user
>guide: Principal, Role, etc.
>Am I right in assuming that Account is the Principal here? Are there
>roles, or even a default role?
>
>What is envisioned for Phase 2, 3Š
>
>Ideally, this is a separate service that can be enhanced by 3rd parties.
>As an example, I want to provide my DBaaS service on an ACS-powered cloud.
>I want to utilize the same Principals (and IAM infrastructure) rather
>than provide my own.
>
>--
>Chiradeep
>
>
>
>On 1/21/14 2:01 PM, "Erik Weber" <[email protected]> wrote:
>
>>On Tue, Jan 21, 2014 at 10:57 PM, Prachi Damle
>><[email protected]>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+Ide
>>>nti
>>>t
>>>y+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.
>>>
>>>
>>
>>Would love to see SAML 2.0 support, but any IAM solution is a good
>>start
>>:-)
>>
>>--
>>Erik Weber
>
