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" <[email protected]> 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 _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
