Open Stack

Hi,

Le 23/05/2016 18:23, Sean Dague a écrit :
> On 05/23/2016 11:56 AM, Tim Bell wrote:
>> On 23/05/16 17:02, "Sean Dague" <sean at dague.net> wrote:
>>
>>> On 05/23/2016 10:24 AM, Tim Bell wrote:
>>>>  
>>>>
[...]
>>>> There can be security implications also so I’d recommend those using
>>>> this current v2 feature to review the bug to understand the potential
>>>> impacts as clouds enable v2.1.
>>>
>>> While I understand from the bug report what your use case is now, I'm
>>> kind of wondering what the shared resources / actions of these 150
>>> people are in this project. Are they all in the same project for other
>>> reasons?
>>
>> The resource pool (i.e. quota) is shared between all of the developers.
>> A smaller team is responsible for maintaining the image set for the project
>> and also providing 2nd line support (such as reboot/problem diagnosis…).
> 
> Ok, so Bob can take up all the instances and go on vacation, and it's a
> 2nd line support call to handle shutting them down? It definitely
> creates some weird situations where you can all pull from the pool, and
> once pulled only you can give back.
> 
> What's the current policy patch look like? (i.e. which operations are
> you changing to user_id).
> 
>> I do not know the EMBL-EBI use case or the EGI Federated Cloud scenarios
>> which are also mentioned in the review.

The EGI Federated Cloud scenarios is almost the same. We have tenants
for several projects and a "catch-all" tenant for small projects (1 or 2
person per project). Therefore, it is important to be sure that a user
from one project does not interact with VMs from another one.

You may find the patch that we are using here:
- Liberty: https://github.com/vin-c/cloud-security/tree/liberty/patch

> 
> Those would be good. I honestly think we need someone to start capturing
> these in a spec, because a huge part of the disconnect here was this was
> a backdoor feature that no one on the development side really understood
> existed, was never tested, and didn't think it was the way things were
> supposed to be working. And if we are bringing it back we really need to
> capture the use cases a lot more clearly so in 5 years we don't do the
> same thing again.
> 
> 	-Sean
> 

Jerome

-- 
Jerome Pansanel
Technical Director at France Grilles
Grid & Cloud Computing Operations Manager at IPHC
IPHC                        ||  GSM: +33 (0)6 25 19 24 43
23 rue du Loess, BP 28      ||  Tel: +33 (0)3 88 10 66 24
F-67037 STRASBOURG Cedex 2  ||  Fax: +33 (0)3 88 10 62 34