Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D804610BE5 for ; Fri, 31 Jan 2014 16:35:54 +0000 (UTC) Received: (qmail 77862 invoked by uid 500); 31 Jan 2014 16:35:53 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 77764 invoked by uid 500); 31 Jan 2014 16:35:53 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 77756 invoked by uid 99); 31 Jan 2014 16:35:52 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 31 Jan 2014 16:35:52 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of AOpgenoort@schubergphilis.com designates 195.66.90.41 as permitted sender) Received: from [195.66.90.41] (HELO sbppmx2.schubergphilis.com) (195.66.90.41) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 31 Jan 2014 16:35:45 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by sbppmx2.schubergphilis.com (Postfix) with ESMTP id 24CC712C43 for ; Fri, 31 Jan 2014 17:35:25 +0100 (MET) X-Virus-Scanned: amavisd-new at schubergphilis.com Received: from sbppmx2.schubergphilis.com ([127.0.0.1]) by localhost (sbppmx2.schubergphilis.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaKvmclrbYI3 for ; Fri, 31 Jan 2014 17:35:25 +0100 (MET) Received: from SBPOTMG101.sbp.lan (edge.schubergphilis.com [195.66.90.11]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by sbppmx2.schubergphilis.com (Postfix) with ESMTP id 1721712B1C for ; Fri, 31 Jan 2014 17:35:25 +0100 (MET) Received: from SBPOMF102.sbp.lan (10.71.2.131) by SBPOTMG101.sbp.lan (10.71.3.100) with Microsoft SMTP Server (TLS) id 14.1.379.0; Fri, 31 Jan 2014 17:35:24 +0100 Received: from SBPOMB401.sbp.lan ([fe80::2163:a5b:1dc1:9f]) by SBPOMF102.sbp.lan ([fe80::9049:fc5b:72ee:dd7%15]) with mapi id 14.02.0318.001; Fri, 31 Jan 2014 17:35:24 +0100 From: Anton Opgenoort To: dev Subject: RE: [DISCUSS] api level access controll Thread-Topic: [DISCUSS] api level access controll Thread-Index: AQHPHnPa5XThAViFNkiZ/+ynBZd2VpqenTUAgAAJeoCAAAJRgIAAXEYg Date: Fri, 31 Jan 2014 16:35:24 +0000 Message-ID: <314BD465B842694DAABB76D807739AA15D75D927@SBPOMB401.sbp.lan> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.71.96.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org +1 voted. Example use case: Our customer portal should actually be able to do a 'list= clusters showcapacities=3Dtrue', to inform our customers on their privately= owned private zones, which are controlled by our CloudStack environment.=20 At this stage, I can only give a root-level API/Secret key combination to o= ur customer portal team, but all they need to do now, is to list some hardw= are usage, create some domains, accounts and users. But with this api key, = they get the keys to the kingdom, without needing it.=20 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 dif= ferent levels, but also 'manage users' at the same time. Both profiles woul= d allow reading and managing of different resources within cloudstack. Ther= efore any 'user' in cloudstack has a 1:N relationship with the roles, and e= ach role has a 1:N relation with the resources, and/or API capabilities.=20 Regards, Anton Opgenoort +31624864156 -----Original Message----- From: Daan Hoogland [mailto:daan.hoogland@gmail.com]=20 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 whic= h 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 wrote: > Agreed - I believe the IAM proposal that went out recently may have cover= ed this topic a little too. > > Is it something to bake into the API layer or better/cleaner to build som= e proxy layer that handles permissions? > > > > Alex Hitchins > +44 7788 423 969 > > -----Original Message----- > From: Erik Weber [mailto:terbolous@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 = wrote: > >> H, >> >> I git a question of an operator ad Schuberg Philis to crete a set of=20 >> api keys and to have control over excatly what api calls are allowed=20 >> 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=20 >> to do it? >> >> > > Having more flexibility with access control is something that I and the c= ompany I work for appreciate. > I can also see several use cases for this, monitoring user that should on= ly be able to list stuff (but all stuff) et cetera. > > -- > Erik Weber > Need Enterprise Grade Support for Apache CloudStack? > Our CloudStack Infrastructure Support offers the best 24/7 SLA for CloudStack Environments. > > Apache CloudStack Bootcamp training courses > > **NEW!** CloudStack 4.2.1=20 > training > 18th-19th February 2014, Brazil.=20 > Classroom > 17th-23rd March 2014, Region A. Instructor led,=20 > On-line > 24th-28th March 2014, Region B. Instructor led,=20 > On-line > 16th-20th June 2014, Region A. Instructor led,=20 > On-line > 23rd-27th June 2014, Region B. Instructor led,=20 > On-line > > 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 r= epresent those of Shape Blue Ltd or related companies. If you are not the i= ntended recipient of this email, you must neither take any action based upo= n 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 com= pany incorporated in England & Wales. ShapeBlue Services India LLP is a com= pany incorporated in India and is operated under license from Shape Blue Lt= d. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil a= nd is operated under license from Shape Blue Ltd. ShapeBlue is a registered= trademark.