Re: [Openstack-operators] Nova 2.1 and user permissions in the policy file

[Sean Dague]

On 05/23/2016 10:24 AM, Tim Bell wrote:
>  
> 
> Quick warning for those who are dependent on the "user_id:%(user_id)s"
> syntax for limiting actions by user. According to 
> https://bugs.launchpad.net/nova/+bug/1539351, this behavior was
> apparently not intended according to the bug report feedback. The
> behavior has changed from v2 to v2.1 and the old syntax no longer works.
> 
>  
> 
> 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.

Here is the proposed nova-spec on limited changes we're considering
bringing back in. The setup language is flowery, because I was in a
flowery mood yesterday. :)

Comments are welcomed there - https://review.openstack.org/#/c/324068/

-Sean

-- 
Sean Dague
http://dague.net

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Nova 2.1 and user permissions in the policy file

[Dario Vianello]

> On 27 May 2016, at 16:11, Sean Dague  wrote:
> 
> On 05/27/2016 04:23 AM, Dario Vianello wrote:
>> 
>>> On 25 May 2016, at 17:31, Tim Bell >> > wrote:
>>> 
>>> 
>>> On 25/05/16 17:36, "Sean Dague" >> > wrote:
>>> 
 On 05/23/2016 10:24 AM, Tim Bell wrote:
> 
> 
> Quick warning for those who are dependent on the "user_id:%(user_id)s"
> syntax for limiting actions by user. According to 
> https://bugs.launchpad.net/nova/+bug/1539351, this behavior was
> apparently not intended according to the bug report feedback. The
> behavior has changed from v2 to v2.1 and the old syntax no longer works.
> 
> 
> 
> 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.
 
 The Nova team is currently lacking information about the minimum number
 of user_id supporting policy points are needed. Because supporting
 user_id everywhere is definitely not going to be an option.
 
 We really need very detailed lists of which actions are required, and
 why. And for all server actions why "lock" action is not sufficient. And
 we need all of that by N1, which is in a week. With that we can evaluate
 what can be added to the API stack. Especially because this all needs
 tests so it doesn't regress. So if we can keep it at a small number of
 operations, it is way more likely to happen. If this grows to
 "everything", it definitely won't.
 
 It would honestly be great if people affected by this could also
 prioritize top to bottom what operations are most important. Detailed
 use case and priority is really needed to figure out what can be done.
 
>>> 
>>> Thanks for looking into this. The current set of activities that our
>>> developers want to do for their VMs (and do not want other doing to
>>> their instances ☺ are
>>> 
>>> - power off/power on/restart
>>> - VNC console (since this also allows the above with appropriate SysRq)
>>> - delete VM
>>> 
>>> I think in the longer term, we’ll can work together to find a way to
>>> do this with nested projects and some kind of automatic project
>>> creation but without nested quotas and image sharing in the hierarchy
>>> being priorities, these are not yet at functional parity compared to
>>> the current Nova V2 implementation.
>>> 
>>> Tim
>> 
>> Here at EMBL-EBI we are touched by this possible change in several ways:
>> - to properly federate our OpenStack to the EGI FedCloud, which requires
>> this feature. More on this coming, I hope somebody from the EGI will
>> post here soon.
>> - to support the same activities mentioned by Tim (power off/on/restart,
>> console, VM deletion) in our about-to-come dev platform
>> - to effectively support the long term of science scenario, where a
>> single tenancy is shared by different independent researches to do their
>> computation. 
>> 
>> I do agree that all this can be tackled by leveraging the nested
>> projects, but especially for the FedCloud we are committed to deliver
>> soon. Strip this feature out of Nova 2.1 would thus be an issue for us. 
> 
> Ok, but these are not the level of detail that we need to be actionable.
> We realistically need an ordered list of every policy rule changed in
> the importance of how that impacts things.
> 
> What is listed above is way too high level to understand any of that.
> From Tim we got a small list of actions, we can probably work with that.
> 
> And to be clear, this feature already doesn't exist in master as it went
> away in the default implementation 2 releases ago. We're talking about
> new feature development here, which is real work. And this feature will
> be marked as deprecated when should it go in, so other alternatives are
> going to need to be considered here.
> 
Hi Sean,

yep, I agree that what Tim listed is a good staring point (also for us). 



>   -Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Cheers,
Dario Vianello

Cloud Bioinformatics Application Architect
European Bioinformatics Institute (EMBL-EBI)
Wellcome Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK
Email: da...@ebi.ac.uk 

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Nova 2.1 and user permissions in the policy file

[Sean Dague]

On 05/27/2016 04:23 AM, Dario Vianello wrote:
> 
>> On 25 May 2016, at 17:31, Tim Bell > > wrote:
>>
>>
>> On 25/05/16 17:36, "Sean Dague" > > wrote:
>>
>>> On 05/23/2016 10:24 AM, Tim Bell wrote:


 Quick warning for those who are dependent on the "user_id:%(user_id)s"
 syntax for limiting actions by user. According to 
 https://bugs.launchpad.net/nova/+bug/1539351, this behavior was
 apparently not intended according to the bug report feedback. The
 behavior has changed from v2 to v2.1 and the old syntax no longer works.



 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.
>>>
>>> The Nova team is currently lacking information about the minimum number
>>> of user_id supporting policy points are needed. Because supporting
>>> user_id everywhere is definitely not going to be an option.
>>>
>>> We really need very detailed lists of which actions are required, and
>>> why. And for all server actions why "lock" action is not sufficient. And
>>> we need all of that by N1, which is in a week. With that we can evaluate
>>> what can be added to the API stack. Especially because this all needs
>>> tests so it doesn't regress. So if we can keep it at a small number of
>>> operations, it is way more likely to happen. If this grows to
>>> "everything", it definitely won't.
>>>
>>> It would honestly be great if people affected by this could also
>>> prioritize top to bottom what operations are most important. Detailed
>>> use case and priority is really needed to figure out what can be done.
>>>
>>
>> Thanks for looking into this. The current set of activities that our
>> developers want to do for their VMs (and do not want other doing to
>> their instances ☺ are
>>
>> - power off/power on/restart
>> - VNC console (since this also allows the above with appropriate SysRq)
>> - delete VM
>>
>> I think in the longer term, we’ll can work together to find a way to
>> do this with nested projects and some kind of automatic project
>> creation but without nested quotas and image sharing in the hierarchy
>> being priorities, these are not yet at functional parity compared to
>> the current Nova V2 implementation.
>>
>> Tim
> 
> Here at EMBL-EBI we are touched by this possible change in several ways:
> - to properly federate our OpenStack to the EGI FedCloud, which requires
> this feature. More on this coming, I hope somebody from the EGI will
> post here soon.
> - to support the same activities mentioned by Tim (power off/on/restart,
> console, VM deletion) in our about-to-come dev platform
> - to effectively support the long term of science scenario, where a
> single tenancy is shared by different independent researches to do their
> computation. 
> 
> I do agree that all this can be tackled by leveraging the nested
> projects, but especially for the FedCloud we are committed to deliver
> soon. Strip this feature out of Nova 2.1 would thus be an issue for us. 

Ok, but these are not the level of detail that we need to be actionable.
We realistically need an ordered list of every policy rule changed in
the importance of how that impacts things.

What is listed above is way too high level to understand any of that.
From Tim we got a small list of actions, we can probably work with that.

And to be clear, this feature already doesn't exist in master as it went
away in the default implementation 2 releases ago. We're talking about
new feature development here, which is real work. And this feature will
be marked as deprecated when should it go in, so other alternatives are
going to need to be considered here.

-Sean

-- 
Sean Dague
http://dague.net

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Nova 2.1 and user permissions in the policy file

[Dario Vianello]

> On 25 May 2016, at 17:31, Tim Bell  wrote:
> 
> 
> On 25/05/16 17:36, "Sean Dague" mailto:s...@dague.net>> 
> wrote:
> 
>> On 05/23/2016 10:24 AM, Tim Bell wrote:
>>> 
>>> 
>>> Quick warning for those who are dependent on the "user_id:%(user_id)s"
>>> syntax for limiting actions by user. According to 
>>> https://bugs.launchpad.net/nova/+bug/1539351, this behavior was
>>> apparently not intended according to the bug report feedback. The
>>> behavior has changed from v2 to v2.1 and the old syntax no longer works.
>>> 
>>> 
>>> 
>>> 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.
>> 
>> The Nova team is currently lacking information about the minimum number
>> of user_id supporting policy points are needed. Because supporting
>> user_id everywhere is definitely not going to be an option.
>> 
>> We really need very detailed lists of which actions are required, and
>> why. And for all server actions why "lock" action is not sufficient. And
>> we need all of that by N1, which is in a week. With that we can evaluate
>> what can be added to the API stack. Especially because this all needs
>> tests so it doesn't regress. So if we can keep it at a small number of
>> operations, it is way more likely to happen. If this grows to
>> "everything", it definitely won't.
>> 
>> It would honestly be great if people affected by this could also
>> prioritize top to bottom what operations are most important. Detailed
>> use case and priority is really needed to figure out what can be done.
>> 
> 
> Thanks for looking into this. The current set of activities that our 
> developers want to do for their VMs (and do not want other doing to their 
> instances ☺ are
> 
> - power off/power on/restart
> - VNC console (since this also allows the above with appropriate SysRq)
> - delete VM
> 
> I think in the longer term, we’ll can work together to find a way to do this 
> with nested projects and some kind of automatic project creation but without 
> nested quotas and image sharing in the hierarchy being priorities, these are 
> not yet at functional parity compared to the current Nova V2 implementation.
> 
> Tim

Here at EMBL-EBI we are touched by this possible change in several ways:
- to properly federate our OpenStack to the EGI FedCloud, which requires this 
feature. More on this coming, I hope somebody from the EGI will post here soon.
- to support the same activities mentioned by Tim (power off/on/restart, 
console, VM deletion) in our about-to-come dev platform
- to effectively support the long term of science scenario, where a single 
tenancy is shared by different independent researches to do their computation. 

I do agree that all this can be tackled by leveraging the nested projects, but 
especially for the FedCloud we are committed to deliver soon. Strip this 
feature out of Nova 2.1 would thus be an issue for us. 

Dario
> - 
>>  -Sean
>> 
>> -- 
>> Sean Dague
>> http://dague.net 
>> 
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org 
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
>> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
> 
Dario Vianello

Cloud Bioinformatics Application Architect
European Bioinformatics Institute (EMBL-EBI)
Wellcome Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK
Email: da...@ebi.ac.uk 

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Nova 2.1 and user permissions in the policy file

[Tim Bell]

On 25/05/16 17:36, "Sean Dague"  wrote:

>On 05/23/2016 10:24 AM, Tim Bell wrote:
>>  
>> 
>> Quick warning for those who are dependent on the "user_id:%(user_id)s"
>> syntax for limiting actions by user. According to 
>> https://bugs.launchpad.net/nova/+bug/1539351, this behavior was
>> apparently not intended according to the bug report feedback. The
>> behavior has changed from v2 to v2.1 and the old syntax no longer works.
>> 
>>  
>> 
>> 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.
>
>The Nova team is currently lacking information about the minimum number
>of user_id supporting policy points are needed. Because supporting
>user_id everywhere is definitely not going to be an option.
>
>We really need very detailed lists of which actions are required, and
>why. And for all server actions why "lock" action is not sufficient. And
>we need all of that by N1, which is in a week. With that we can evaluate
>what can be added to the API stack. Especially because this all needs
>tests so it doesn't regress. So if we can keep it at a small number of
>operations, it is way more likely to happen. If this grows to
>"everything", it definitely won't.
>
>It would honestly be great if people affected by this could also
>prioritize top to bottom what operations are most important. Detailed
>use case and priority is really needed to figure out what can be done.
>

Thanks for looking into this. The current set of activities that our developers 
want to do for their VMs (and do not want other doing to their instances ☺ are

- power off/power on/restart
- VNC console (since this also allows the above with appropriate SysRq)
- delete VM

I think in the longer term, we’ll can work together to find a way to do this 
with nested projects and some kind of automatic project creation but without 
nested quotas and image sharing in the hierarchy being priorities, these are 
not yet at functional parity compared to the current Nova V2 implementation.

Tim
- 
>   -Sean
>
>-- 
>Sean Dague
>http://dague.net
>
>___
>OpenStack-operators mailing list
>OpenStack-operators@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Nova 2.1 and user permissions in the policy file

[Sean Dague]

On 05/23/2016 10:24 AM, Tim Bell wrote:
>  
> 
> Quick warning for those who are dependent on the "user_id:%(user_id)s"
> syntax for limiting actions by user. According to 
> https://bugs.launchpad.net/nova/+bug/1539351, this behavior was
> apparently not intended according to the bug report feedback. The
> behavior has changed from v2 to v2.1 and the old syntax no longer works.
> 
>  
> 
> 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.

The Nova team is currently lacking information about the minimum number
of user_id supporting policy points are needed. Because supporting
user_id everywhere is definitely not going to be an option.

We really need very detailed lists of which actions are required, and
why. And for all server actions why "lock" action is not sufficient. And
we need all of that by N1, which is in a week. With that we can evaluate
what can be added to the API stack. Especially because this all needs
tests so it doesn't regress. So if we can keep it at a small number of
operations, it is way more likely to happen. If this grows to
"everything", it definitely won't.

It would honestly be great if people affected by this could also
prioritize top to bottom what operations are most important. Detailed
use case and priority is really needed to figure out what can be done.

-Sean

-- 
Sean Dague
http://dague.net

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Nova 2.1 and user permissions in the policy file

[Sean Dague]

On 05/23/2016 11:56 AM, Tim Bell wrote:
> On 23/05/16 17:02, "Sean Dague"  wrote:
> 
>> On 05/23/2016 10:24 AM, Tim Bell wrote:
>>>  
>>>
>>> Quick warning for those who are dependent on the "user_id:%(user_id)s"
>>> syntax for limiting actions by user. According to 
>>> https://bugs.launchpad.net/nova/+bug/1539351, this behavior was
>>> apparently not intended according to the bug report feedback. The
>>> behavior has changed from v2 to v2.1 and the old syntax no longer works.
>>
>> Well, the behavior changes with the backend code base. By mitaka the
>> default backend code for both is the same. And the legacy code base is
>> about to be removed.
>>
>> This feature (policy enforcement by user_id) was 100% untested, which is
>> why it never ended up in the new API stack. Being untested setting
>> owner: 'user_id: %(user_id)s' might have some really unexpected results
>> because not everything has a user_id.
>>
> 
> There are several hints given in the documentation regarding this sort of 
> feature. 
> 
> Examples are such as http://docs.openstack.org/developer/oslo.policy/api.html 
> and 
> http://docs.openstack.org/mitaka/config-reference/policy-json-file.html#examples

Ok, follow on question.

Is the concern that within a large tenant you do not want user A to
accidentally reboot user B's server? Would the "lock" construct be
sufficient here for users that have servers in critical states?

Are all the failure domains these kinds of failures? Or what is the
detailed list of bad interactions that you are concerned about.

-Sean

-- 
Sean Dague
http://dague.net

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Nova 2.1 and user permissions in the policy file

[Sean Dague]

On 05/24/2016 02:22 AM, Jerome Pansanel wrote:
> 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"  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.

Ok, but the catch-all project is just to have less "projects" allocated
in keystone right? Are these users using shared resources. I get there
is a convenience that no one is allocating projects... and this just
falls back to AD and people get in dynamically, but that seems like we
could solve project on demand differently.

I think part of the challenge here is that fundamentally project is
intended to be the unit of sharing. Because policy is so open ending
people did a bunch of things which effectively made nested projects,
which work in some cases, but might have some really odd edge conditions
based on what actions are enforced where. It also really breaks the
construct of

GET /servers

Being the list of servers you can do things to. Which... is a pretty
fundamental contract point in Nova. And confusing that point across
clouds makes it really hard for people to build software against the API
that your users can just use.

-Sean

-- 
Sean Dague
http://dague.net

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Nova 2.1 and user permissions in the policy file

[Jerome Pansanel]

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"  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
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Nova 2.1 and user permissions in the policy file

[Sean Dague]

On 05/23/2016 11:56 AM, Tim Bell wrote:
> On 23/05/16 17:02, "Sean Dague"  wrote:
> 
>> On 05/23/2016 10:24 AM, Tim Bell wrote:
>>>  
>>>
>>> Quick warning for those who are dependent on the "user_id:%(user_id)s"
>>> syntax for limiting actions by user. According to 
>>> https://bugs.launchpad.net/nova/+bug/1539351, this behavior was
>>> apparently not intended according to the bug report feedback. The
>>> behavior has changed from v2 to v2.1 and the old syntax no longer works.
>>
>> Well, the behavior changes with the backend code base. By mitaka the
>> default backend code for both is the same. And the legacy code base is
>> about to be removed.
>>
>> This feature (policy enforcement by user_id) was 100% untested, which is
>> why it never ended up in the new API stack. Being untested setting
>> owner: 'user_id: %(user_id)s' might have some really unexpected results
>> because not everything has a user_id.
>>
> 
> There are several hints given in the documentation regarding this sort of 
> feature. 
> 
> Examples are such as http://docs.openstack.org/developer/oslo.policy/api.html 
> and 
> http://docs.openstack.org/mitaka/config-reference/policy-json-file.html#examples

Ok, so those are good points of documentation to bring back in line with
whatever reality we feel is the one to land on. Keeping user_id support
in Nova policy is going to require someone to write a lot of tests to
verify it, because it's never been in the current stack, again, because
it was never really implemented, because there were never any tests for
this scenario anywhere.

>>> 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.

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

-- 
Sean Dague
http://dague.net

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Nova 2.1 and user permissions in the policy file

[Tim Bell]

On 23/05/16 17:02, "Sean Dague"  wrote:

>On 05/23/2016 10:24 AM, Tim Bell wrote:
>>  
>> 
>> Quick warning for those who are dependent on the "user_id:%(user_id)s"
>> syntax for limiting actions by user. According to 
>> https://bugs.launchpad.net/nova/+bug/1539351, this behavior was
>> apparently not intended according to the bug report feedback. The
>> behavior has changed from v2 to v2.1 and the old syntax no longer works.
>
>Well, the behavior changes with the backend code base. By mitaka the
>default backend code for both is the same. And the legacy code base is
>about to be removed.
>
>This feature (policy enforcement by user_id) was 100% untested, which is
>why it never ended up in the new API stack. Being untested setting
>owner: 'user_id: %(user_id)s' might have some really unexpected results
>because not everything has a user_id.
>

There are several hints given in the documentation regarding this sort of 
feature. 

Examples are such as http://docs.openstack.org/developer/oslo.policy/api.html 
and 
http://docs.openstack.org/mitaka/config-reference/policy-json-file.html#examples

>> 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…).

I do not know the EMBL-EBI use case or the EGI Federated Cloud scenarios
which are also mentioned in the review.

Tim

>
>   -Sean
>
>-- 
>Sean Dague
>http://dague.net
>
>___
>OpenStack-operators mailing list
>OpenStack-operators@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Nova 2.1 and user permissions in the policy file

[Adam Young]

On 05/23/2016 11:02 AM, Sean Dague wrote:

On 05/23/2016 10:24 AM, Tim Bell wrote:
  


Quick warning for those who are dependent on the "user_id:%(user_id)s"
syntax for limiting actions by user. According to
https://bugs.launchpad.net/nova/+bug/1539351, this behavior was
apparently not intended according to the bug report feedback. The
behavior has changed from v2 to v2.1 and the old syntax no longer works.

v2 to v2.1 of what?


Well, the behavior changes with the backend code base. By mitaka the
default backend code for both is the same. And the legacy code base is
about to be removed.

This feature (policy enforcement by user_id) was 100% untested, which is
why it never ended up in the new API stack. Being untested setting
owner: 'user_id: %(user_id)s' might have some really unexpected results
because not everything has a user_id.


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?


My sediments exactly.  In cloud, you should never be looking at a user 
id for policy.  It should be possible to always have more than one user 
perform an action, and enforce policy on the project_id.


The one exception for this is Barbican managing cryptographic secrets 
for a user's Identity.


And yes, I meant to say sediments.  I'm trying to be part of the solution.



-Sean




___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Nova 2.1 and user permissions in the policy file

[Sean Dague]

On 05/23/2016 10:24 AM, Tim Bell wrote:
>  
> 
> Quick warning for those who are dependent on the "user_id:%(user_id)s"
> syntax for limiting actions by user. According to 
> https://bugs.launchpad.net/nova/+bug/1539351, this behavior was
> apparently not intended according to the bug report feedback. The
> behavior has changed from v2 to v2.1 and the old syntax no longer works.

Well, the behavior changes with the backend code base. By mitaka the
default backend code for both is the same. And the legacy code base is
about to be removed.

This feature (policy enforcement by user_id) was 100% untested, which is
why it never ended up in the new API stack. Being untested setting
owner: 'user_id: %(user_id)s' might have some really unexpected results
because not everything has a user_id.

> 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?

-Sean

-- 
Sean Dague
http://dague.net

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Nova 2.1 and user permissions in the policy file

[Tim Bell]

Quick warning for those who are dependent on the "user_id:%(user_id)s" syntax 
for limiting actions by user. According to  
https://bugs.launchpad.net/nova/+bug/1539351, this behavior was apparently not 
intended according to the bug report feedback. The behavior has changed from v2 
to v2.1 and the old syntax no longer works.

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.

Tim
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators