Open Stack

On Wed, 20 Mar 2019 09:37:54 -0500, Matt Riedemann <mriedemos at gmail.com> 
wrote:
> On 3/18/2019 4:40 PM, melanie witt wrote:
>> I wanted to run the idea by operators and users to get feedback.
> 
> Let me be frank and ask if we (nova) have specific operators and users
> that are clamoring for these changes and if so, do they plan on not only
> attending the session but engaging in the development of these pretty
> massive shifts in how nova works? I know we've been talking about this
> stuff for a long time, but the demand just doesn't feel like it's there
> from the operators community, and as a development team we're already
> spread thin.

I have customers who have been configuring keystone roles and applying 
them to non-admin users, configuring their policy.json correctly, and 
then being unable to access the nova API in the way they wanted [1]. 
Example: configured non-admin user access to live migration using 
role:MyRole and it doesn't work, they get 404 Instance Not Found if 
going across projects. Because of legacy stuff in nova, it only works 
correctly for role:admin.

After learning more about our history around policy stuff and picking 
Lance's brain, I found that scope types are a way we could solve the 
problem. Alternatively, we could fix it legacy-style. But if we go the 
scope types route, we could use enablement of proper non-admin policy 
handling as a carrot for getting operators/users to begin using tokens 
with different scopes to access the API in the way they want.

So, there are operators who want and need this, and based on what I 
learned from Lance, I think I can organize an effort around pushing this 
forward in Train. I outlined the steps we need [2]:

   1. Add test coverage for existing Nova default policy, to ensure we 
don't regress.
   2. Add Keystone scopes to Nova APIs. For example, server APIs could 
allow scopes of 'project' and 'system'.
   3. Add scope checks to Nova APIs and filter the compute_api.get() 
accordingly. The ability to filter would need to be added to the 
compute_api.get() method. If the token scope is 'project', filter the 
get() by project_id. If the token scope is 'system', do not filter the 
get().
   4. Remove the hard-coding of 'project_only=True' in the database layer.
   5. Educate users about how to request project-scoped vs system-scoped 
tokens from Keystone [4]. They would need to use a system-scoped token 
in order to do a server action across projects, whereas a project-scoped 
token would allow a server action only within a project.

And I will be able to spend time working on it, and my hope is that 
other people will want to help out too. The first two steps lend 
themselves especially well to being split up among many contributors and 
are quite mechanical. I plan to create an etherpad for organizing that 
work. I think the steps outlined above are not directly related to 
granular API policy and could be worked on in parallel, IIUC.

Cheers,
-melanie

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1663544
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1663544#c9