Hi Anton and Dan, Yes these usecases can be satisfied with the IAM feature being developed (CLOUDSTACK-5920)
Anton, For the customer care portal case - the steps will be to create a custom policy and choose the specifc APIs the accounts/group of accounts having this policy can invoke. For read access, it is possible to grant the read-only API access to the list* APIs needed. Dan, Same will apply to the api permissions but at an account level instead of individual keys- with CS it is not possible to define the access control at a CloudStack User (apikey) level. All the access control is defined at an Account level. Given this, you can specify the APIs an account has permissions to invoke - these permisssions then apply to all the keys under that account. Thus you can create a set of accounts(group) and have control over what APIs this group can invoke. The ticket is the parent ticket for the whole feature that will get updated later, but most of the development is currently being done in the 'rbac' branch. As Chiradeep pointed out, the FS on wiki should provide more details. Thanks, Prachi -----Original Message----- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, February 03, 2014 10:48 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] api level access controll Have you seen this. https://cwiki.apache.org/confluence/x/ypkTAg There was a recent thread on this ML as well. On 1/31/14 8:35 AM, "Anton Opgenoort" <aopgeno...@schubergphilis.com> wrote: >+1 voted. > >Example use case: Our customer portal should actually be able to do a >'listclusters showcapacities=true', to inform our customers on their >privately owned private zones, which are controlled by our CloudStack >environment. >At this stage, I can only give a root-level API/Secret key combination >to our customer portal team, but all they need to do now, is to list >some hardware usage, create some domains, accounts and users. But with >this api key, they get the keys to the kingdom, without needing it. > >We thus want to break up the keys to the kingdom in a flexible way, >meaning via RBAC. A role the customer portal can play is to 'list >capacity' at different levels, but also 'manage users' at the same time. >Both profiles would allow reading and managing of different resources >within cloudstack. Therefore any 'user' in cloudstack has a 1:N >relationship with the roles, and each role has a 1:N relation with the >resources, and/or API capabilities. > >Regards, > >Anton Opgenoort +31624864156 > >-----Original Message----- >From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] >Sent: Friday, January 31, 2014 12:55 PM >To: dev >Subject: Re: [DISCUSS] api level access controll > >tehre is a ticket CLOUDSTACK-5920 > >not much activity on it yet. It does however mention the buzzword rbac >which would point in the direction of Eriks whishes and our own. > >vote vote vote please > >On Fri, Jan 31, 2014 at 12:47 PM, Alex Hitchins ><alex.hitch...@shapeblue.com> wrote: >> Agreed - I believe the IAM proposal that went out recently may have >>covered this topic a little too. >> >> Is it something to bake into the API layer or better/cleaner to build >>some proxy layer that handles permissions? >> >> >> >> Alex Hitchins >> +44 7788 423 969 >> >> -----Original Message----- >> From: Erik Weber [mailto:terbol...@gmail.com] >> Sent: 31 January 2014 11:13 >> To: dev@cloudstack.apache.org >> Subject: Re: [DISCUSS] api level access controll >> >> On Fri, Jan 31, 2014 at 12:00 PM, Daan Hoogland >><daan.hoogl...@gmail.com>wrote: >> >>> H, >>> >>> I git a question of an operator ad Schuberg Philis to crete a set of >>> api keys and to have control over excatly what api calls are allowed >>> for this set of keys. Does anybody else recognise this use case? >>> already hacked it in? have an idea how to do it? has a reason why >>> not to do it? >>> >>> >> >> Having more flexibility with access control is something that I and >>the company I work for appreciate. >> I can also see several use cases for this, monitoring user that >>should only be able to list stuff (but all stuff) et cetera. >> >> -- >> Erik Weber >> Need Enterprise Grade Support for Apache CloudStack? >> Our CloudStack Infrastructure >>Support<http://shapeblue.com/cloudstack-infrastructure-support/> >>offers the best 24/7 SLA for CloudStack Environments. >> >> Apache CloudStack Bootcamp training courses >> >> **NEW!** CloudStack 4.2.1 >> training<http://shapeblue.com/cloudstack-training/> >> 18th-19th February 2014, Brazil. >> Classroom<http://shapeblue.com/cloudstack-training/> >> 17th-23rd March 2014, Region A. Instructor led, >> On-line<http://shapeblue.com/cloudstack-training/> >> 24th-28th March 2014, Region B. Instructor led, >> On-line<http://shapeblue.com/cloudstack-training/> >> 16th-20th June 2014, Region A. Instructor led, >> On-line<http://shapeblue.com/cloudstack-training/> >> 23rd-27th June 2014, Region B. Instructor led, >> On-line<http://shapeblue.com/cloudstack-training/> >> >> This email and any attachments to it may be confidential and are >>intended solely for the use of the individual to whom it is addressed. >>Any views or opinions expressed are solely those of the author and do >>not necessarily represent those of Shape Blue Ltd or related companies. >>If you are not the intended recipient of this email, you must neither >>take any action based upon its contents, nor copy or show it to anyone. >>Please contact the sender if you believe you have received this email >>in error. Shape Blue Ltd is a company incorporated in England & Wales. >>ShapeBlue Services India LLP is a company incorporated in India and is >>operated under license from Shape Blue Ltd. Shape Blue Brasil >>Consultoria Ltda is a company incorporated in Brasil and is operated >>under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
