-----Original Message----- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Tuesday, January 21, 2014 4:27 PM To: dev@cloudstack.apache.org 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" <chiradeep.vit...@citrix.com> 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" <terbol...@gmail.com> wrote: > >>On Tue, Jan 21, 2014 at 10:57 PM, Prachi Damle >><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+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 >